how to know the object's type?

[zl2k]

hi, there,

Suppose I create an instance of a class (Class Foo). Then I put the
object into an contenor. Later on, I take it out from the contenor.
How can I know the object is of Class Foo? It looks dumb to put a
classname as id within the class. Does c++ provides some function say,
object.getType() and returns Foo? Thanks.

zl2k

 

[Stefan van Kessel]

hi, there,

Suppose I create an instance of a class (Class Foo). Then I put the
object into an contenor. Later on, I take it out from the contenor.
How can I know the object is of Class Foo? It looks dumb to put a
classname as id within the class. Does c++ provides some function say,
object.getType() and returns Foo? Thanks.

zl2k

The standard containers offer a typedef value_type. So if you for
example have the type of the container as a template parameter T, you
can get the type of the objects in the container via T::value_type. If
your compiler already supports the c++0x feature decltype, you can also
get the type for example by using decltype(*t.begin()).

#include <iostream>
#include <vector>

template <typename T>
void foo(const T& t)
{
std::cout << typeid(T::value_type).name() << std::endl;
std::cout << typeid(decltype(*t.begin())).name() << std::endl;
}

int main() {
std::vector<int> vec;
foo(vec);
}

 

[Jorgen Grahn]

hi, there,

Suppose I create an instance of a class (Class Foo). Then I put the
object into an contenor. Later on, I take it out from the contenor.

More correctly you're putting *a copy of the object* into the container,
and taking *a copy* out from it. You're not talking about containers
of pointers, it seems.

/Jorgen

 

[Bernhard Ibertsberger]

How can I know the object is of Class Foo? It looks dumb to put a

Have a look at the visitor pattern (GOF). It recovers the type
information via double dispatch and the program flow lands within a
function designated to a certain type of the class hierarchy.

hth
Bernhard

 

[Joshua Maurice]

zl2k ha scritto:


This sounds a lot like Java-influenced thinking.

Perhaps, but the design would be just as bad in Java as in C++. In
\nearly\ all well designed programs, you should not explicitly query
an object for its type as part of normal operations. Dynamic dispatch
through virtual functions, aka Object Oriented programming, is there
specifically to avoid querying an object for its type then switching
on that type to do something different for each type. I have no simple
answer for the OP. We would need to know a lot about the problem
domain to offer a good design alternative.

Let me put this another way. To the OP: First, your question is
legitimate, and the literal answer is: "You are correct. C++ offers no
way to get the type of an arbitrary object at runtime. If you have a
Foo*, and it's a polymorphic class, then you can use dynamic_cast and/
or typeid to get the type."

However, asking the question suggests that you are pursuing a bad
design. In C++ and Java, the standard library containers are
homogeneous - they hold objects of the same type. In C++, you can have
a vector<Foo*>. It holds only pointers to Foo objects, which can point
to Foo objects, objects of derived type, and so on. In Java, the
situation is the same. You can have an ArrayList<Foo>, which holds
"references" to Foo objects, objects of derived type, and so on.

So, why do you want to put an object into a container, forget about
it, and have some unrelated code take one of the objects out of the
same container, and then try to do some derived-type specific logic to
it? This has alarm bells going off for bad design. For example, see
the C++ FAQ, specifically see the Circle And Ellipse problem, which
you may be doing.
http://www.parashift.com/c++-faq-lite/proper-inheritance.html#faq-21.7

 

[Öö Tiib]

Perhaps, but the design would be just as bad in Java as in C++. In
\nearly\ all well designed programs, you should not explicitly query
an object for its type as part of normal operations.

There can be good reasons. For example for detecting programming bugs:

T* T::clone() const
{
assert( typeid( *this ) == typeid( T ) );
// *this is real T
return new T( *this );
}

Problem of OP may be also is protection against bugs. If his
"contenor" can contain NonFoo but should only contain pure Foo's by
contract then detecting does not hurt.