Walter wrote:
> "Edward Diener" <eddielee_no_spam_here_and_now@tropicsoft.com> wrote in message news:c5dvid$1t14$1@digitaldaemon.com...
>> Walter wrote:
>>> "Edward Diener" <eddielee_no_spam_here_and_now@tropicsoft.com> wrote in message news:c5ccen$2g54$1@digitaldaemon.com...
>>>> Walter wrote:
>>>>> "Edward Diener" <eddielee_no_spam_here_and_now@tropicsoft.com> wrote in message news:c5a7vd$2bet$1@digitaldaemon.com...
>>>>>> Notice that I
>>>>>> have included no files, which makes the error doubly curious.
>>>>>
>>>>> You can have the compiler include files not in the source with the -HI switch.
>>>>
>>>> I am not using the -HI switch directly, whatever that is. My compiler switches are -c -A -w- .
>>>
>>> That is very curious. Do you have a CFLAGS environment variable?
>>
>> No. My command line in the batch file looks like:
>>
>>
> H:\Utilities\DigitalMars\bin\dmc -c -A -w- -oh:\tc\o\dm\TestPrivate.obj -IH:
>> \Utilities\DigitalMars\stlport\stlport TestPrivate.cpp
>
> Do you have a blank or newline after the -IH: ?

No. It is all on one line but undortunately HTML folds it when I display it in a post.

Please test it for yourself if you have STLport 4.5.3 installed and, if yours compiles correctly, I will look into why mine does not.

"Walter" <walter@digitalmars.com> wrote in message news:c5dbok$tn8$1@digitaldaemon.com...
>
> "Edward Diener" wrote
> >
> > I am not using the -HI switch directly, whatever that is. My compiler switches are -c -A -w- .
>
> That is very curious. Do you have a CFLAGS environment variable?
>
>

Error reproduced using a band new installation of DMC unzipped into default directory (I've just reformatted my comp, so no envir set at all).

\dm\bin\dmc -c -A -w- -o\dm\projects\Quick_Test.obj -I\dm\stlport\stlport\ Quick_Test.cpp

KTC
-- 
Experience is a good school but the fees are high.
    - Heinrich Heine

KTC wrote:
> "Walter" <walter@digitalmars.com> wrote in message news:c5dbok$tn8$1@digitaldaemon.com...
>>
>> "Edward Diener" wrote
>>>
>>> I am not using the -HI switch directly, whatever that is. My compiler switches are -c -A -w- .
>>
>> That is very curious. Do you have a CFLAGS environment variable?
>>
>>
>
> Error reproduced using a band new installation of DMC unzipped into default directory (I've just reformatted my comp, so no envir set at all).
>
> \dm\bin\dmc -c -A -w- -o\dm\projects\Quick_Test.obj -I\dm\stlport\stlport\ Quick_Test.cpp

Thanks ! At least it is a bug which can be duplicated.

I see what the problem is now. The attached file goes in dm\stlport\stlport\config, and replaces stl_dm.h.

Thanks for helping me out with this.

-Walter

Walter wrote:
> I see what the problem is now. The attached file goes in dm\stlport\stlport\config, and replaces stl_dm.h.
>
> Thanks for helping me out with this.

Your welcome.

I see what you have done, setting
# define _STLP_DEFAULT_TYPE_PARAM 1
However, that leads to a few more questions:

1) What causes this file to be included.long with _config.h, when I am not including anything in my source file ?

2) It seems as if line 369 in stlport\stlport\stl\_config.h is in error and the sequence there should be instead:

#if defined(_STLP_DEFAULT_TYPE_PARAM)
#undef _STLP_DEFAULT_TYPE_PARAM
#endif
# define _STLP_DEFAULT_TYPE_PARAM 1

Of course this is not your problem.

3) There is a discussion on whether the source file does indeed have an error in comp.lang.c++. Among the many C++ compilers in which I am able to try this out, Comeau and the latest C++BuilderX compiler from Borland give an error in strict Ansi mode, saying that "function "C::f" is inaccessible" in the expression "function "C::f", while VC6,7,7.1,8.0, GCC3.3.1, C++Builder 3,4,5,6, and your compiler do not flag any errors in strict Ansi mode. In non-strict Ansi mode no compiler flags the code as an error. What is your understanding of this ?

"Edward Diener" <eddielee_no_spam_here_and_now@tropicsoft.com> wrote in message news:c5fckj$1ioo$1@digitaldaemon.com...
> 1) What causes this file to be included.long with _config.h, when I am not including anything in my source file ?

The -A means RTTI is supported, to do rtti requires that typeinfo be included.

> 2) It seems as if line 369 in stlport\stlport\stl\_config.h is in error
and
> the sequence there should be instead:
>
> #if defined(_STLP_DEFAULT_TYPE_PARAM)
> #undef _STLP_DEFAULT_TYPE_PARAM
> #endif
> # define _STLP_DEFAULT_TYPE_PARAM 1
>
> Of course this is not your problem.

The other definitions of _STL__DEFAULT_TYPE_PARAM all set it to 1, so stl_dm.h was just inconsistent with them.

> 3) There is a discussion on whether the source file does indeed have an error in comp.lang.c++. Among the many C++ compilers in which I am able to try this out, Comeau and the latest C++BuilderX compiler from Borland give an error in strict Ansi mode, saying that "function "C::f" is
inaccessible"
> in the expression "function "C::f", while VC6,7,7.1,8.0, GCC3.3.1, C++Builder 3,4,5,6, and your compiler do not flag any errors in strict
Ansi
> mode. In non-strict Ansi mode no compiler flags the code as an error. What is your understanding of this ?

I'm unconvinced either is right yet.

Walter wrote:
> "Edward Diener" <eddielee_no_spam_here_and_now@tropicsoft.com> wrote in message news:c5fckj$1ioo$1@digitaldaemon.com...
>> 1) What causes this file to be included.long with _config.h, when I am not including anything in my source file ?
>
> The -A means RTTI is supported, to do rtti requires that typeinfo be included.

Even if I never use typeid or type_info myself ? That is strange to me. Perhaps it should be documented when a compile includes header files which a programmer does not.

>
>> 2) It seems as if line 369 in stlport\stlport\stl\_config.h is in error and the sequence there should be instead:
>>
>> #if defined(_STLP_DEFAULT_TYPE_PARAM)
>> #undef _STLP_DEFAULT_TYPE_PARAM
>> #endif
>> # define _STLP_DEFAULT_TYPE_PARAM 1
>>
>> Of course this is not your problem.
>
> The other definitions of _STL__DEFAULT_TYPE_PARAM all set it to 1, so stl_dm.h was just inconsistent with them.

But the corrected lines above prevent the compiler error no matter if _STL__DEFAULT_TYPE_PARAM is set or not or what it is set to. Anyway it is a moot point. I can always suggest this to STLport.

>
>> 3) There is a discussion on whether the source file does indeed have an error in comp.lang.c++. Among the many C++ compilers in which I am able to try this out, Comeau and the latest C++BuilderX compiler from Borland give an error in strict Ansi mode, saying that "function "C::f" is inaccessible" in the expression "function "C::f", while VC6,7,7.1,8.0, GCC3.3.1, C++Builder 3,4,5,6, and your compiler do not flag any errors in strict Ansi mode. In non-strict Ansi mode no compiler flags the code as an error. What is your understanding of this ?
>
> I'm unconvinced either is right yet.

Evidently the DM compiler is convinced that it is legal to use the construct. I tend to favor the opposite idea that class D can not access a private member of class C even if it is just to make that member a friend of itself. I have always philosophically viewed "private" as: "hands off" except by the class members or friends of the class itself.

"Edward Diener" <eddielee_no_spam_here_and_now@tropicsoft.com> wrote in message news:c5fvj6$2glq$1@digitaldaemon.com...
> Evidently the DM compiler is convinced that it is legal to use the construct. I tend to favor the opposite idea that class D can not access a private member of class C even if it is just to make that member a friend
of
> itself. I have always philosophically viewed "private" as: "hands off" except by the class members or friends of the class itself.

In C++, there is the right way, the wrong way, and what the Standard says!