Re: default allocator, overriding @ runtime

[Benjamin Kosnik <bkoz at redhat dot com>]

>Some people want to use a different allocator (by default) for all of
>stl.  I'd still like to be able to turn it off at runtime.

Others have also indicated that this would be a useful feature.

>Is the best/only way to replace the default allocator to muck with 
>
>    libstdc++-v3/include/bits/stl_alloc.h
>
>And just change the code?

That's currently the only way to change the behavior of std::allocator.

Of course, the best (only?) way to specify an allocator for an STL
container is to specify the allocator as part of the STL container's
type. (There's a template parameter on these types just for this
purpose....)

-----------

The following comments are only applicable to mainline gcc.

I'd always assumed, based on the old allocator setup, that switching
allocators at runtime was a no-go.

However, now that I look at current mainline code, I think it's closer
but still impossible.

An advantage of the current derivation strategy is that std::allocator
uses the base allocator for all the non-trivial member functions. Thus,
allocate() becomes a uniquely-mangled call...

Take a look at this, in part from testsuite/ext/allocators.cc:

#include <memory>

void check_allocator()
{
  using namespace std;
  typedef allocator<int> allocator_type;

  allocator_type a;
  allocator_type::pointer p = a.allocate(10);
  a.deallocate(p, 10);
}

int main()
{
  check_allocator();
  return 0;
}

%COMP.sh "-g -c -O0" ~/alloc_switch.cc

%nm alloc_switch.o
         U __gxx_personality_v0
0000007c T main
         U _Unwind_Resume
00000000 T _Z15check_allocatorv
         U _ZdlPv
00000000 W _ZN9__gnu_cxx13new_allocatorIiE10deallocateEPij
00000000 W _ZN9__gnu_cxx13new_allocatorIiE8allocateEjPKv
00000000 W _ZN9__gnu_cxx13new_allocatorIiEC2Ev
00000000 W _ZN9__gnu_cxx13new_allocatorIiED2Ev
00000000 W _ZNSaIiEC1Ev   // problem
00000000 W _ZNSaIiED1Ev  // problem
         U _Znwj

So, the (only remaining?) problem is that the constructors and
destructors for std::allocator (weakly defined, assume for a moment that
non-weak systems don't exist) would change, depending on the base
external allocator.

Thus, multiple object files could not merge the weak ctor/dtor symbols,
as they'd be different. A show-stopper, to be sure.

-benjamin