Re: Future of C++
Alex wrote:
On Aug 10, 2:02 am, Bart van Ingen Schenau <b...@ingen.ddns.info>
wrote:
Why all the complication, when you can simply do
typeid(*pb); /* where pb is a pointer to the base class */
The standard guarantees that this yields the type_info for the most
derived class, if the base class is polymorphic.
True, however if the parent class has no virtual functions, it doesn't
happen. Inheritance is not synonym for polymorphism. A design may call
for just extending the base interface in derived classes. Or
inheriting only the behavior from the base class.
That said, try this and see what you get:
#include <iostream>
class Base {};
class Derived : public Base {};
int main()
{
Derived* pd = new Derived;
Base* pb = pd;
std::cout << typeid(*pb).name() << std::endl;
delete pd;
}
MSVC and gcc will print the base type name. I'd say that any compliant
compiler should do the same.
They should, just like in this example:
#include <iostream>
#include <typeinfo>
class Base
{
std::type_info& get_type() const
{
return typeid(*this);
}
};
class Derived : public Base
{
std::type_info& get_type() const
{
return typeid(*this);
}
};
int main()
{
Derived* pd = new Derived;
Base* pb = pd;
std::cout << pb->get_type().name() << std::endl;
delete pd;
}
When the parent class has virtual functions, I suspect the performance
penalty of typeid(*pb) will be the same as for dynamic_cast and
virtual call returning typeid(*this) may be a cheaper way to go.
Based on how I would implement RTTI for polymorphic classes, I don't
share your assessment.
I would implement the RTTI feature like this:
- the first entry of the v-table of a polymorphic class points to the
type_info structure of that class.
- The type_info structures form a tree that mirrors the inheritance tree
of the corresponding classes. type_info structures of a derived class
have links to the type_info structures of the base classes.
In this structure, resolving the typeid operator has the same expense as
a single virtual function call (accessing an entry of the v-table).
The (virtual) get_type() function would be double that, because the
compiler can not assume that the typeid(*this) inside get_type can be
resolved statically. There might be an unknown derived class that does
not override the get_type function.
The cost of a dynamic_cast would be even higher, because it generally
involves a typeid operator and a search through the type_info tree to
locate correct base class.
The
bottom line is, the original example used to mock the code structure
could have been pulled out of context and the original author may have
had a valid case for it.
As I also don't know the original context, that is a possibility we
can't ignore.
Just like the code in boost::any and Ogre.
Alex
Bart v Ingen Schenau
--
a.c.l.l.c-c++ FAQ: http://www.comeaucomputing.com/learn/faq
c.l.c FAQ: http://c-faq.com/
c.l.c++ FAQ: http://www.parashift.com/c++-faq-lite/
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]