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 03:10:21PM -0500, Benjamin Kosnik wrote:
> 
> > > I'd think you can just go ahead with the plot to have both allocators
> > > available all the time. Add both the malloc_alloc_template, and the
> > > pool_alloc_template instantiations. These new symbols can be put into
> > > the GLIBCPP_3.2.1 version, or GLIBCPP_3.3, so that linkage is
> > > versioned.

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.

> > I agree that they can both be available all the time, but the default
> > allocator used by the STL containers can only be one of them.  To me,
> > there is value in being able to swap the malloc-based allocator in
> > underneath everything, even if it means I have to recompile all
> > application code.  I don't think it's possible to do things as
> > efficiently and not have to recompile.
> 
> Right.
> 
> Then the --enable flag becomes --enable-default-allocator or whatever. 

I have tentatively changed this to --enable-pool-allocator, with the
disabled state being -D_GLIBCPP_USE_MALLOC=1.

> Sounds like you are on the right track...

To be honest, I don't think I've ever been more confused :)  I don't
know how symbol versioning can be used to prevent linking object files
that were compiled with different _GLIBCPP_USE_MALLOC settings.  I
tried quite a lot, but unless each compiled object has an undefined
symbol in it that is resolved by the library, I don't see how
versioned symbols even apply.  I'm testing entirely with a statically
linked libstdc++, too, BTW, to make sure that works.  I want to detect
the mismatch at initial link time, not just when the shared library is
loaded.

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.

Sorry I'm not being much help :(

-- 
------------------------------------------------------------------
Brad Spencer - spencer@infointeractive.com - "It's quite nice..."
Systems Architect | InfoInterActive Corp. | A Canadian AOL Company


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