Title: | C++ |
Notice: | Read 1.* and use keywords (e.g. SHOW KEY/FULL KIT_CXX_VAX_VMS) |
Moderator: | DECCXX::AMARTIN |
Created: | Fri Nov 06 1987 |
Last Modified: | Thu Jun 05 1997 |
Last Successful Update: | Fri Jun 06 1997 |
Number of topics: | 3604 |
Total number of notes: | 18242 |
Hi, I have searched the conference and saw quite a few problems where virtual memory limits were hit, but couldn't see anything which looked similar to this.... so if this has already been reported I apologise. $ cxx /version NL: DEC C++ V5.5-017 on OpenVMS VAX V6.2 $ mms /desc=makefile.mms test cxx /assume=noheader_type_default /exceptions=CLEANUP /notemplate_define /NOOPT /include =([-.H],DMQ$USER) /object=BUILD$OUTPUT:TESTFILE.OBJ TESTFILE.CXX %CLI-F-TEXT, Compiler abort - virtual memory limits exceeded. %SYSTEM-F-ABORT, abort %MMS-F-ABORT, For target BUILD$OUTPUT:TESTFILE.OBJ, CLI returned abort status: %X0000002C. -SYSTEM-F-ABORT, abort The testfile.cxx is basically empty but includes a header which looks basically as below... #include <map> #include <string> typedef map < string, string, less<string> > fooMap; There is no declaration in the source of type fooMap, the problem appears to be in just defining the type fooMapin the header. I believe there is possibly a compiler problem with the imbedded string template type in the map definition. Defining a similar map type using integer types is fine. I have increased quotas, working sets, etc... quite considerably to no avail. Any ideas ?? Has anyone seen this before ?? Ian Lucas. Systems Integration Engineering Gold Coast, Australia
T.R | Title | User | Personal Name | Date | Lines |
---|---|---|---|---|---|
3464.1 | not reported but fixed | HNDYMN::MCCARTHY | A Quinn Martin Production | Tue Feb 25 1997 05:54 | 1 |
The problem has been fixed in the development stream. | |||||
3464.2 | a little more info | DECC::J_WARD | Tue Feb 25 1997 09:10 | 17 | |
The problem occurs only on VAX/VMS when you declare a map<string, anyothertype>. The actual memory was not running out, there was a internal buffer that was being overwritten because the template name was too long (remember this expands to an rb_tree of a basic_string of a char, char_trait<char>, allocator<char>, etc... I don't know of a workaround, unless you want to use the old String class (the non-standard one). This will probably work because the old String class wasn't templatized and therefore the expanded template name would be shorter. Or use just a const char* ): As mentioned in .1, we considered it a high priority bug to fix when we discovered the problem and it will be fixed in V5.6. |