------- Comment #12 from bkoz at gcc dot gnu dot org  2005-11-17 22:15 -------

Here you go Jason. Actually, it looks like I have a complete archive of most
parts of this discussion, the related material, code samples, issues, etc. If
you would like, I will tar it up and put it in this pr. Or, if you are
interested, I can send it to you (or others) via private email. 

I should have just put this stuff in post-Kona: sorry. I need to get better
about this kind of thing.

Anyway. Jason, I think making the namespace nested is fine. Interestingly, I
reviewed these discussions, and it looks like at the time of the debug mode
design discussion, we were wondering about the pros and cons of nested vs.
separate namespaces.

Looks like now we know more about these tradeoffs.

The only drawback that I can see is trying to reduce the size penalty for
mangled names. This is going to be an issue for some people, and we might as
well admit it from the start. 

I'd thought of nested solutions, including the obvious ones:

namespace _6 {
namespace std {

namespace std {
namespace _6 {

but the problem is then that all the specialized compression for narrow std::
types (basic_string, basic_istream, etc) will fall down, and all your names go
through two namespace manglings. I'm not convinced this is such a bad thing,
actually: having non-compressed std:: would mean post-processing of library
binaries with other tools will become much more regular, without substitutions. 

Of course, 

namespace _6 {

also removes the specialized namespace std:: compression, but the fully
qualified name is still within reasonable limits of the current status quo.
This was judged to be the least obese of all options, in terms of symbol size
explosion. (ie _ZNS vs. _ZN2_6).

I must tell you that I would rather have this feature (and a resolution to the
weak symbol vs. shared object problem), and loose compression, than have either
the benefits of compression or a shorter fully qualified name. If I had a magic
wand, of course, I'd pick compression on generic template type name, not
instance name, so that wchar_t and char types would also be compressed 
(ie compress basic_string, not basic_string<char>), plus namespace association.
That might be a way to win back some of the loss if we switch to something like
std::_6 for the namespace.

Anyway.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24660

Reply via email to