Re: EEEEKS! The mangling changed!

[Carlo Wood <carlo at alinoe dot com>]

On Tue, Dec 02, 2003 at 02:56:27PM -0600, Loren James Rittle wrote:
> Fully agreed.  __gnu_norm::vector<> is not a __gnu_debug::vector<>
> even if both can be mapped to std::vector<> with 'using' statements.
> We should not make changes to aid debugging tools, if they make actual
> debugging harder.  I could support a scheme where std::__x::y implied
> std::y for external tools that want to optionally hide such details.

I don't see the difference between std::__gnu_xyz and ::__gnu_xyz,
they are both completely under the control of the gcc developers.

But, if this can be agreed on, and transforming ::__gnu_norm into ::std
cannot, then I am just as happy with it.

Needless to remark that indeed, in debugging mode, this transformation
will not make debugging [std::]__gnu_debug:: any easier.  But that is
trivial; therefore we might as well concentrate on the default case
(normal mode).

Making decisions in cases like this is difficult :), there is no
"best" way - so for technical nerds like us there is no way to
make clear that a single solution is the best.

I think that I could prove however that it is possible to define a
mathematical precise equivalence between std:: and [std::]__gnu_norm::,
so that there would be no disadvantage for users who don't know
about __gnu_norm (or are just not used to think in terms on
__gnu_norm).  [ We'd still have to demand that they learn to think
in terms of __gnu_debug:: when actually using the debug mode, but
they will have to do that anyway. ]

So, from that point of view, there is a slight advantage: the users
won't have to learn anything new in normal mode, and all debug tools
will continue to work as easy as before, in normal mode.

[ In order to actually make the decision to do this, or not, we need
some authority... one of the things that annoys me most often as a
beginning gcc developer is that I have still no idea who is the
boss here :/ (for certain topics).  But let me start a new thread
about this topic. ]

-- 
Carlo Wood <carlo@alinoe.com>