This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Slightly better way to __USE_MALLOC


On Thu, Oct 10, 2002 at 07:22:36PM -0300, Brad Spencer wrote:
> 
> The symbols I'm talking about aren't new.  __default_alloc_template
> and __malloc_alloc_template already exist and are already both in the
> GLIBCPP_3.2 version.  I think it would make sense to rename __default
> to __pool, but it's probably too late for that now.

Too late for the 3.2 series, but nobody's expecting the library to have
the same ABI for 3.[34].  There're still too many useful changes to make.
Like this one.  :-)

On my whiteboard I have a Grand Master Plan to reorganize the stl_alloc.h
header, making things more generic, and allowing multiple allocation
schemes to be instantiated in the library.  For it, I was freely changing
the names of the internal classes.

(Coding it keeps getting pushed back...)


> I see now why a "patch would be appreciated". :)  I'm starting to
> question the value of having both __malloc and __default templates
> instantiated in the library, too.

Then you can in theory write

    std::vector<foo,the_malloc_allocator>     x;
    std::vector<foo,the_default_allocator>    y;

without needing to carry around instantiations of one of those allocators
in your code, which is wasteful at best and could lead to multiple symbol
definitions at worst.


Phil

-- 
I would therefore like to posit that computing's central challenge, viz. "How
not to make a mess of it," has /not/ been met.
                                                 - Edsger Dijkstra, 1930-2002


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]