• "Matthew" <admin stlsoft.dot.dot.dot.dot.org> Oct 10 2004
• "Walter" <newshound digitalmars.com> Oct 10 2004
• "Matthew" <admin stlsoft.dot.dot.dot.dot.org> Oct 10 2004
• "Walter" <newshound digitalmars.com> Oct 10 2004
• "Matthew" <admin stlsoft.dot.dot.dot.dot.org> Oct 10 2004
• "Walter" <newshound digitalmars.com> Oct 11 2004
• Dimitri Kaparis <d_kaparis universalstudyhelper.com> Oct 13 2004
• Scott Michel <scottm aero.org> Oct 13 2004
• Dimitri Kaparis <d_kaparis universalstudyhelper.com> Oct 13 2004
• Scott Michel <scottm aero.org> Oct 14 2004
• "Walter" <newshound digitalmars.com> Oct 22 2004
• "Matthew" <admin.hat stlsoft.dot.org> Feb 21 2005
• "Walter" <newshound digitalmars.com> Feb 26 2005
• "Matthew" <admin stlsoft.dot.dot.dot.dot.org> Feb 26 2005

I mean in terms of command-line. I don't want to split my implementation
file (as it's a unittest file, that includes all headers in WinSTL)

"Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message
news:ckaokb$1u0f$1 digitaldaemon.com...
 I mean in terms of command-line. I don't want to split my implementation
 file (as it's a unittest file, that includes all headers in WinSTL)


You're the first to come up with that message! What are you doing?

Compiling the unit-test for WinSTL. It includes all the WinSTL headers,
under the definition of STLSOFT_UNITTEST.


"Walter" <newshound digitalmars.com> wrote in message
news:ckbtie$2pgd$1 digitaldaemon.com...
 "Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message
 news:ckaokb$1u0f$1 digitaldaemon.com...
 I mean in terms of command-line. I don't want to split my




 file (as it's a unittest file, that includes all headers in WinSTL)


 You're the first to come up with that message! What are you doing?

"Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message
news:ckc6i9$2vpq$1 digitaldaemon.com...
 Compiling the unit-test for WinSTL. It includes all the WinSTL headers,
 under the definition of STLSOFT_UNITTEST.


 "Walter" <newshound digitalmars.com> wrote in message
 news:ckbtie$2pgd$1 digitaldaemon.com...
 "Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message
 news:ckaokb$1u0f$1 digitaldaemon.com...
 I mean in terms of command-line. I don't want to split my




 file (as it's a unittest file, that includes all headers in WinSTL)


 You're the first to come up with that message! What are you doing?




Essentially, it means you have a symbol table larger than 30 megabytes or
so.

"Walter" <newshound digitalmars.com> wrote in message
news:ckcksk$7qm$1 digitaldaemon.com...
 "Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message
 news:ckc6i9$2vpq$1 digitaldaemon.com...
 Compiling the unit-test for WinSTL. It includes all the WinSTL




 under the definition of STLSOFT_UNITTEST.


 "Walter" <newshound digitalmars.com> wrote in message
 news:ckbtie$2pgd$1 digitaldaemon.com...
 "Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message
 news:ckaokb$1u0f$1 digitaldaemon.com...
 I mean in terms of command-line. I don't want to split my




 file (as it's a unittest file, that includes all headers in








 You're the first to come up with that message! What are you doing?




 Essentially, it means you have a symbol table larger than 30 megabytes


 so.


Can this be allowed to grow larger by a current (or future) command-line
param?

"Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message
news:ckcmn8$927$1 digitaldaemon.com...
 "Walter" <newshound digitalmars.com> wrote in message
 news:ckcksk$7qm$1 digitaldaemon.com...
 "Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message
 news:ckc6i9$2vpq$1 digitaldaemon.com...
 Compiling the unit-test for WinSTL. It includes all the WinSTL




 under the definition of STLSOFT_UNITTEST.


 "Walter" <newshound digitalmars.com> wrote in message
 news:ckbtie$2pgd$1 digitaldaemon.com...
 "Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message
 news:ckaokb$1u0f$1 digitaldaemon.com...
 I mean in terms of command-line. I don't want to split my




 file (as it's a unittest file, that includes all headers in








 You're the first to come up with that message! What are you doing?




 Essentially, it means you have a symbol table larger than 30 megabytes


 so.


 Can this be allowed to grow larger by a current (or future) command-line
 param?


Sure, but it sure seems like a massive compilation you're doing.

Walter wrote:
 "Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message
 news:ckcmn8$927$1 digitaldaemon.com...
 
"Walter" <newshound digitalmars.com> wrote in message
news:ckcksk$7qm$1 digitaldaemon.com...

"Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message
news:ckc6i9$2vpq$1 digitaldaemon.com...

Compiling the unit-test for WinSTL. It includes all the WinSTL




headers,

under the definition of STLSOFT_UNITTEST.


"Walter" <newshound digitalmars.com> wrote in message
news:ckbtie$2pgd$1 digitaldaemon.com...

"Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message
news:ckaokb$1u0f$1 digitaldaemon.com...

I mean in terms of command-line. I don't want to split my




implementation

file (as it's a unittest file, that includes all headers in








WinSTL)

You're the first to come up with that message! What are you doing?




Essentially, it means you have a symbol table larger than 30 megabytes


or

so.


Can this be allowed to grow larger by a current (or future) command-line
param?


 
 Sure, but it sure seems like a massive compilation you're doing.
 
 


It's hit me also. I've decided to try using the latest compiler version 
with the new STLPort 4.6.2 to build my project and it choke on one of my 
top-level classes. There's some heavy usage of all kinds of stl 
containers there. I tried going through my headers in the include tree 
and removing some inefficiencies here and there, but I don't think 
anything would cut it, short of probably splitting the implementation of 
my class.
The same code compiles successfully with 8.38 and the previously 
supplied version of STLPort, 4.5.3.

Dimitri Kaparis wrote:
 It's hit me also. I've decided to try using the latest compiler version 
 with the new STLPort 4.6.2 to build my project and it choke on one of my 
 top-level classes. There's some heavy usage of all kinds of stl 
 containers there. I tried going through my headers in the include tree 
 and removing some inefficiencies here and there, but I don't think 
 anything would cut it, short of probably splitting the implementation of 
 my class.


Are you compiling with "-g" or "-gf"? Makes a big difference: "-g" is 
somewhat smaller whereas "-gf" is world+dog+kitchen_sink.

Scott Michel wrote:
 Dimitri Kaparis wrote:
 
 It's hit me also. I've decided to try using the latest compiler 
 version with the new STLPort 4.6.2 to build my project and it choke on 
 one of my top-level classes. There's some heavy usage of all kinds of 
 stl containers there. I tried going through my headers in the include 
 tree and removing some inefficiencies here and there, but I don't 
 think anything would cut it, short of probably splitting the 
 implementation of my class.


 
 Are you compiling with "-g" or "-gf"? Makes a big difference: "-g" is 
 somewhat smaller whereas "-gf" is world+dog+kitchen_sink.


Actually I was compiling with -gh, but that did not turn out to be the 
problem. I was trying to use STLPort Debug (_STLP_DEBUG), which was 
obviously bringing in too much load. Normal debug mode compiled 
successfully with all settings I tried, while _STLP_DEBUG crashed with 
"Out of memory" both with "-g" and "-gf"
The STLPort Debug mode turns out to be quite unusable. In case it is 
still, or will be, supported, here are two other problems I have 
encountered with it:

Comparing a std::string to a character pointer or a literal string using 
the "!=" operator gives the following error:
main.cpp(6): ambiguous reference to symbol
main.cpp(6): Had: std::operator !=(const _Tp&,const _Tp&)
main.cpp(6): and: std::operator !=(const 
_Nondebug_string<_CharT,_Traits,_Alloc>&,const _CharT*)

Using std::list's copy constructor gives the following:

C:\dm\bin\..\stlport\stlport\stl/debug/_list.h(149) : Error: member 
'?$__range_checker std HU?$_List_iterator std HU?$_Const_traits std H 1  1 ' 
of class '?$list std HV?$allocator std H 1 ' is not accessible

Dimitri Kaparis wrote:
 Actually I was compiling with -gh, but that did not turn out to be the 
 problem. I was trying to use STLPort Debug (_STLP_DEBUG), which was 
 obviously bringing in too much load. Normal debug mode compiled 
 successfully with all settings I tried, while _STLP_DEBUG crashed with 
 "Out of memory" both with "-g" and "-gf"


I didn't run into your problems when building the regression tests, but 
ran into the problem you report below. But I'm not entirely surprised, 
after I had to correct a few bugs in the _STLP_DEBUG code.

Frankly, I'm not convinced that _STLP_DEBUG really does anything 
worthwhile other than create headaches. It's pretty clear that not too 
many people use _STLP_DEBUG because there were some glaring (and I mean 
!!OBVIOUS!!) bugs in the code.

 Comparing a std::string to a character pointer or a literal string using 
 the "!=" operator gives the following error:
 main.cpp(6): ambiguous reference to symbol
 main.cpp(6): Had: std::operator !=(const _Tp&,const _Tp&)
 main.cpp(6): and: std::operator !=(const 
 _Nondebug_string<_CharT,_Traits,_Alloc>&,const _CharT*)


Yup, I reported this to Walter and provided a small testcase. That's the 
most time consuming part of doing the debugging: if I find a compiler 
bug, then stripping down the code to a reasonable and Walter-testable 
testcase takes a lot of time.

 C:\dm\bin\..\stlport\stlport\stl/debug/_list.h(149) : Error: member 
 '?$__range_checker std HU?$_List_iterator std HU?$_Const_traits std H 1  1 ' 
 of class '?$list std HV?$allocator std H 1 ' is not accessible


This one was reported elsewhere about private bases not being accessible.


-scooter

There's a new switch for this in the 8.42.1 beta.

"Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message
news:ckaokb$1u0f$1 digitaldaemon.com...
 I mean in terms of command-line. I don't want to split my implementation
 file (as it's a unittest file, that includes all headers in WinSTL)

If this is -GT, it doesn't work. I've tried from -GT10 right up to
-GT1000000000. What gives?

"Walter" <newshound digitalmars.com> wrote in message
news:clbl2r$nbi$3 digitaldaemon.com...
 There's a new switch for this in the 8.42.1 beta.

 "Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message
 news:ckaokb$1u0f$1 digitaldaemon.com...
 I mean in terms of command-line. I don't want to split my implementation
 file (as it's a unittest file, that includes all headers in WinSTL)


 

It's -HPnn, nn is in megabytes.

"Matthew" <admin.hat stlsoft.dot.org> wrote in message
news:cvcf3q$2d9q$1 digitaldaemon.com...
 If this is -GT, it doesn't work. I've tried from -GT10 right up


 "Walter" <newshound digitalmars.com> wrote in message


 There's a new switch for this in the 8.42.1 beta.

 "Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message
 news:ckaokb$1u0f$1 digitaldaemon.com...
 I mean in terms of command-line. I don't want to split my






 file (as it's a unittest file, that includes all headers in WinSTL)

Ah!

LOL

Anyway, is no matter now. This issue has spurred me into what is now a 
nicer solution for the STLSoft unittests.

I now have a Ruby script - what else?! - that examines the STLSoft 
directory and sub-dirs for all .h and .hpp, and creates a bunch of 
unittest files: 10 each for STLSoft, ACESTL ATLSTL, COMSTL, ..., WinSTL, 
WTLSTL. Each unittest source file contains at most 20 header files from 
the respective project. Furthermore, the compiler (in)compatibilities 
are now marked in the header files, and so the unittest file contains 
conditional inclusion, as in:

// From rangelib/indexed_range.hpp

/* 
/////////////////////////////////////////////////////////////////////////////
 * Compatibility
 */

/*
[Incompatibilies-start]
__STLSOFT_COMPILER_IS_BORLAND:
__STLSOFT_COMPILER_IS_MWERKS:   (__MWERKS__ & 0xFF00) < 0x3000
[Incompatibilies-end]
 */


which results in ..\test\rangelib\unittest.0.cpp containing:

#include 
<H:\STLSoft\Identities\STLSoft\stlsoft\inprogress\rangelib\associative_range.hpp>
#if !defined(__STLSOFT_COMPILER_IS_BORLAND) && \
    !(defined(__STLSOFT_COMPILER_IS_MWERKS) && ((__MWERKS__ & 0xFF00) < 
0x3000))
# include 
<H:\STLSoft\Identities\STLSoft\stlsoft\inprogress\rangelib\indexed_range.hpp>
#endif
#include 
<H:\STLSoft\Identities\STLSoft\stlsoft\inprogress\rangelib\operator_adaptors.hpp>


Since this is all auto-generated (along with the unittest makefiles for 
all projects for all supported compilers), the single point of 
compatibility truth is in the header itself, which helps enormously. 
Furthermore, because the unittest inclusions are partitioned into a set 
of fully auto-generated source files, linked to one 'main()' unittest 
file, the auto-generation is far easier than it was last year. And now 
the only compiler that hangs with the reduced code size per unittest 
file is VC++ 5.0, which I'm all but about to junk support for anyway. 
(The only reason I've kept it so far is that all the Synesis Software 
DLLs are still built with it ... he he.)

So, in summary, I'm glad DMC++ had a spat since it's resulted in me 
having a far better unitttest generation toolset than before.

Cheers

Matthew

P.S. All that remains to do now is to get DMC++ fully compatible with 
the current RangeLib, which relies on it having a teensy bit better 
SFINAE support ... ;)



"Walter" <newshound digitalmars.com> wrote in message 
news:cvq9vn$ric$1 digitaldaemon.com...
 It's -HPnn, nn is in megabytes.

 "Matthew" <admin.hat stlsoft.dot.org> wrote in message
 news:cvcf3q$2d9q$1 digitaldaemon.com...
 If this is -GT, it doesn't work. I've tried from -GT10 right up


 "Walter" <newshound digitalmars.com> wrote in message


 There's a new switch for this in the 8.42.1 beta.

 "Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message
 news:ckaokb$1u0f$1 digitaldaemon.com...
 I mean in terms of command-line. I don't want to split my






 file (as it's a unittest file, that includes all headers in 
 WinSTL)