mt_allocator: static DE-initialization order fiasco?

[Paolo Carlini]

Carlo Wood wrote:

>In that case, the only way one can write a test case
>would be by explicitely creating a memory pool oneself.
>Before I put time into that I'd prefer it if you first
>answer my question whether or not __mt_alloc is to
>be considered 'external interface' that a user may use
>or not.
>
Yes, sorry, but probably, we (I?) already answered this kind of
question some time ago... Anyway, __mt_alloc is not external
interface, in the sense that is not part of the standard and is "only"
used by std::allocator to implement its functionalities.

However, besides having an additional template parameter (the
policy) and the wrong name, actually *is* a complete allocator,
and the real std::allocator that the user is supposed to use is just a
very thin wrapper around it! Have a look to include/bits/allocator.h
+ config/allocator/mt_allocator_base.h. You can actually come
to this same conclusion also from testsuite/ext/mt_allocator
where __mt_alloc is used directly in order to test it irrespective
of the |--enable-libstdcxx-allocator option passed at build
time.

|Therefore, if you are getting into serious troubles using __mt_alloc
directly, the same will happen if you just use std::allocator. Consider
that mt_allocator is now the default in the build, therefore, if you
just select the right policy via a typedef in include/ext/mt_allocator.h
and rebuild the library you can very easily double check what I
said.

Please, if you have a small testcase contribute it.

Thanks,
Paolo.