EEEEKS! The mangling changed!
Carlo Wood
carlo@alinoe.com
Wed Dec 3 01:49:00 GMT 2003
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>
More information about the Libstdc++
mailing list