www.digitalmars.com Home | Search | C & C++ | D | DMDScript | News Groups | index | prev | next
Archives

D Programming
D
D.gnu
digitalmars.D
digitalmars.D.bugs
digitalmars.D.dtl
digitalmars.D.dwt
digitalmars.D.announce
digitalmars.D.learn
digitalmars.D.debugger

C/C++ Programming
c++
c++.announce
c++.atl
c++.beta
c++.chat
c++.command-line
c++.dos
c++.dos.16-bits
c++.dos.32-bits
c++.idde
c++.mfc
c++.rtl
c++.stl
c++.stl.hp
c++.stl.port
c++.stl.sgi
c++.stlsoft
c++.windows
c++.windows.16-bits
c++.windows.32-bits
c++.wxwindows

digitalmars.empire
digitalmars.DMDScript

c++ - Fatal error: out of memory - anything I can do?

↑ ↓ ← "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
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)
Oct 10 2004
"Walter" <newshound digitalmars.com> writes:
"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?
Oct 10 2004
↑ ↓ "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
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?

Oct 10 2004
↑ ↓ "Walter" <newshound digitalmars.com> writes:
"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.
Oct 10 2004
↑ ↓ "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"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?
Oct 10 2004
↑ ↓ "Walter" <newshound digitalmars.com> writes:
"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.
Oct 11 2004
↑ ↓ Dimitri Kaparis <d_kaparis universalstudyhelper.com> writes:
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.
Oct 13 2004
↑ ↓ Scott Michel <scottm aero.org> writes:
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.
Oct 13 2004
↑ ↓ Dimitri Kaparis <d_kaparis universalstudyhelper.com> writes:
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
Oct 13 2004
↑ ↓ → Scott Michel <scottm aero.org> writes:
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
Oct 14 2004
"Walter" <newshound digitalmars.com> writes:
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)

Oct 22 2004
↑ ↓ "Matthew" <admin.hat stlsoft.dot.org> writes:
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)


Feb 21 2005
↑ ↓ "Walter" <newshound digitalmars.com> writes:
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)



Feb 26 2005
↑ ↓ → "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
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)




Feb 26 2005