#include <iostream>
#include <cassert>

int half(int n)
__in  { assert( n > 0 ); }
__out (result) { assert(result+result < n); }
__body
{
return n/2;
}

int main() {
std::cout << "Hello, world" << half(-5) << std::endl;
return 0;
}

compiling this code with DMC841C with STLport, error occured: # even if '-D' is NOT specified

>dmc  foo.cpp
__in  { assert( n > 0 ); }
^
foo.cpp(5) : Error: '__stl_in' is not in function parameter list
__out (result) { assert(result+result < n); }
^
foo.cpp(6) : Error: '=', ';' or ',' expected
}
^
foo.cpp(10) : Error: '=', ';' or ',' expected
return 0;
^
foo.cpp(14) : Error: '=', ';' or ',' expected
}
^
foo.cpp(15) : Error: '=', ';' or ',' expected
Fatal error: too many errors
--- errorlevel 1

..why? and what should I do to compile?

FUKUDA wrote:
> __in  { assert( n > 0 ); }
> ^
> foo.cpp(5) : Error: '__stl_in' is not in function parameter list
> __out (result) { assert(result+result < n); }
> ^
> foo.cpp(6) : Error: '=', ';' or ',' expected
> }
> ^
> foo.cpp(10) : Error: '=', ';' or ',' expected
> return 0;
> ^
> foo.cpp(14) : Error: '=', ';' or ',' expected
> }
> ^
> foo.cpp(15) : Error: '=', ';' or ',' expected
> Fatal error: too many errors
> --- errorlevel 1
> 
> ..why? and what should I do to compile?

There's a good reason for why this does not work -- the STLport code's header files have "__in" and "__out" as parameters all over the place. If you look in the stlport\stl\stl_dm.h header file, you'll find the #define's.

You're #include-ing <iostream>, which comes from STLport.

Honestly, I'm not sure whether to fix this because the STLport people aren't necessarily friendly to bug fixes and "__in" as a parameter to template methods makes perfectly good sense.


-scooter

In article <ck3tjd$1qrr$1@digitaldaemon.com>, Scott Michel says...
>...
>Honestly, I'm not sure whether to fix this because the STLport people
>aren't necessarily friendly to bug fixes and "__in" as a parameter to
>template methods makes perfectly good sense.

thanks a lot.

insertion of

#undef __in
#undef __out
#undef __body

after #include, it works.

--- another problem ---
so I tried to build debug version on STLport:

> make -f dm.mak
Error on line 69: bad syntax for implicit rule, should be .frm.to:

.. why?

FUKUDA wrote:
> insertion of 
> 
> #undef __in
> #undef __out
> #undef __body

I thought about this solution this morning in the shower. Glad it works for you.

> --- another problem ---
> so I tried to build debug version on STLport:
> 
> 
>>make -f dm.mak

Use smake. :-)


-scooter

In article <ck6idh$1u6a$1@digitaldaemon.com>, Scott Michel says...

>> so I tried to build debug version on STLport:
>> 
>>>make -f dm.mak
>
>Use smake. :-)

free DMC++ does NOT include smake...

FUKUDA wrote:
> free DMC++ does NOT include smake...

I'm well aware that the free DMC++ doesn't include smake, and neither does it include the DLL runtime.

My question for you would be, "Why are you rebuilding STLport when I've already done it for you?" Or, "Why haven't you purchased the CD yet?"

In article <ckm9id$2ovn$2@digitaldaemon.com>, Scott Michel says...

>I'm well aware that the free DMC++ doesn't include smake, and neither does it include the DLL runtime.
>
>My question for you would be, "Why are you rebuilding STLport when I've already done it for you?" Or, "Why haven't you purchased the CD yet?"

STLport distribution stlport.zip doen NOT include DEBUG version lib.
(only stlp45dm_static.lib)

so, when I specified -D option to enable DbC, linker can not find appropriate lib.

FUKUDA wrote:
> In article <ckm9id$2ovn$2@digitaldaemon.com>, Scott Michel says...
> 
> 
>>I'm well aware that the free DMC++ doesn't include smake, and neither does it include the DLL runtime.
>>
>>My question for you would be, "Why are you rebuilding STLport when I've already done it for you?" Or, "Why haven't you purchased the CD yet?"
> 
> 
> STLport distribution stlport.zip doen NOT include DEBUG version lib.
> (only stlp45dm_static.lib)

You must have downloaded the incorrect file. My recent port of the 4.6.2 STLport is http://mordred.cs.ucla.edu/STLport_DMC/STLport-4.6.2.zip. You will find the debug versions of the library in that zipfile. Also, please make sure you read some of my notes and installation instructions http://mordred.cs.ucla.edu/STLport_DMC/

> so, when I specified -D option to enable DbC, linker can not find
> appropriate lib.

There are two different debug versions of the library. There's the -DDEBUG version and the -D_STLP_DEBUG version. Other people have reported problems with linking a -D_STLP_DEBUG program, so YMMV.


-scooter

STLport 5.0 will fix the some of the `__' nonsense because Microsoft's Whidbey compiler (8.0) uses the same __ variables as STLport - causing name conflicts. In general `__' is reserved for compiler/OS internal variables, I would like to know why STLport chose to name all their variables in such a manner.

>Honestly, I'm not sure whether to fix this because the STLport people
>aren't necessarily friendly to bug fixes and "__in" as a parameter to
>template methods makes perfectly good sense.
>-scooter

anuj.goyal@gmail.com wrote:
> STLport 5.0 will fix the some of the `__' nonsense because Microsoft's Whidbey
> compiler (8.0) uses the same __ variables as STLport - causing name conflicts.
> In general `__' is reserved for compiler/OS internal variables, I would like to
> know why STLport chose to name all their variables in such a manner.

So that they wouldn't clash with (a) users, (b) other compilers, or (c) coolness factor? Could have been a holdover from the HP and SGI code bases.

Actually, I don't think that it'd make a stylistic or compilation difference if they used double underscores or not. Like you deftly pointed out, double underscores are generally used by the compiler vendors for "special things."


-scooter