David VanCamp wrote:
>
> Pete Becker (petebecker@acm.org) wrote:
> : David VanCamp wrote:
> : >
> : >
> : > I cannot imagine any real value to this, not only because
> : > some other compiler may implement a rather different
> : > collation sequence, but more importantly, this information
> : > seems useless for any purpose I can imagine.
> : >
>
> : You'd use it to create a sorted container of type identifiers, which
> : would then make it possible to use binary search to find whether an
> : entry is present.
> :       -- Pete
>
> I considered this, but why would anyone want to sort on some
> implementation defined collation order?

In order to be able to look things up.

> Sorting based on the
> type name would make more sense to me.

There's nothing that prevents you from doing that. It might not be as
fast as code the library vendor provides, though.
---
[ 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
]

David VanCamp wrote in message <66pje1$lqk@post.gsfc.nasa.gov>...
>Pete Becker (petebecker@acm.org) wrote:
>
>: You'd use [type_info::before()]
>: to create a sorted container of type identifiers, which
>: would then make it possible to use binary search to find whether an
>: entry is present.
>: -- Pete
>
>I considered this, but why would anyone want to sort on some
>implementation defined collation order? Sorting based on the
>type name would make more sense to me.

Ah, but the encoding of the name is "some implementation defined" value. And
many past threads have debated the utility of these names, especially given
the tricky business of local, static, and unnamed-namespace types.

>Also, not having any
>way to traverse the inheritance hierarchy nor having any other
>useful information about the class would, it seems to me,
>severely limit the value of any such list of typeid's.


In the immortal words of Stroustrup, "If you want Smalltalk, you know where
to find it." The type_info class is not a meta-class; it's merely a way of
identifying types in the presence of polymorphism. The feature is
intentionally limited to prevent abuses that the language designers felt
were too common in more powerful systems.

A mapping from type to data works best when you know in advance which types
exist and what you want to do with them. The most common practical use I've
seen is in implementing generic serialization. You first identify which
types you want to serialize, and create a mapping from the types to some
application-defined identifiers. The advantages: your type identifiers are
then independent of the implementation-defined type names (and probably more
compact), and you don't need to derive all "serializables" from a common
abstract parent.

In more general terms, mapping types allows the equivalent of "virtual
dispatch" for types not related by inheritance. I suppose you could call the
technique "generic dispatch" or somesuch. You have to roll your own; there's
not much language support, but there's just enough to allow it. Admittedly
with considerable effort, you could probably implement some sort of
delegation-based (as opposed to inherited) dispatch using this information.
---
Bradd W. Szonye
bradds@concentric.net
http://www.concentric.net/~Bradds
---
[ 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 <66pje1$lqk@post.gsfc.nasa.gov>, dvancamp@v2k.hst.nasa.gov (David VanCamp) wrote:
>Pete Becker (petebecker@acm.org) wrote:

[on type_info::before()]

>: You'd use it to create a sorted container of type identifiers, which
>: would then make it possible to use binary search to find whether an
>: entry is present.
>:       -- Pete
>
>I considered this, but why would anyone want to sort on some
>implementation defined collation order? Sorting based on the
>type name would make more sense to me.

type_info::before() can be much faster than comparing names.
I can imagine an implementation implementing it like this:

bool type_info::before( const type_info& other )
{
    return this < &other;
}

as opposed to a call to strcmp().

If I were to write this, it would invoke unspecified behavior.  The
implementation can do whatever it wants.  This can work because the
number of type_info objects is fixed (you can only get a reference
to const from the typeid() operator and all constructors are private).

marco
---
[ 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
]

David VanCamp wrote in message <66pje1$lqk@post.gsfc.nasa.gov>...
>Pete Becker (petebecker@acm.org) wrote:
>: David VanCamp wrote:
>: >
>: >
>: > I cannot imagine any real value to this, not only because
>: > some other compiler may implement a rather different
>: > collation sequence, but more importantly, this information
>: > seems useless for any purpose I can imagine.
>: >
>
>: You'd use it to create a sorted container of type identifiers, which
>: would then make it possible to use binary search to find whether an
>: entry is present.
>: -- Pete
>
>I considered this, but why would anyone want to sort on some
>implementation defined collation order? Sorting based on the
>type name would make more sense to me. Also, not having any
>way to traverse the inheritance hierarchy nor having any other
>useful information about the class would, it seems to me,
>severely limit the value of any such list of typeid's.
>

While it may be an arbitrary ordering it still provides the ability to
locate instances of a class. As for using the typename that may be what the
implementation uses but you can't count on it. A reason for not using the
type name is the cost of getting that name and the space it requires as a
string. Some other implementation could order the types on, say, the vtable
address which is much smaller and more easily compared.

>David Van Camp
>dvancamp@v2pop.hst.nasa.gov
>---
>[ 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
>]


Rud Merriam
Houston - First word from the moon
---
[ 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
]

dvancamp@v2k.hst.nasa.gov (David VanCamp) writes:

|>  Pete Becker (petebecker@acm.org) wrote:
|>  : David VanCamp wrote:
|>  : >
|>  : >
|>  : > I cannot imagine any real value to this, not only because
|>  : > some other compiler may implement a rather different
|>  : > collation sequence, but more importantly, this information
|>  : > seems useless for any purpose I can imagine.
|>  : >
|>
|>  : You'd use it to create a sorted container of type identifiers, which
|>  : would then make it possible to use binary search to find whether an
|>  : entry is present.
|>  :  -- Pete
|>
|>  I considered this, but why would anyone want to sort on some
|>  implementation defined collation order?

Because it is required by map, for example.  And I can imagine that
using typeid's as an index into a map is a pretty common use.  (Of
course, I prefer hash code maps, so I'm still out of luck.)

--
James Kanze    +33 (0)1 39 23 84 71    mailto: kanze@gabi-soft.fr
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orient   e objet --
              -- Beratung in objektorientierter Datenverarbeitung
---
[ 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
]

Why isn't "type_info::before" spelled "type_info::operator<" ?

Mike
---
[ 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
]

Pete Becker (petebecker@acm.org) wrote:
: David VanCamp wrote:
: >
: >
: > I cannot imagine any real value to this, not only because
: > some other compiler may implement a rather different
: > collation sequence, but more importantly, this information
: > seems useless for any purpose I can imagine.
: >

: You'd use it to create a sorted container of type identifiers, which
: would then make it possible to use binary search to find whether an
: entry is present.
:  -- Pete

I considered this, but why would anyone want to sort on some
implementation defined collation order? Sorting based on the
type name would make more sense to me. Also, not having any
way to traverse the inheritance hierarchy nor having any other
useful information about the class would, it seems to me,
severely limit the value of any such list of typeid's.

David Van Camp
dvancamp@v2pop.hst.nasa.gov
---
[ 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
]

Looking at the Dec C++ draft, I see that type_info provides
the function:

   bool before (const type_info &) const;

which returns true or false depending on the implementation
defined collation sequence of the classes described by the
type_info objects used. I don't understand the purpose of
this. The SGI compiler seems to consider the 'implementation
defined collation order' as the physical order in which the
classes are defined, eg. for

  class A { ... };
    . . .
  class B { ... };

the following query returns true:

  typeid(A).before (typeid(B))

I cannot imagine any real value to this, not only because
some other compiler may implement a rather different
collation sequence, but more importantly, this information
seems useless for any purpose I can imagine.

Can anyone explain why before works this way? Also, why
is there no support to iterate the list of type_info
objects which represent an inheritance hierarchy? That
would have been a useful feature!

TIA
David Van Camp
---
[ 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                             ]

David VanCamp wrote:
>
>
> I cannot imagine any real value to this, not only because
> some other compiler may implement a rather different
> collation sequence, but more importantly, this information
> seems useless for any purpose I can imagine.
>
> Can anyone explain why before works this way? Also, why
> is there no support to iterate the list of type_info
> objects which represent an inheritance hierarchy? That
> would have been a useful feature!

You'd use it to create a sorted container of type identifiers, which
would then make it possible to use binary search to find whether an
entry is present.
 -- Pete
---
[ 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                             ]

David VanCamp <dvancamp@v2k.hst.nasa.gov> wrote:
: Looking at the Dec C++ draft, I see that type_info provides
: the function:

:    bool before (const type_info &) const;

: which returns true or false depending on the implementation
: defined collation sequence of the classes described by the
: type_info objects used. I don't understand the purpose of
: this. The SGI compiler seems to consider the 'implementation
: defined collation order' as the physical order in which the
: classes are defined, eg. for

:   class A { ... };
:     . . .
:   class B { ... };

: the following query returns true:

:   typeid(A).before (typeid(B))

: I cannot imagine any real value to this, not only because
: some other compiler may implement a rather different
: collation sequence, but more importantly, this information
: seems useless for any purpose I can imagine.

My guess is that it's made to make it possible to put a bunch
of typeid's into a container for which comparison is needed,
like a map<>, for example.

: Can anyone explain why before works this way? Also, why
: is there no support to iterate the list of type_info
: objects which represent an inheritance hierarchy? That
: would have been a useful feature!

No attempts to extend typeid() beyond the bare minimum were made,
in order not to encourage bad programming practices. You shouldn't
need to be able to figure out at run time what was derived from
what, although dynamic_cast<> inadvertently enables you to.
There was no plans to create an RTTI heaven, but to only implement
portions of RTTI, which enable programmers to [portably] implement things
which could not have been [portably] implemented without a direct language
support.

Oleg.
--
Life is a sexually transmitted, 100% lethal disease.
---
[ 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                             ]