Brian Parker <bparker@gil.com.au> writes:

|> In browsing the draft standard I have come across what appears to be a
|> minor problem with the specification of type_info::name().  In D & E,
|> Dr Stroustrup suggests associating extended type information with a
|> given type by using a map indexed by either typeid(*p).name() or
|> &typeid(*p). The draft standard, however, specifies that name()
|> returns an implementation-defined (and presumably possibly non-unique)
|> value.  Typeinfo::name() should probably be specified to return a
|> unique string for each different type to allow this form of lookup, or
|> are there other portable ways to achieve this? (D&E actually states
|> that some implementations may not be able to guarantee uniqueness of
|> type_info objects so I presume that using &typeid(*p) as an index is
|> non-portable.)
|>
|> Any comments?

Isn't this what the type_info::before is for?  (Of course, this doesn't
help if you want to put type_info's in a hash table.)

I do think that it would be worthwhile to add words to the effect that
the implementation defined strings returned by name should compare equal
(when converted to wstring?) if the type_info objects themselves compare
equal, and unequal otherwise.  As it now stands, an implementation which
always returns "some type" would be conforming, as long as it documents
this fact.  On the other hand, of course, the string returned could
depend on the locale.

--
James Kanze      home:     kanze@gabi-soft.fr        +33 (0)1 39 55 85 62
                 office:   kanze@vx.cit.alcatel.fr   +33 (0)1 69 63 14 54
GABI Software, Sarl., 22 rue Jacques-Lemercier, F-78000 Versailles France
     -- Conseils en informatique industrielle --
---
[ 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                             ]

In browsing the draft standard I have come across what appears to be a minor
problem with the specification of type_info::name().
In D & E, Dr Stroustrup suggests associating extended type information with
a given type by using a map indexed by either typeid(*p).name() or
&typeid(*p). The draft standard, however, specifies that name() returns an
implementation-defined (and presumably possibly non-unique) value.
Typeinfo::name() should probably be specified to return a unique string for
each different type to allow this form of lookup, or are there other
portable ways to achieve this? (D&E actually states that some
implementations may not be able to guarantee uniqueness of type_info objects
so I presume that using &typeid(*p) as an index is non-portable.)

Any comments?

,Brian Parker  (bparker@gil.com.au)
---
[ 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
]