Digital Mars - c++ - Compile error using -A and Stlport 4.5.3

↑ ↓ ← → "Edward Diener" <eddielee_no_spam_here_and_now tropicsoft.com> writes:

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 ?

Apr 10 2004

↑ ↓ ← → Scott Michel <scottm mordred.cs.ucla.edu> writes:

Edward Diener <eddielee_no_spam_here_and_now tropicsoft.com> wrote:
                                                               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.

Apr 10 2004

↑ ↓ ← → "Edward Diener" <eddielee_no_spam_here_and_now tropicsoft.com> writes:

Scott Michel wrote:
 Edward Diener <eddielee_no_spam_here_and_now tropicsoft.com> wrote:
                                                               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 ?

Apr 10 2004

↑ ↓ ← → Scott Michel <scottm mordred.cs.ucla.edu> writes:

Edward Diener <eddielee_no_spam_here_and_now tropicsoft.com> wrote:
 Scott Michel wrote:
 Edward Diener <eddielee_no_spam_here_and_now tropicsoft.com> wrote:
                                                               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. :-) :-)

Apr 11 2004

↑ ↓ ← → "Edward Diener" <eddielee_no_spam_here_and_now tropicsoft.com> writes:

Scott Michel wrote:
 Edward Diener <eddielee_no_spam_here_and_now tropicsoft.com> wrote:
 Scott Michel wrote:
 Edward Diener <eddielee_no_spam_here_and_now tropicsoft.com> wrote:
                                                               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.

Apr 11 2004

↑ ↓ ← → "Edward Diener" <eddielee_no_spam_here_and_now tropicsoft.com> writes:

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

Apr 11 2004

↑ ↓ ← → "Walter" <walter digitalmars.com> writes:

"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?

Apr 11 2004

↑ ↓ ← → "Edward Diener" <eddielee_no_spam_here_and_now tropicsoft.com> writes:

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

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.

Apr 12 2004

↑ ↓ ← → "Walter" <walter digitalmars.com> writes:

"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:


 \Utilities\DigitalMars\stlport\stlport TestPrivate.cpp


Do you have a blank or newline after the -IH: ?

Apr 12 2004

↑ ↓ ← → "Edward Diener" <eddielee_no_spam_here_and_now tropicsoft.com> writes:

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:


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

Apr 12 2004

↑ ↓ ← → "Edward Diener" <eddielee_no_spam_here_and_now tropicsoft.com> writes:

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 ?

Apr 12 2004

↑ ↓ ← → "Walter" <walter digitalmars.com> writes:

"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


 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 ?


I'm unconvinced either is right yet.

Apr 12 2004

↑ ↓ ← → "Edward Diener" <eddielee_no_spam_here_and_now tropicsoft.com> writes:

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.

Apr 12 2004

↑ ↓ ← → "Walter" <walter digitalmars.com> writes:

"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


 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!

Apr 13 2004

↑ ↓ ← → "KTC" <me here.com> writes:

"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

Apr 12 2004

↑ ↓ ← → "Edward Diener" <eddielee_no_spam_here_and_now tropicsoft.com> writes:

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.

Apr 12 2004