"Paul D. DeRocco" <strip_these_words_pderocco@ix.netcom.com> writes:
> Lassi Tuura wrote:
> > [[ requiring the relation ]]
> >   x == y  ==>  strcmp (x.name (), y.name ()) == 0
>
> But the standard does require that. Within a single run of the program,
> the same type will always produce a type_info with the same name. And
> the meaning of type_info::operator== is that two type_info's refer to
> the same type. Therefore, if operator== returns true, the two
> type_info's must have the same name.

Could be please quote the standard to support this?  As far as I can
tell, the standard does not even guarantee that successive calls to
`type_info::name()' will return the same value -- all it says is that
the method returns an implementation-defined value.  The paragraph
below from [lib.type.info, 18.5.1] is not in my opinion unambiguous
enough to support your claim:

     1  The class type_info describes type information generated by
        the implementation. Objects of this class effectively store a
        pointer to a name for the type, and an encoded value suitable
        for comparing two types for equality or collating order. The
        names, encoding rule, and collating sequence for types are all
        unspecified and may differ between programs.

Cheers,
//lat
--
Lassi.Tuura@cern.ch          There's no sunrise without a night
---
[ 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                             ]

Lassi Tuura wrote:
>
> Could be please quote the standard to support this?  As far as I can
> tell, the standard does not even guarantee that successive calls to
> `type_info::name()' will return the same value -- all it says is that
> the method returns an implementation-defined value.  The paragraph
> below from [lib.type.info, 18.5.1] is not in my opinion unambiguous
> enough to support your claim:
>
>      1  The class type_info describes type information generated by
>         the implementation. Objects of this class effectively store a
>         pointer to a name for the type, and an encoded value suitable
>         for comparing two types for equality or collating order. The
>         names, encoding rule, and collating sequence for types are all
>         unspecified and may differ between programs.

It would only be legal for an implementation to generate a different
string every time you called type_info::name() if you ignore the
conventional meaning of the word "name". It says that the string is "a
name for the type", and a name isn't a name if it keeps changing. The
above clause merely limits its usefulness to within a single program;
arguing that every call to name() could return a different value reduces
its usefulness to zero.

--

Ciao,
Paul

(Please remove the "strip_these_words_" prefix from the return
address, which has been altered to foil junk mail senders.)
---
[ 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
]

Lassi Tuura wrote:
>
> Taking a bit different view to the ongoing discussion on standardizing
> type_info::name(), I'd like to request for a bit stricter wording for
> this method [lib.type.info, 18.5.1/7].  Namely, assuming that `x' and
> `y' are of type `std::type_info &', I suggest that the following
> relation holds:
>
>   x == y  ==>  strcmp (x.name (), y.name ()) == 0
>
> In other words, equal type_info objects must return equal strings (but
> not necessarily the same pointer).  As far as I can tell, nothing in
> CD2 requires that.  And note that I am *not* requesting that the
> relation holds in the other direction: different type_info objects may
> return names that compare equal.

But the standard does require that. Within a single run of the program,
the same type will always produce a type_info with the same name. And
the meaning of type_info::operator== is that two type_info's refer to
the same type. Therefore, if operator== returns true, the two
type_info's must have the same name.

--

Ciao,
Paul

(Please send e-mail to mailto:pderocco@ix.netcom.com instead of the
return address, which has been altered to foil junk mail senders.)
---
[ 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
]

Taking a bit different view to the ongoing discussion on standardizing
type_info::name(), I'd like to request for a bit stricter wording for
this method [lib.type.info, 18.5.1/7].  Namely, assuming that `x' and
`y' are of type `std::type_info &', I suggest that the following
relation holds:

  x == y  ==>  strcmp (x.name (), y.name ()) == 0

In other words, equal type_info objects must return equal strings (but
not necessarily the same pointer).  As far as I can tell, nothing in
CD2 requires that.  And note that I am *not* requesting that the
relation holds in the other direction: different type_info objects may
return names that compare equal.

The reason for this is that I am after adding application specific
type information based on type_info, and this information could be
used heavily during the program execution.  In my case there is no
need to communicate type information from one execution to another,
and hence the issues raised in the other thread are mostly irrelevant.
In a system with potentially very many classes---from several hundreds
to thousands---simply using the collating order may be too slow for
heavy use: as far as I can see the best one can do with
`type_info::before' is O(log2(N)).  If equal type_info objects were
guaranteed to have equal names, one could use faster look-up
mechanisms such as hash tables or patricia trees in the first stage
and resort to collating order to sort out the last bits -- with
presumably far fewer type_info objects to sort (this is obviously a
quality of implementation issue, since a poor product might always
return "foobar" or even just "" for `type_info::name()').

Does anyone see a reason why this requirement could not be
incorporated into the standard?  If there are no objections, is there
anyone interested in pursuing the topic in the committee?  Or, is
there still a possibility to send in formal change requests?

//lat
--
Lassi.Tuura@cern.ch          There's no sunrise without a night
---
[ 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                             ]