c++ - Fatal error: out of memory - anything I can do?
- "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)
Oct 10 2004
"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
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
"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
"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
"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
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
implementationfile (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
orso.
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
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
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> 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
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
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
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
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