Matt Austern wrote:
>
> "Bill Wade" <bill.wade@stoner.com> writes:
>
> > True, but not that easy.
> >
> > What would the string be for types in unnamed namespaces?  Duplicate type
> > names may appear in unnamed namespaces in seperate compilation units.
> >
> > What would the string be for unnamed types?
> >   struct{int i;} i;
> >   enum { FOO,BAR } j;
> >

What about: {unnamed}

Ok, this wouldn't be suitable for persistance - but I wouldn't
expect unnamed types suitable for persistance, anyway (I can't
even write a new-expression for them!)

> > I still think a standard naming would be nice, even if it didn't provide
> > unique (or repeatable) strings for some restricted cases.
>

So do I.

> There's another problem: there are a few nasty corners within the C++
> type system where types cannot be represented directly.  That is,
> there are some kinds types that are impossible to write without an
> intermediate typedef.  What would you expect the printed form of one
> of those type names to be?

There's no reason why the string would have to pass the C++ parser.
It just has to be unique for all "global" types (i.e. all types that
in principle could be accessed from anywhere in the program).

In another post, David Vandevoo gives the example:

        #include <iostream>
        #include <typeinfo>

        extern "C" typedef void C_function();
        extern "C++" typedef void CPP_function();
        void f(C_function*, CPP_function*) {}

        int main() {
           std::cout << typeid(f).name() << std::endl;
        }


The result could f.ex. be standardized as:

void(void(extern"C"*)(),void(*)())

which would not parse as valid C++ expression, but would be
uniqe and understandable (as far as function types can be
understandable at all).

Another example:

extern "C" void f(int);

could result in

void extern"C"(int)

The only real problem are indeed all those cases where omitted names
occur.
In this case, probably the best solution would be to leave the
"name" of the unnamed quantity implementation defined, except
that it must start with "{" and end with "}", so it's easy to
conclude that there is an implementation dependency.

So for the code

#include <iostream.h>

namespace
{
  class X {};
}

int main()
{
  cout << typeof(X).name();
}

the following results would be legal:

{}::X
{unnamed}::X
{unnamed namespace}::X
{namespace 1 of file testtypeof.cc}::X
{testtypeof.cc:._1}::X
{?}::X

but the following would not:

(null)       (i.e. a null pointer)
::X
unnamed::X

Especially the second and third could give you problems, as there
might be a global X defined, and there might be an object or
namespace named "unnamed".
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Todd V. Jonker wrote:
>
> Nick Thurn <nick.thurn@kipling.bain.com.au> wrote
> > Bradd W. Szonye wrote:
> > >     typedef map< type_info *, string, type_ordering > type_map;
> > >
> > >     type_map pmap;
> > >     pmap[ &typeid(Widget) ] = "Widget";
> > >     pmap[ &typeid(Foobar) ] = "Foobar";
> > >     pmap[ &typeid(Grolum) ] = "Grolum";
> >
> > Yes, I already understood this. The point I was trying to make was
> > the programmer should not have to define the strings "Widget"...etc.
> > IMHO it shouldn't be necessary as we have type_info::name().
>
> Another problem with this approach is that it has terrible coupling
> effects.
> You have suddenly forced the linker to include every class you know about
> into every application that uses this map. When you are developing multiple
> applications that share class libraries, this is a very big problem.
>
It's funny that many C++ constructs have this effect, eg inline
functions.
Lakos has 1.5 inches of book about avoiding them! (well, mainly :)

Attempting to remove coupling by decentralising the initialisation of
the "type_map" introduces further funnies such as static init order.
Being able to offload these problems to the runtime is a big advantage
IMHO.

cheers
Nick
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Nick Thurn <nick.thurn@kipling.bain.com.au> wrote
> Bradd W. Szonye wrote:
> >     // type_ordering below is the comparison functor
> >     typedef map< type_info *, string, type_ordering > type_map;
> >
> >     type_map pmap;
> >     pmap[ &typeid(Widget) ] = "Widget";
> >     pmap[ &typeid(Foobar) ] = "Foobar";
> >     pmap[ &typeid(Grolum) ] = "Grolum";
>
> Yes, I already understood this. The point I was trying to make was
> the programmer should not have to define the strings "Widget"...etc.
> IMHO it shouldn't be necessary as we have type_info::name().

Another problem with this approach is that it has terrible coupling
effects.
You have suddenly forced the linker to include every class you know about
into every application that uses this map. When you are developing multiple
applications that share class libraries, this is a very big problem.

. . . Todd V. Jonker . . . . Sr. System Designer. . .
. . . todd@clarit.com . . . . . CLARITECH Corp. . . .
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Bradd W. Szonye wrote:
>
> Jess Holle <jessholl@netcom.com> wrote in article
> <jessholl-2807972236550001@10.0.2.15>...
>
> > By leaving out any attempt to standardize on this type_info::name() is
> > reduced in usefulness from powerful persistence to debug strings!  As I'm
> > sure you realized in your implementation, type_info::name() _could_ be
> > the key to a beautifully simple persistence mechanism if only the return
> > value was standardized.  Not that I can fault the ANSI C++ committee for
> > lack of effort, BUT this was a poor aspect to leave unspecified IMHO.
>
> Again, not unspecified but implementation-defined. Were it "unspecified" in
> standardese, it would indeed be useless. However, you're right;
> type_info::name() is not intended for persistence; type_info::before() is.

Hi Bradd,

Can you explain how it is possible for type_info::before() to be used
for
compiler/platform independent persistence, please spell it out.

cheers
Nick
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Nick Thurn <nick.thurn@mailhost.bain.com.au> wrote in article
<33EAE0F9.62F6@aus.deuba.com>...
>
> Can you explain how it is possible for type_info::before() to be used for
> compiler/platform independent persistence, please spell it out.

Well, I won't give an actual implementation, because I haven't actually
done something like this. However, you can create a map<> using a type_info
pointer for the key, some application-defined identifier for the value, and
a functor object for the ordering relationship. The functor object uses
type_info::before() internally to determine which of the two types is
"less" than the other. Then you build a persistence map:

    // type_ordering below is the comparison functor
    typedef map< type_info *, string, type_ordering > type_map;

    type_map pmap;
    pmap[ &typeid(Widget) ] = "Widget";
    pmap[ &typeid(Foobar) ] = "Foobar";
    pmap[ &typeid(Grolum) ] = "Grolum";

You can write the strings (Widget, Foobar, Grolum) to the persistent
storage and know that they're the same regardless of compiler vendor,
version, or target. I may have some of the syntax not-quite-right, but
that's close. (I also didn't actually write the functor for you because I'm
a bit rusty with them and I don't want to write something totally wrong.)

Hope that helps.

Bradd
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Todd V. Jonker <todd@clarit.com> wrote in article
<01bca276$4bf02040$8d9356cf@newsag5>...
>
> Actually, having a well-defined string is exceedingly useful in many
> contexts. I had to create a whole parallel RTTI mechanism because I
needed
> well-defined names that would be portable across platforms (think
> persistence) and having this feature in the language would prevent a lot
of
> messy work.

All true.

> I don't see why the name cannot be specified in almost all cases, since
> each class has a know, fully-specified identification already. Why not
just
> define the type_info::name() to be the string representation of that, eg,
> "std::vector<int,Allocator<int>>"?  Easy enough, and much more useful.

True, but not that easy.

What would the string be for types in unnamed namespaces?  Duplicate type
names may appear in unnamed namespaces in seperate compilation units.

What would the string be for unnamed types?
  struct{int i;} i;
  enum { FOO,BAR } j;

I still think a standard naming would be nice, even if it didn't provide
unique (or repeatable) strings for some restricted cases.
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

"Bill Wade" <bill.wade@stoner.com> writes:

> True, but not that easy.
>
> What would the string be for types in unnamed namespaces?  Duplicate type
> names may appear in unnamed namespaces in seperate compilation units.
>
> What would the string be for unnamed types?
>   struct{int i;} i;
>   enum { FOO,BAR } j;
>
> I still think a standard naming would be nice, even if it didn't provide
> unique (or repeatable) strings for some restricted cases.

There's another problem: there are a few nasty corners within the C++
type system where types cannot be represented directly.  That is,
there are some kinds types that are impossible to write without an
intermediate typedef.  What would you expect the printed form of one
of those type names to be?
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Matt Austern (austern@mti.sgi.com) wrote:
: There's another problem: there are a few nasty corners within the C++
: type system where types cannot be represented directly.  That is,
: there are some kinds types that are impossible to write without an
: intermediate typedef.  What would you expect the printed form of one
: of those type names to be?

Can you please give an example of one of these types?

--
        Tony Cook - tony@online.tmx.com.au <= testing .procmailrc
                    100237.3425@compuserve.com
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Tony Cook wrote:
>
> Matt Austern (austern@mti.sgi.com) wrote:
> : There's another problem: there are a few nasty corners within
> : the C++ type system where types cannot be represented directly.
> : That is, there are some kinds types that are impossible to write
> : without an intermediate typedef.  What would you expect the
> : printed form of one of those type names to be?
>
> Can you please give an example of one of these types?

 #include <iostream>
 #include <typeinfo>

 extern "C" typedef void C_function();
 extern "C++" typedef void CPP_function();
 void f(C_function*, CPP_function*) {}

 int main() {
    std::cout << typeid(f).name() << std::endl;
 }

Linkage specifiers can only appear in namespace scope.
So, to indicate the linkage of parameters you may need to
use an intermediate typedef.

 Daveed
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Bradd W. Szonye wrote:
>
> Nick Thurn <nick.thurn@mailhost.bain.com.au> wrote in article
> <33EAE0F9.62F6@aus.deuba.com>...
> >
> > Can you explain how it is possible for type_info::before() to be used for
> > compiler/platform independent persistence, please spell it out.
>
> Well, I won't give an actual implementation, because I haven't actually
> done something like this. However, you can create a map<> using a type_info
> pointer for the key, some application-defined identifier for the value, and
> a functor object for the ordering relationship. The functor object uses
> type_info::before() internally to determine which of the two types is
> "less" than the other. Then you build a persistence map:
>
>     // type_ordering below is the comparison functor
>     typedef map< type_info *, string, type_ordering > type_map;
>
>     type_map pmap;
>     pmap[ &typeid(Widget) ] = "Widget";
>     pmap[ &typeid(Foobar) ] = "Foobar";
>     pmap[ &typeid(Grolum) ] = "Grolum";
>

Yes, I already understood this. The point I was trying to make was
the programmer should not have to define the strings "Widget"...etc.
IMHO it shouldn't be necessary as we have type_info::name().

Surely the non-pathological cases *can* be standardized? Who cares if
type_info::name() is implementation defined for stuff declared in
wierd circumstance, such as at function scope or in anonymous unions?
Language lawyers perhaps??

Thanks
Nick
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Bradd W. Szonye <bradds@concentric.net> wrote
> > Bradd W. Szonye wrote:
> > > Jess Holle <jessholl@netcom.com> wrote
> > > >
> > > > type_info::name() can return anything the implementor feels like.
> > >
> > > Well, within certain limits. But, yes, it is implementation-defined.
...
> Oh well, I won't lose any sleep over that. (I'm surprised that there's
not
> even a note giving a suggested value; such as the pointer-to-int
> conversion, which is 'intended to be unsurprising.') After all,
> type_info::before() is more useful and flexible for actual programs, as I
> already pointed out.

Actually, having a well-defined string is exceedingly useful in many
contexts. I had to create a whole parallel RTTI mechanism because I needed
well-defined names that would be portable across platforms (think
persistence) and having this feature in the language would prevent a lot of
messy work.

I don't see why the name cannot be specified in almost all cases, since
each class has a know, fully-specified identification already. Why not just
define the type_info::name() to be the string representation of that, eg,
"std::vector<int,Allocator<int>>"?  Easy enough, and much more useful.

--
. . . Todd V. Jonker . . . . Sr. System Designer. . .
. . . todd@clarit.com . . . . . CLARITECH Corp. . . .
. . . . . . . . http://pobox.com/~tvj . . . . . . . .
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

This is a multi-part message in MIME format.

------=_NextPart_000_0001_01BC9BA6.CE62F740
Content-Type: text/plain;
 charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

 I have a simple program that loads persistent polymorphic objects from
file. Each object data is preceeded by its name. For obvious reasons, I
prefered to use "typeid(*object).name()" to retrieve the class name for
output. When the program compiled with Borland C++ 5.0, it read the file
well. But when compiled with Microsoft Visual C++ 5.0, it failed to =
read. I
debugged the program and found that Microsoft add the word "class" =
followed
by space before the class name. Is that right? Who of the two conforms =
to
the standard?

Avner Ben   |   avnerben@netvision.net.il





------=_NextPart_000_0001_01BC9BA6.CE62F740
Content-Type: text/html;
 charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>

<META content=3Dtext/html;charset=3Diso-8859-1 =
http-equiv=3DContent-Type><!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 =
HTML//EN"><HTML><HEAD>
<META content=3D'"MSHTML 4.71.1008.3"' name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#ffffff>
<P><FONT color=3D#000000 face=3DArial size=3D2>&nbsp;<FONT size=3D2>I =
have a simple=20
program that loads persistent polymorphic objects from<BR>file. Each =
object data=20
is preceeded by its name. For obvious reasons, I<BR>prefered to use=20
&quot;typeid(*object).name()&quot; to retrieve the class name =
for<BR>output.=20
When the program compiled with Borland C++ 5.0, it read the =
file<BR>well. But=20
when compiled with Microsoft Visual C++ 5.0, it failed to read. =
I<BR>debugged=20
the program and found that Microsoft add the word &quot;class&quot;=20
followed<BR>by space before the class name. Is that right? Who of the =
two=20
conforms to<BR>the standard?<BR><BR>Avner Ben&nbsp;&nbsp; |&nbsp;&nbsp; =
<A=20
href=3D"mailto:avnerben@netvision.net.il">avnerben@netvision.net.il</A><B=
R><BR><BR></FONT></FONT></P></BODY></HTML>

------=_NextPart_000_0001_01BC9BA6.CE62F740--
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Avner Ben writes:

> "typeid(*object).name()"

> Microsoft add the word "class" followed by space before the class
> name. Is that right?

The value returned by type_info::name() is implementation-defined.
Thus, both M$ and Borland are correct.  In fact, anything is correct.
AFAIK, a valid implementation of this method is { return 0; } or {
return ""; }.  You should not depend on the value returned by this
method if you intend to be portable.

--
Alexandre Oliva
mailto:oliva@dcc.unicamp.br mailto:aoliva@acm.org
Universidade Estadual de Campinas, SP, Brasil
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

> I have a simple program that loads persistent polymorphic objects from
>file. Each object data is preceeded by its name. For obvious reasons, I
>prefered to use "typeid(*object).name()" to retrieve the class name for
>output. When the program compiled with Borland C++ 5.0, it read the file
>well. But when compiled with Microsoft Visual C++ 5.0, it failed to =
>read. I
>debugged the program and found that Microsoft add the word "class" =
>followed
>by space before the class name. Is that right? Who of the two conforms =
>to
>the standard?

This is the beauty of the current C++ standard with respect to object
persistence: they both conform perfectly, i.e. type_info::name() can
return anything the implementor feels like.  Isn't that great?

By leaving out any attempt to standardize on this type_info::name() is
reduced in usefulness from powerful persistence to debug strings!  As I'm
sure you realized in your implementation, type_info::name() _could_ be the
key to a beautifully simple persistence mechanism if only the return value
was standardized.  Not that I can fault the ANSI C++ committee for lack of
effort, BUT this was a poor aspect to leave unspecified IMHO.

--
---------------------------------------------------------------------
Jess Holle and /                                   jessholl@netcom.com
Wendy Vidlak  /
Norwood, MA  /  ftp://ftp.netcom.com/pub/je/jessholl/j_and_w_www.html
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Jess Holle <jessholl@netcom.com> wrote in article
<jessholl-2807972236550001@10.0.2.15>...
> > I have a simple program that loads persistent polymorphic objects from
> >file. Each object data is preceeded by its name. For obvious reasons, I
> >prefered to use "typeid(*object).name()" to retrieve the class name for
> >output. When the program compiled with Borland C++ 5.0, it read the file
> >well. But when compiled with Microsoft Visual C++ 5.0, it failed to =
> >read. I
> >debugged the program and found that Microsoft add the word "class" =
> >followed
> >by space before the class name. Is that right? Who of the two conforms =
> >to
> >the standard?
>
> type_info::name() can return anything the implementor feels like.

Well, within certain limits. But, yes, it is implementation-defined.

> By leaving out any attempt to standardize on this type_info::name() is
> reduced in usefulness from powerful persistence to debug strings!  As I'm
> sure you realized in your implementation, type_info::name() _could_ be
the
> key to a beautifully simple persistence mechanism if only the return
value
> was standardized.  Not that I can fault the ANSI C++ committee for lack
of
> effort, BUT this was a poor aspect to leave unspecified IMHO.

Again, not unspecified but implementation-defined. Were it "unspecified" in
standardese, it would indeed be useless. However, you're right;
type_info::name() is not intended for persistence; type_info::before() is.

Defining the type_info::name() syntax would have served only to bulk out
the standard document and give the committee more work to do, when they had
more important things to define. It isn't so important that this string is
standardized as that it is well-defined somewhere. This topic has been
discussed extensively in the past.

A type's name() isn't directly useful for persistence, no. However, there's
still a well-defined strict-weak ordering among types, defined by
type_info::before(). That means that, for persistence, you can provide a
map<> from types to your own type identifiers. That's the "generally
accepted" way to use type_info for persistence. Using before() instead of
name() also gives you much more flexibility, since you can put any
identifiers you like into the persistence map.

The very fact that two vendors chose different implementations for
type_info::name() shows that defining it in the standard would have lead to
time-consuming and wasteful debate. As written, type_info::name() is purely
a quality-of-implementation issue; the resulting strings need not even be
human-readable. They might follow, for instance, the compiler's
name-mangling algorithm.
--
Bradd W. Szonye
bradds@concentric.net
http://www.concentric.net/~Bradds
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Alexandre Oliva wrote:
>
> AFAIK, a valid implementation of this method is
> { return 0; } or { return ""; }.
>

Can type_info::name() be the same for different types?

--Bill
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

WSEYMOUR  writes:

> Alexandre Oliva wrote:

>> AFAIK, a valid implementation of this method is
>> { return 0; } or { return ""; }.

> Can type_info::name() be the same for different types?

There's no requirement in the CD2 stating that it cannot.

--
Alexandre Oliva
mailto:oliva@dcc.unicamp.br mailto:aoliva@acm.org
Universidade Estadual de Campinas, SP, Brasil
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

In article <01bc9c27$3b2884a0$be72adce@azguard>, "Bradd W. Szonye" <bradds@concentric.net> wrote:

> The very fact that two vendors chose different implementations for
> type_info::name() shows that defining it in the standard would have lead to
> time-consuming and wasteful debate. As written, type_info::name() is purely
> a quality-of-implementation issue; the resulting strings need not even be
> human-readable. They might follow, for instance, the compiler's
> name-mangling algorithm.

The original RTTI papers provided some examples of what type_info::name
should return; these examples do not show mangled names.

I tried to get WG21/J16 to consider standardizing the names, but there
was not sufficient interest.  However there is still a chance of issuing
a Technical Report which would give guidance to implementors.

As a starting point, here is the gist of my paper 95-0053/N0653 from 1995
in which I proposed a standard form to WG21/J16.  My intent is to try to
get some version of that paper accepted as a Technical Report.

Parts of this proposal are based on examples in Stroustrup's paper
92-0068/N0145.

   The canonical form for classes and enumerations is the class or
   enumeration name (without elaboration), explicitly qualified with any
   immediately enclosing class and/or namespace scopes.  The names of the
   qualifiers themselves are determined by the canonical naming rules
   (applied recursively).
...
   Note that the names of local classes and enumerations do not encode any
   information about the enclosing function; this implies that two
   different local classes may have the same signature name
...
   The representation of any type names involving unnamed classes and/or
   unnamed enumerations is implementation-defined, except that such names
   must not contain white space and must contain at least one character
   which could not otherwise appear in a type signature.
...
   Certain type specifiers are redundant.  In the interest of keeping
   signatures short, redundant specifiers are omitted.  These include:

      int  in  short int  and  long int
      signed  in  signed short,  signed int,  and  signed long

   Type specifiers must appear in the order in which they occur in the
   following list:

      const, volatile,
      signed, unsigned,
      short, long,
      char, wchar_t, bool, int, float, double, void
      class-specifier, enum-specifier

   Optional parentheses must be omitted.

   The only white space in type names is single space characters inserted
   in the following places:

      Between adjacent identifiers and/or keywords.
      Between a type-specifier-seq  and an abstract-declarator.
      After each comma in a parameter list.
...
   Within a template-id, the following rules apply:

   type-id - Represented using the type signature name.

   template-name - Represented using the fully qualified template name.

   assignment-expression  - There are several kinds of assignment
      expression template arguments; we distinguish them by the
      corresponding parameter types:

      reference to data - The fully qualified  name of the argument.
        Qualifiers, including those for unnamed classes, are type
        signature names.

      pointer to data - As above, prefixed with "&".

      signed integral - The decimal representation of the value,
         prefixed by "-" for negative values.

      unsigned integral - The decimal representation of the value,
        suffixed by "U".

      reference to function - The qualified function name as specified
        in the "Function Names" section below. (omitted)

      pointer to function - As above, prefixed with "&".

      pointer to member function - As above.  The qualifier naturally
        includes the class name.


I have omitted some of the more obscure points regarding templates; and
there are some details not yet worked out.  But the above rules cover
the vast majority of the cases.

These are the rules I used in the Taligent/HP front end, but I do not
know if the HP compiler still uses these rules.

Until and unless there is official guidance from WG21/J16, I encourage
vendors to publish their current formatting rules for type_info::name()
so at least the degree of portability between various platforms
will be known.


-- Bill Gibbons
   bill@gibbons.org
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Bradd W. Szonye wrote:
>
> Jess Holle <jessholl@netcom.com> wrote in article
> <jessholl-2807972236550001@10.0.2.15>...
> > > I have a simple program that loads persistent polymorphic objects from
> > >file. Each object data is preceeded by its name. For obvious reasons, I
> > >prefered to use "typeid(*object).name()" to retrieve the class name for
> > >output. When the program compiled with Borland C++ 5.0, it read the file
> > >well. But when compiled with Microsoft Visual C++ 5.0, it failed to =
> > >read. I
> > >debugged the program and found that Microsoft add the word "class" =
> > >followed
> > >by space before the class name. Is that right? Who of the two conforms =
> > >to
> > >the standard?
> >
> > type_info::name() can return anything the implementor feels like.
>
> Well, within certain limits. But, yes, it is implementation-defined.

What are those limits? I've seen messages posted which said that a
conforming implementation could provide the same empty string for every
call to type_info::name()
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

James Kuyper <kuyper@wizard.net> wrote in article
<33DF6FD1.1CFB@wizard.net>...
> Bradd W. Szonye wrote:
> > Jess Holle <jessholl@netcom.com> wrote in article
> > >
> > > type_info::name() can return anything the implementor feels like.
> >
> > Well, within certain limits. But, yes, it is implementation-defined.
>
> What are those limits? I've seen messages posted which said that a
> conforming implementation could provide the same empty string for every
> call to type_info::name()

<laugh>
Just one limit: That it be defined. (I just checked.) Also, it may be a
NTMBS, suitable for conversion and display as a wstring. So it's entirely a
quality-of-implementation issue, useful for whatever the vendor deems it
useful.

Oh well, I won't lose any sleep over that. (I'm surprised that there's not
even a note giving a suggested value; such as the pointer-to-int
conversion, which is 'intended to be unsurprising.') After all,
type_info::before() is more useful and flexible for actual programs, as I
already pointed out.

There's use of 'unspecified' with regard to name() and before(), but I
don't know that 'unspecified' is exactly the right term. Most uses of
unspecified behavior are a shortcut straight into undefined behavior, but
these things shouldn't be entirely unspecified. From run to run, perhaps,
but within a single execution, no! Otherwise, you just take the teeth out
of type_info::before() also.
--
Bradd W. Szonye
bradds@concentric.net
http://www.concentric.net/~Bradds
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

James Kuyper wrote:
>
> Bradd W. Szonye wrote:

> > Well, within certain limits. But, yes, it is implementation-defined.
>
> What are those limits?

I wonder too. CD2 says:

  const char* name() const;

  Returns:
    an implementation-defined value.
  Notes:
    The  message  may be a null-terminated multibyte string (_lib.multi-
    byte.strings_), suitable for conversion and  display  as  a  wstring
    (_lib.string.classes_, _lib.locale.codecvt_)

Which to me implies it may be anything, even a 0 pointer. It is
*allowed* to be a character string, but it doesn't even have to be
that.
   _
/Bjorn.
--
Bjorn Fahller                  Tel: +46 8 4220898 /
NA/EBC/DN/NT                   -------------------
Ericsson Business Networks AB / A polar bear is a rectangular
S-131 89 Stockholm/SWEDEN    /  bear after a coordinate transform
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]