It can be used for defining a sort order on the type_infos. You can use it
to associate
more detailed info for a given type_info with a STL map (you can not use
type_info::name, as it need not be unique). See D& E for more detailed
explanation:

    struct CmpTypeInfo {
         bool operator()(const type_info& a, const type_info& b) const {
 return a.before(b);
         }
    };
    typedef map<type_info, MyExtendedInfo, CmpTypeInfo> TypeInfoMap;

    TypeInfoMap imap;
    TypeInfoMap::const_iterator ci = imap.find(some_type_info);
    if (ci != imap.end()) {      // found
       // (*ci).second is your extended info
    }

> Anyway, can someone give me a description as to the purpose behind
> type_info::before(), why someone would want to use it, and possibly even
> a brief example?
---
[ 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
]

I recently submitted this to comp.lang.c++, but I think it applies here.

I have read the C++ Draft dated 12/2/96 and read the Microsoft
documentation (oddly enough they're identical) for class type_info and
type_info::before() and I can't make heads nor tails of it.  I'm
confused with the following statments:

"Use the type_info::before member function to determine the collating
sequence of types.  There is no guarantee that type_info::before will
yield the same result in different programs or even different runs of
the same program."

If it isn't deterministic, why would it be used?  In Bruce Eckel's book,
Thinking in C++ (a very good book in most respects), he says it can be
used to determine predecessors in the class hierarchy (base-derived
relationships), but this is contradicted by the standard.  I attribute
this difference to the fact that the standard was still evolving rapidly
when the book was written.

Anyway, can someone give me a description as to the purpose behind
type_info::before(), why someone would want to use it, and possibly even
a brief example?


Much appreciated,

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

Chad Willwerth wrote:

> "Use the type_info::before member function to determine the collating
> sequence of types.  There is no guarantee that type_info::before will
> yield the same result in different programs or even different runs of
> the same program."
>
> If it isn't deterministic, why would it be used?

It _is_ deterministic, within a single execution of the program.

> In Bruce Eckel's book,
> Thinking in C++ (a very good book in most respects), he says it can be
> used to determine predecessors in the class hierarchy (base-derived
> relationships), but this is contradicted by the standard.

No, it can't. For instance, in Borland, all type_info::before() does is
the equivalent of "return strcmp(name(), rhs.name()) < 0;". That tells
you bupkis about the relationship among the classes.

> Anyway, can someone give me a description as to the purpose behind
> type_info::before(), why someone would want to use it, and possibly even
> a brief example?

So that it's possible to use type_info objects as search keys more
efficiently. If they are unordered, then a search based on type_info
can't be anything more efficient than a plain exhaustive search.

--

Ciao,
Paul D. DeRocco

(Please send e-mail to mail: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 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                             ]