std::string exorcism hiccup

[Tony Bryant]

> I floated the idea the last type the question of allocators came up, and
> the (admittedly vaguely ugly) idea of (b) was not so much "shot down" as
> "vomited on" due to its ugliness.  :-)

If it acheives the goal It'll look like a perfect 10.

>
> The ugly part I think is that the different mangling would not actually
> apply to std::allocator, but rather to a type buried way down in the
> instantiation chain.  Everything would still work -- the changed default
> pool allocator would be implicitly instantiated in the user's own object
> files -- but it would have to be well-documented.
>
> Opinions, anyone?  (go go gadget asbestos underwear!)

The ripple effect of such a scheme boogles the mind, i.e. it would need to 
apply to almost everything currently compilied into libstdc++.a, 

e.g. you'd need to end up with a different std::string mangling to 
differentiate from the libstdc++.a std::string from the user's std::string, 
(since the will be effecitively different types).

but that then begs the question of template instatiation - will the user need 
to explicity instantiate their own std::string? I guess this can't be done 
automatically since that's why libstdc++.a exists already.

Have I missing the trick here? How do you propose the user will select the 
paramters for their new allocator?