• Scott Michel <scottm aero.org> Nov 09 2005
• "Walter Bright" <newshound digitalmars.com> Nov 11 2005
• Heinz Saathoff <hsaat despammed.com> Nov 11 2005
• tink <tink_member pathlink.com> Nov 13 2005
• "Walter Bright" <newshound digitalmars.com> Nov 13 2005
• Scott Michel <scottm aero.org> Nov 15 2005
• Scott Michel <scottm aero.org> Nov 14 2005

I've already sent Watlter the testcase that replicates the bug in 
simplest terms. Currently, it is not possible to compile STLport or use 
STLport in your applications, esp. if you use <string>.

Please do not barrage Walter with bug reports.

Details: DMC complains about _DEFAULT_SIZE not being defined. The test 
case looks like:

--------------------
template<class Tp, int>
class Parent {
public:
   enum { DefaultSize = 32 };

private:
   Tp  array[DefaultSize];

public:
   Parent(int size);
};

typedef Parent<char, DefaultSize> NewBug;
--------------------

What happened is DMC++ now implements dependent/nondependent name lookup.
DefaultSize is not in scope at the declaration of NewBug according to my
understanding of the Standard.

There were a couple of problems compiling STLPort with this new lookup, but
a corrected STLPort has been posted.

I believe the compiler is operating correctly.

Walter Bright wrote...
 What happened is DMC++ now implements dependent/nondependent name lookup.
 DefaultSize is not in scope at the declaration of NewBug according to my
 understanding of the Standard.
 
 There were a couple of problems compiling STLPort with this new lookup, but
 a corrected STLPort has been posted.
 
 I believe the compiler is operating correctly.


The actual gimpel PC-Lint doesn't accept the code either:
                     _
  typedef Parent<char, DefaultSize> NewBug;
  bug.cpp  14  Error 40: Undeclared identifier 'DefaultSize'
  bug.cpp  14  Error 1048: expected a constant expression
  bug.cpp  14  Error 40: Undeclared identifier 'DefaultSize'
  bug.cpp  14  Error 1048: expected a constant expression

It's also my understanding that DefaultSize is not in scope here.


- Heinz

In article <dl1nqt$5fi$1 digitaldaemon.com>, Walter Bright says...
There were a couple of problems compiling STLPort with this new lookup, but
a corrected STLPort has been posted.


Where is the corrected STLPort? Is the corrected version on the STLPort website,
the STLPort shipped with DMC++, or the STLPort 4.6.2 from Scott Michel's site?

Doug

"tink" <tink_member pathlink.com> wrote in message
news:dl7u2k$2fjl$1 digitaldaemon.com...
 In article <dl1nqt$5fi$1 digitaldaemon.com>, Walter Bright says...
There were a couple of problems compiling STLPort with this new lookup,




a corrected STLPort has been posted.


 Where is the corrected STLPort? Is the corrected version on the STLPort



No.

 the STLPort shipped with DMC++,


Yes.

tink wrote:
 In article <dl1nqt$5fi$1 digitaldaemon.com>, Walter Bright says...
 
There were a couple of problems compiling STLPort with this new lookup, but
a corrected STLPort has been posted.


 
 Where is the corrected STLPort? Is the corrected version on the STLPort
website,
 the STLPort shipped with DMC++, or the STLPort 4.6.2 from Scott Michel's site?


Took me most of the day to recompile STLport. Updated ZIP file and patch 
files for 4.6.2:

http://mordred.cs.ucla.edu/STLport_DMC/STLport_8.46.zip
http://mordred.cs.ucla.edu/STLport_DMC/STLport_8.46.patch


-scooter

Walter Bright wrote:
 What happened is DMC++ now implements dependent/nondependent name lookup.
 DefaultSize is not in scope at the declaration of NewBug according to my
 understanding of the Standard.


Imagine my surprise when suddenly the code no longer compiled. Not 
exactly "The Principle of Least Surprise".

I understood what was going on when I looked at the code, and posting a 
fair warning seemed prudent.

 There were a couple of problems compiling STLPort with this new lookup, but
 a corrected STLPort has been posted.


Is there a diff somewhere so I can update 4.6.2 on my site?

 I believe the compiler is operating correctly.


It's your compiler. Of course it is! :-)


-scooter