Re: std::string exorcism hiccup

[Phil Edwards <phil at jaj dot com>]

On Sun, Jun 16, 2002 at 12:55:14PM +1200, Tony Bryant wrote:
> > 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,

Boggling the mind is, I've decided, my purpose in life.

We already have such ripple effects in place now; __USE_MALLOC comes to mind.
Both that scheme and my pipe dream ripple all through the memory allocation
areas of code, but don't actually alter anything else.  The /behavior/
is changed on the global scale, but the majority of the libstdc++.a code
is bitwise identical.

(I'm going to go out on a limb and mention that those sorts of design
hooks appeal to me.  I want to change /one/ parameter in /one/ place,
not many parameters in many places.)


> 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).

I don't think I agree, but until I have time to actually work up an example
of code, I won't claim it can be easily done.  (We get too many of those
claims without code already, I don't want to add to it.)  Give me a few days.


Phil

-- 
If ye love wealth greater than liberty, the tranquility of servitude greater
than the animating contest for freedom, go home and leave us in peace.  We seek
not your counsel, nor your arms.  Crouch down and lick the hand that feeds you;
and may posterity forget that ye were our countrymen.            - Samuel Adams