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

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

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

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

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