Using the STLPort 4.5.3 configured to work with Digital Mars, when I compile
this program with the -A switch:
class C
{
private:
void f();
};
class D
{
friend void C::f();
};
I get:
# define __DFL_TMPL_PARAM( classname, defval ) class classname = defval
^
C:\DigitalMars\stlport\stlport\stl/_config.h(370) : Preprocessor error
: '_STLP_DEFAULT_TYPE_PARAM' is already defined
--- errorlevel 1
but if I compile without the -A switch, there is no error. Of course there
should be an error in strict Ansi mode ( 11.4 para 7 says
"A name nominated by a friend declaration shall be accessible in the scope
of the class containing the friend declaration. " ), but I certainly
wouldn't expect a preprocessing error coming out of stlport. Notice that I
have included no files, which makes the error doubly curious. Is this a
fault of STLPort rather than Digital Mars ? I notice the latest STLPort is
4.6. Is there a version configured for Digital Mars using that latest
version which perhaps doesn't have this bug ?

Is
this a fault of STLPort rather than Digital Mars ? I notice the
latest STLPort is
4.6. Is there a version configured for Digital Mars using that latest
version which perhaps doesn't have this bug ?

"-A" and STLport have issues coexisting.

That is pretty succinct. Are either parties, Digital Mars and STLPort, aware
of that and attempting to make peace and live amicably together with their
child -A ?

All standards are subject to interpretation and DMC++ is no exception
(although I happen to like the interpretation.) STLport's objective is a
high degree of portability between a lot of compiler platforms; it's full
of a lot of compromises.
So, no, it's not likely to reconcile -A between DMC and STLport.
Of course, you're more than welcome to hack the STLport code, send patches
back to stlport.com to reconcile the problems. :-) :-)

Is
this a fault of STLPort rather than Digital Mars ? I notice the
latest STLPort is
4.6. Is there a version configured for Digital Mars using that
latest version which perhaps doesn't have this bug ?

"-A" and STLport have issues coexisting.

That is pretty succinct. Are either parties, Digital Mars and
STLPort, aware of that and attempting to make peace and live
amicably together with their child -A ?

All standards are subject to interpretation and DMC++ is no exception
(although I happen to like the interpretation.) STLport's objective
is a high degree of portability between a lot of compiler platforms;
it's full of a lot of compromises.
So, no, it's not likely to reconcile -A between DMC and STLport.
Of course, you're more than welcome to hack the STLport code, send
patches back to stlport.com to reconcile the problems. :-) :-)

I have no idea even what the problem is and why STLport thinks that
"'_STLP_DEFAULT_TYPE_PARAM' is already defined". I was hoping someone here
could explain that. I still don't know why anything from STLport is even
being #included since the code clearly doesn't need or use any #include
files. I am pointing to the STLport directory for its include files on the
command line, since I am running it from a batch file, but that still should
make no difference unless Digital Mars is including files automatically
somehow.

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
where your compiler has been installed at H:\Utilities\DigitalMars and the
TestPrivate.cpp is:
"class C
{
private:
void f();
};
class D
{
friend void C::f();
};"
When I compile with:
H:\Utilities\DigitalMars\bin\dmc -c -w- -oh:\tc\o\dm\TestPrivate.obj -IH:\Ut
ilities\DigitalMars\stlport\stlport TestPrivate.cpp
there are no compiler errors. Can you try and duplicate this ? Of course use
the -o switch to output to one of your own directories and the IH switch to
point to wherever STLport 4.5.3 is on your machine. I am using the latest
version of your compiler downloaded from your site.

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:

-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.

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 ?

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

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

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

mode. In non-strict Ansi mode no compiler flags the code as an error. What
is your understanding of this ?

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.

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

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!

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

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