This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: libstdc++/4219: stl_alloc using -D__USE_MALLOC fails
- To: bjornw at planetarion dot com, gcc-bugs at gcc dot gnu dot org, gcc-prs at gcc dot gnu dot org, ljrittle at gcc dot gnu dot org, nobody at gcc dot gnu dot org
- Subject: Re: libstdc++/4219: stl_alloc using -D__USE_MALLOC fails
- From: ljrittle at gcc dot gnu dot org
- Date: 4 Sep 2001 21:02:27 -0000
Synopsis: stl_alloc using -D__USE_MALLOC fails
Responsible-Changed-From-To: unassigned->ljrittle
Responsible-Changed-By: ljrittle
Responsible-Changed-When: Tue Sep 4 14:02:27 2001
Responsible-Changed-Why:
Look like mine.
State-Changed-From-To: open->feedback
State-Changed-By: ljrittle
State-Changed-When: Tue Sep 4 14:02:27 2001
State-Changed-Why:
BTW, I think it would be a good idea to make the
change you spotted.
Is there a reason why you can't follow this advice on
the new way to use the malloc interface in your application
(from ./include/bits/c++config but see the primary
documentation on the matter as well):
// Default to the typically high-speed, pool-based allocator (as
// libstdc++-v2) instead of the malloc-based allocator (libstdc++-v3
// snapshots). See libstdc++-v3/docs/html/17_intro/howto.html for
// details on why you don't want to override this setting. Ensure
// that threads are properly configured on your platform before
// assigning blame to the STL container-memory allocator. After doing
// so, please report any possible issues to libstdc++@gcc.gnu.org .
// Do not blindly #define __USE_MALLOC here or on the command line.
The problem with users defining __USE_MALLOC on the command
line is that it is a subtle ABI change that may cause you
problems...
http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=4219&database=gcc