Re: rtti
On May 2, 3:03 am, Chameleon <cham_...@hotmail.com> wrote:
I have derived classes `Angle`, `Azimuth`, `Distance`, `Height` from
base class `Relation`.
I want to put all of these in a `vector<Relation>` but they have
different size, so, I create a `union AnyRelation` and I put all of
derived classes inside this union, and the vector become
`vector<AnyRelation>`.
When I want to check what type the derived class is, I use `typeid`.
Is there a better approach, or I am going right?
Well, there's one major problem with your approach. It isn't
legal C++, and won't compile. At least assuming that Relation
has any virtual functions (and it should, otherwise, there's no
point in the derivation). What you can do is use something like
boost::variant, or even boost::any, but usually (not always),
the need for such a solution is indicative of a design error.
Another try, is to put every derived class in its own vector:
vector<Azimuth>
vector<Angle>
vector<Distance>
and so on.
and in a `vector<Relation>` I can use references to real objects.
With this approach I can avoid the `typeid` because I can check if
pointer of derived class object belongs to a specific `vector`.
The real question is what you are doing with the typeid to begin
with. You've not described the problem in enough detail, or
rather at a high enough level, for us to make any concrete
suggestions, but in most cases, if Azimuth implements Relation,
client code should be able to deal with just Relation, without
knowing that this particular Relation is an Azimuth. (Again,
there are exceptions, but they are few and far between. And
generally only concern a single subset of the derived classes.)
And a final question:
Its better to create my own rtti, or to use build-in? (for speed)
My own rtti:
------------
class A {
A() : rtti(0) {}
int rtti;
int getRTTI() { return rtti; }
bool isB() { return rtti == 1; }
virtual ~A() {}};
class B : public A {
B() { rtti = 1; }
};
In general, it's better to only use virtual functions. If some
of the derived classes have to implement an extended interface,
then I'd probably go with dynamic_cast until the profiler showed
it to be a problem. If it is a performance problem, and the
design really does require such, then you can consider something
like:
class Base
{
// ...
virtual Extended* getExtended() { return NULL; }
// ...
};
class Extended : public Base
{
virtual Extended* getExtended() { return this; }
// ...
};
Those classes which implement the extended interface derived
from Extended; those which don't, don't.
And for better or for worse, once polymorphism enters into the
scene, you're going to have to deal with pointers and dynamic
allocation. Since, based on the names, I'd guess that these are
really "value" type objects (which you'ld copy, and never
allocate dynamically if the polymorphism wasn't involved), and
they probably don't contain pointers to other objects (so you
can't get cycles), you can consider using some sort of reference
counting pointer; boost::shared_ptr, or better yet, some sort of
invasive pointer (and have Relation contain the counter);
alternatively, if you make all of the constructors private,
use factory methods which return the smart pointers, and none of
the types ever call any function which might take a pointer to
the object itself, you can probably use boost::shared_ptr
without too many problems.
--
James Kanze