Related articles |
---|
Name mangling youngwk@yahoo.com (Young Wei Kuan) (2001-07-01) |
Re: Name mangling thant@acm.org (Thant Tessman) (2001-07-02) |
Re: Name mangling fjh@cs.mu.OZ.AU (2001-07-03) |
Re: Name mangling toon@moene.indiv.nluug.nl (Toon Moene) (2001-07-06) |
Re: Name mangling alainm@cup.hp.com (Alain Miniussi) (2001-07-06) |
Re: Name mangling dosreis@cmla.ens-cachan.fr (Gabriel Dos Reis) (2001-07-17) |
Re: Name mangling alainm@cup.hp.com (Alain Miniussi) (2001-07-18) |
Re: Name mangling dosreis@cmla.ens-cachan.fr (Gabriel Dos Reis) (2001-07-23) |
From: | Alain Miniussi <alainm@cup.hp.com> |
Newsgroups: | comp.compilers |
Date: | 18 Jul 2001 20:01:07 -0400 |
Organization: | HP |
References: | 01-07-008 01-07-027 01-07-038 01-07-047 01-07-071 |
Keywords: | C++ |
Posted-Date: | 18 Jul 2001 20:01:07 EDT |
Gabriel Dos Reis wrote:
> Toon Moene <toon@moene.indiv.nluug.nl> writes:
> | the new one is more efficient (leads to shorter mangled names). At
> | least, that's what I recall - IANAC++Guru.
> Your recollection is right. The new mangling scheme avoids repeated
> names. Try mangling and demangling "T" defined as
>
> using namespace std;
> typedef multimap<string, multiset<vector<list<vector<double> > > > > T;
This is a little bit unfair :-) you are using a lot of abbreviations
in that one ("std::string" is specificaly recognized and mangled as
"Ss" instead of (being mangled as a plain)
"std::basic_string<char,::std::char_traits<char>,::std::allocator<char>
>" same thing for the implicit "std::allocator", "std" is compressed
in "st"... ok that last one is not...).
If you want to illustrate the substitution mechanism, you should not
rely on the catalog, or people are going to systematicaly expect a
miracle :-) Still, it is true that this mangling is more efficient. As
an approximation, it could be said that most of the saving comes from
the fact that a given source identifier only appears once in the
mangled name.
Alain
Return to the
comp.compilers page.
Search the
comp.compilers archives again.