type_info::name question

type_info::name question

[Ryszard Kabatek]

Is there any possibility to get the class name from type_info::name?

For typeid(string).name() I get:
't12basic_string3ZcZt18string_char_traits1ZcZt24__default_alloc_template2b1i0'.


Ryszard Kabatek

Martin-Luther University Halle-Wittenberg
Department of Physical Chemistry
Geusaer Str. 88, 06217 Merseburg, Germany
Tel. +49 3461 46 2487 Fax. +49 3461 46 2129
e-mail: kabatek@chemie.uni-halle.de

Re: type_info::name question

[Alexandre Oliva]

Ryszard Kabatek <rysio@rumcajs.chemie.uni-halle.de> writes:

> Is there any possibility to get the class name from type_info::name?

You might run `c++filt' and feed it the result of type_info::name(),
but you may prefer to create a library containing the unmangler
functions from c++filt and link your program with it.

-- 
Alexandre Oliva
mailto:oliva@dcc.unicamp.br mailto:aoliva@acm.org
http://www.dcc.unicamp.br/~oliva
Universidade Estadual de Campinas, SP, Brasil

Re: type_info::name question

[Thomas Kunert]

Alexandre Oliva wrote:
> 
> Ryszard Kabatek <rysio@rumcajs.chemie.uni-halle.de> writes:
> 
> > Is there any possibility to get the class name from type_info::name?
> 
> You might run `c++filt' and feed it the result of type_info::name(),
> but you may prefer to create a library containing the unmangler
> functions from c++filt and link your program with it.

IMHO, type_info::name isn't useful at all if it returns some cryptic
string. Is there some intention behind that behavior or is it just the
shortest way towards conformance? Almost everybody, who wants to use
that function, would like it to return some readable typename. The
compiler already contains unmangler code, doesn't it? Of course I know
there are many more important thing to do, and it's easier to request a
feature than providing a patch, but perhaps someone has some sparetime
:)

--
Thomas Kunert

Re: type_info::name question

[Alexandre Oliva]

Thomas Kunert <kunert@physik.tu-dresden.de> writes:

> IMHO, type_info::name isn't useful at all if it returns some cryptic
> string.

type_info::name *isn't* useful at all, as defined in the standard.  I
particularly appreciate the fact that the string representation is
compact, albeit not human-readable.  Compactness is more important
that readability when it comes to reducing the size of persistent
object stores, for one.  If you really want a readable representation,
I've already explained that it's just a matter of running c++filt or
embedding it into your application.

-- 
Alexandre Oliva
mailto:oliva@dcc.unicamp.br mailto:aoliva@acm.org
http://www.dcc.unicamp.br/~oliva
Universidade Estadual de Campinas, SP, Brasil

Re: type_info::name question

[Thomas Kunert]

Alexandre Oliva wrote:
> 
> Thomas Kunert <kunert@physik.tu-dresden.de> writes:
> 
> > IMHO, type_info::name isn't useful at all if it returns some cryptic
> > string.
> 
> type_info::name *isn't* useful at all, as defined in the standard.  

Only if one clings to the paper as you do. 
The function is called `name', not `some_arbitrary_string'. IMO, that is
description enough. 

``Implementation defined'' doesn't mean ``as unuseful as possible to
prevent portability problems'' but ``make the best of it, everybody
should know about portability''. And if the function does what it's name
suggests -- giving the name of the type in some readable language -- it
*is* useful.

> If you really want a readable representation,
> I've already explained that it's just a matter of running c++filt or
> embedding it into your application.

Of course I can do that, in fact I have done this a long time ago, to
port some perfectly working code to egcs, but I hate rewriting functions
from the standard library only because of some weird chosen
implementation defined values.

Regards, 
Thomas

Re: type_info::name question

[Alexandre Oliva]

Thomas Kunert <kunert@physik.tu-dresden.de> writes:

> Alexandre Oliva wrote:

>> type_info::name *isn't* useful at all, as defined in the standard.  

> ``Implementation defined'' doesn't mean ``as unuseful as possible to
> prevent portability problems'' but ``make the best of it, everybody
> should know about portability''. And if the function does what it's name
> suggests -- giving the name of the type in some readable language -- it
> *is* useful.

Then please tell us what the following program should print [note: it
does not compile with egcs 1.1, only with newer snapshots]:

#include <iostream>
#include <string>
#include <typeinfo>

template <typename T>
struct foo {
  foo() {
    struct test {
      test() { std::cout << typeid(*this).name() << std::endl; }
    } mytest;
  }
};

main() {
  foo<std::string> bar;
}

If you can find a readable and portable representation of that, then
you're free to try to implement it within egcs.

>> If you really want a readable representation, I've already
>> explained that it's just a matter of running c++filt or embedding
>> it into your application.

> Of course I can do that, in fact I have done this a long time ago, to
> port some perfectly working code to egcs, but I hate rewriting functions
> from the standard library only because of some weird chosen
> implementation defined values.

On how many other compilers does your perfectly working code would run 
before you ported it to egcs?

-- 
Alexandre Oliva
mailto:oliva@dcc.unicamp.br mailto:aoliva@acm.org
http://www.dcc.unicamp.br/~oliva
Universidade Estadual de Campinas, SP, Brasil

Re: type_info::name question

[Thomas Kunert]

Alexandre Oliva wrote:
> 
> Thomas Kunert <kunert@physik.tu-dresden.de> writes:
> 
> > Alexandre Oliva wrote:
> 
> >> type_info::name *isn't* useful at all, as defined in the standard.
> 
> > ``Implementation defined'' doesn't mean ``as unuseful as possible to
> > prevent portability problems'' but ``make the best of it, everybody
> > should know about portability''. And if the function does what it's name
> > suggests -- giving the name of the type in some readable language -- it
> > *is* useful.
> 
> Then please tell us what the following program should print [note: it
> does not compile with egcs 1.1, only with newer snapshots]:
> 
> #include <iostream>
> #include <string>
> #include <typeinfo>
> 
> template <typename T>
> struct foo {
>   foo() {
>     struct test {
>       test() { std::cout << typeid(*this).name() << std::endl; }
>     } mytest;
>   }
> };
> 
> main() {
>   foo<std::string> bar;
> }
> 
> If you can find a readable and portable representation of that, then
> you're free to try to implement it within egcs.

What means `portable' in that case? I don't expect the same result on
all platform, I just expect any readable representation of the typename.
How about the string used for error messages? IRIX C++ gives `test', IMO
even this is OK.

Perhaps I should give an example for my intended purpose. 
I've a library for parsing command line options. Some of these options
take parameters. There is an automatic help facility: The library can,
without any application code, print the type of the expected parameters.

Implementing it is my weak point: Even if I was able to do the hacking,
I can't provide the necessary paperwork. Therefore I take the easier
way: I just demand the desired features :-)
Please don't take it wrong: I'm _very_ satisfied with EGCS, and use it
for all my programming. I just want to make a proposal on how to make it
even better. 
 
> 
> On how many other compilers does your perfectly working code would run
> before you ported it to egcs?

One. SGI-C++. But I switched to a better compiler :).

Regards, 
Thomas

Re: type_info::name question

[Martin von Loewis]

> What means `portable' in that case? I don't expect the same result on
> all platform, I just expect any readable representation of the typename.

Define 'readable'. I can certainly read the strings g++ produces right
now.

> Perhaps I should give an example for my intended purpose. 
> I've a library for parsing command line options. Some of these options
> take parameters. There is an automatic help facility: The library can,
> without any application code, print the type of the expected parameters.

See, this is exactly the problem: Your intended purposes clashes with
other peoples uses of this function. Other people use it for
externalization of objects, and expect reliable unique identification.
Return 'test' for a class that is nested in a template would then just
break.

I don't think anything will happen about this in the near future, so
you'll have to stick with linking libiberty.

Regards,
Martin

Re: type_info::name question

[Martin von Loewis]

> IMHO, type_info::name isn't useful at all if it returns some cryptic
> string. Is there some intention behind that behavior or is it just the
> shortest way towards conformance? 

I believe the shortest way to conformance would be

type_info::name()
{
  return "";
}

The standard does not mandate that different type_infos give different
names.

> The compiler already contains unmangler code, doesn't it?

The compiler doesn't, libiberty does. Of course, the compiler can just
pretty-print class names, as it does in error messages.

My feeling is that type_info::name isn't that useful, period. OTOH, it
probably wouldn't be difficult to change the g++ implementation of it.
We just need some volunteer.

Regards,
Martin

Re: type_info::name question

[Todd Vierling]

On Mon, 14 Sep 1998, Ryszard Kabatek wrote:

: Is there any possibility to get the class name from type_info::name?
: 
: For typeid(string).name() I get:
: 't12basic_string3ZcZt18string_char_traits1ZcZt24__default_alloc_template2b1i0'.

This is the mangled name of the fully qualified class "string".  If you add
two underscores (three on platforms that need leading underscores) and run
it through c++filt, you get something useable, but it still won't say
"string"--it cannot in this case, since string is a template.

The name is mangled such that it is machine-useable.  The output of
typeinfo::name() isn't guaranteed to be human-readable.

-- 
-- Todd Vierling (Personal tv@pobox.com; Bus. todd_vierling@xn.xerox.com)

Re: type_info::name question

[Nathan Myers]

Thomas Kunert wrote:
> 
> Alexandre Oliva wrote:
> >
> > Ryszard Kabatek <rysio@rumcajs.chemie.uni-halle.de> writes:
> >
> > > Is there any possibility to get the class name from type_info::name?
> >
> > You might run `c++filt' and feed it the result of type_info::name(),
> > but you may prefer to create a library containing the unmangler
> > functions from c++filt and link your program with it.
> 
> IMHO, type_info::name isn't useful at all if it returns some cryptic
> string. Is there some intention behind that behavior or is it just the
> shortest way towards conformance? Almost everybody who wants to use
> that function, would like it to return some readable typename.

Sorry, I don't agree.  The industrial use of type_info::name is to 
generate a key to represent a type for streamed object representations.
One desirable quality of this name is that it be short and quickly
generated.  Squangling minimizes length. 

However, tying the RTTI name to the mangling scheme of the moment makes 
it harder to be compatible with other implementations, or across versions 
of egcs itself, which could be important for persistent data.  I imagine 
a future need for a compiler flag that chooses the RTTI name convention, 
choosing between mangling, squangling, and some POSIX- or CORBA-specified 
convention.

Nathan Myers
ncm@cantrip.org

Re: type_info::name question

[Martin von Loewis]

> Sorry, I don't agree.  The industrial use of type_info::name is to 
> generate a key to represent a type for streamed object representations.

Unfortunately, this is a non-portable use. The standard does not
guarantee any properties of the string returned, not even uniqueness
in some sense.

> I imagine a future need for a compiler flag that chooses the RTTI
> name convention, choosing between mangling, squangling, and some
> POSIX- or CORBA-specified convention.

I'd rather make this an explicit GNU extension, giving it a different
method name as well. Using CORBA conventions might not even be a bad
idea,

namespace X{
  class Y{
  };
};

char *s = typeid(X::Y).__repository_id();

might initialize s to "gnu:X/Y:1.0" or some such. Telling people they
can use type_info::name for this application is bad advice.

Regards,
Martin

Re: type_info::name question

[Nathan Myers]

Martin von Loewis wrote:
> 
> > Sorry, I don't agree.  The industrial use of type_info::name is to
> > generate a key to represent a type for streamed object representations.
> 
> Unfortunately, this is a non-portable use. The standard does not
> guarantee any properties of the string returned, not even uniqueness
> in some sense.  ...  Telling people they
> can use type_info::name for this application is bad advice.

The definition is left "implementation-defined" in the standard 
_specifically_ to allow implementers to define something useful.  
The intent was to allow users to write code that is portable 
among those implementations which support the features required.  
One thing guaranteed about a GNU-only extension is that code that 
uses it won't be conforming.  With member name() there is at least 
a chance, if the compiler implementors co-operate.

That is, at least a program will be able to talk to another
program compiled with the same-version compiler, if the feature 
is implemented meaningfully at all; maybe with programs compiled
other versions of the same compiler, if the implementer has 
documented the format; and possibly with code compiled with 
some other compilers, if the definition references another 
standard.  The last is not possible with a GNU-only extension.

This is not to say that GNU extensions in this area wouldn't be
useful (e.g. __mangle(), __squangle(), __corba()).  It is only 
to say that the name() member should be settable at compile time 
to be synonymous with any of the GNU extensions.

Nathan Myers
ncm@cantrip.org

Re: type_info::name question

[Martin von Loewis]

> uses it won't be conforming.  With member name() there is at least 
> a chance, if the compiler implementors co-operate.

This is what makes this approach particularly bad. Using the standard
method will make it compile, yet it works in an implementation-defined
way. Most users won't be aware of these details, and run into problems
without being warned. If you use an extension, you *know* you need to
consider this code when using a different compiler.

Using an additional method might not be good, because you'd have to
use macros to replace them on a different compiler. A global function

char* __mangle(type_info&);

might be better; one could then implement this in different ways
depending on the compiler.

> This is not to say that GNU extensions in this area wouldn't be
> useful (e.g. __mangle(), __squangle(), __corba()).  It is only 
> to say that the name() member should be settable at compile time 
> to be synonymous with any of the GNU extensions.

I'm not against g++ giving some additional guarantees about the string
returned by name(); I just think it is bad advise to use name() as
long as there no guarantees (unless it is used for debugging).

For example, g++ could warn if name is called, while the user did not
request specific semantics for it.

Regards,
Martin

Re: type_info::name question

[Nathan Myers]

Martin von Loewis wrote:
> > uses it won't be conforming.  With member name() there is at least
> > a chance, if the compiler implementors co-operate.
> 
> This is what makes this approach particularly bad. Using the standard
> method will make it compile, yet it works in an implementation-defined
> way. Most users won't be aware of these details, and run into problems
> without being warned. 

I can't accept that.  The RTTI feature is a hook for support of object
databases and the like.  Anybody using it is painfully aware of the 
cross-platform issues.


> I'm not against g++ giving some additional guarantees about the string
> returned by name(); I just think it is bad advice to use name() as
> long as there no guarantees (unless it is used for debugging).
> 
> For example, g++ could warn if name is called, while the user did not
> request specific semantics for it.

This would be a good thing.  In the absence of such a request the RTTI 
records could be smaller, which would also be a good thing.

Nathan Myers
ncm@cantrip.org

Re: type_info::name question

[Jason Merrill]

>>>>> Thomas Kunert <kunert@physik.tu-dresden.de> writes:

 > Alexandre Oliva wrote:
 >> 
 >> Ryszard Kabatek <rysio@rumcajs.chemie.uni-halle.de> writes:
 >> 
 >> > Is there any possibility to get the class name from type_info::name?
 >> 
 >> You might run `c++filt' and feed it the result of type_info::name(),
 >> but you may prefer to create a library containing the unmangler
 >> functions from c++filt and link your program with it.

 > IMHO, type_info::name isn't useful at all if it returns some cryptic
 > string. Is there some intention behind that behavior or is it just the
 > shortest way towards conformance?

Two reasons:

 1) The mangled name is shorter, so the RTTI overhead is lower.
 2) The mangled name is unique.

Jason

Re: type_info::name question

[Ryszard Kabatek]

Jason Merrill wrote:

> >>>>> Thomas Kunert  writes:
>
>  > Alexandre Oliva wrote:
>  >>
>  >> Ryszard Kabatek  writes:
>  >>
>  >> > Is there any possibility to get the class name from
>  >> > type_info::name?
>  >>
>  >> You might run `c++filt' and feed it the result of type_info::name(),
>  >> but you may prefer to create a library containing the unmangler
>  >> functions from c++filt and link your program with it.
>
>  > IMHO, type_info::name isn't useful at all if it returns some cryptic
>  > string. Is there some intention behind that behavior or is it just
>  > the shortest way towards conformance?
>
> Two reasons:
>
>  1) The mangled name is shorter, so the RTTI overhead is lower.
>  2) The mangled name is unique.
>
> Jason

Yes, the mangled name is `very' unique. 
It may change in the next egcs version.

What value do return other comilers for type_info::name?


Ryszard Kabatek
---
Martin-Luther University Halle-Wittenberg
Department of Physical Chemistry
Geusaer Str. 88, 06217 Merseburg, Germany
Tel. +49 3461 46 2487 Fax. +49 3461 46 2129

Re: type_info::name question

[kunert]

Alexandre Oliva wrote:
> 
> Thomas Kunert <kunert@physik.tu-dresden.de> writes:
> 
> > IMHO, type_info::name isn't useful at all if it returns some cryptic
> > string.
> 
> type_info::name *isn't* useful at all, as defined in the standard.  

Only if one clings to the paper as you do. 
The function is called `name', not `some_arbitrary_string'. IMO, that is
description enough. 

``Implementation defined'' doesn't mean ``as unuseful as possible to
prevent portability problems'' but ``make the best of it, everybody
should know about portability''. And if the function does what it's name
suggests -- giving the name of the type in some readable language -- it
*is* useful.

> If you really want a readable representation,
> I've already explained that it's just a matter of running c++filt or
> embedding it into your application.

Of course I can do that, in fact I have done this a long time ago, to
port some perfectly working code to egcs, but I hate rewriting functions
from the standard library only because of some weird chosen
implementation defined values.

Regards, 
Thomas

Re: type_info::name question

[Jason Merrill]

How would people feel about including the demangler in libgcc, and calling
from type_info::name?

Jason

Re: type_info::name question

[H.J. Lu]

> 
> How would people feel about including the demangler in libgcc, and calling
> from type_info::name?
> 
> Jason
> 

I'd like to see a mangler in libgcc, even a simple one. It may be
useful for dlsym () and other things.

-- 
H.J. Lu (hjl@gnu.org)

Re: type_info::name question

[Nathan Myers]

Jason Merrill wrote:
> 
> How would people feel about including the demangler in libgcc, and calling
> from type_info::name?

People are complaining about RTTI overhead already.  The purpose
of name() was to provide a hook for serializing objects, so its
only important quality is uniqueness (for types with external linkage). 
A separate function that yields a "pretty" type name given the result 
of name() would probably be useful for some people.

Nathan Myers
ncm@cantrip.org

Re: type_info::name question

[Mike Stump]

> To: kunert@physik.tu-dresden.de, egcs@cygnus.com
> From: Jason Merrill <jason@cygnus.com>
> Date: 11 Oct 1998 13:12:38 -0700

> How would people feel about including the demangler in libgcc, and
> calling from type_info::name?

The only concerns I guess I have are:

kankakee bash[42] size cxxmain.o 
   text    data     bss     dec     hex filename
  24349     120       4   24473    5f99 cxxmain.o

and the fact it calls malloc.  If it is only ever linked in when name
is called, it might not be too big.  Having it throw bad_alloc seems
better than xmalloc stuff, that's easy to fix.  Having sometimes throw
bad_alloc seems bad.  Also, if it allocates stuff, who deallocs?  The
Standard dones't have that interface.  Also, if it is a static buffer,
there is nothing in the standard that says the lifetime expires that
quickly.  So, I thinking the only solution would be to just put the
non demangled version in the .o file to begin with.  And if we do
that, then I worry about the total size of the .o files growing yet
some more.  Every 5% we add, is another 5% we don't get back.  :-(

Re: type_info::name question

[Mark Mitchell]

>>>>> "Mike" == Mike Stump <mrs@wrs.com> writes:

    >> To: kunert@physik.tu-dresden.de, egcs@cygnus.com From: Jason
    >> Merrill <jason@cygnus.com> Date: 11 Oct 1998 13:12:38 -0700

    >> How would people feel about including the demangler in libgcc,
    >> and calling from type_info::name?

    Mike> The only concerns I guess I have are:

    Mike> kankakee bash[42] size cxxmain.o text data bss dec hex
    Mike> filename 24349 120 4 24473 5f99 cxxmain.o

I agree with Mike.  I think the two consistent approaches are to put
the fully demangled names directly into the object file, and to keep
things as they are.  I don't really think the demangler should be in
libgcc.

I think the right solution is to install a new header file with a well
documented demangling interface, along with the code to do the
demangling.  We don't need the full complexity of demangle.h, just
__demangle_name (const char*) or some such.  On many compilers, this
is a separate library (libdemangle), and I think that's what we should
do, too; it's a C++-specific (and maybe Java) concept, and it doesn't
really need to take up space in libgcc.a.  This library should be
created/installed only if LANGUAGES contains C++ (Java?).

Another advantage of this approach over your suggestion is that you
can use the demangler for more than just RTTI: for example, you could
demangle names used with dlsym and friends.

-- 
Mark Mitchell 			mark@markmitchell.com
Mark Mitchell Consulting	http://www.markmitchell.com