Re: rtti
On May 2, 9:00 pm, Chameleon <cham_...@hotmail.com> wrote:
=CE=A3=CF=84=CE=B9=CF=82 02 =CE=9C=CE=B1=CF=8A 2011 14:05, =CE=BF/=CE=B7 =
=C3=96=C3=B6 Tiib =CE=AD=CE=B3=CF=81=CE=B1=CF=88=CE=B5:
On May 2, 5: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`.
It is asking for difficulties. C++0x changed the union a bit but i
still dislike it.
Is there a better approach, or I am going right?
I suspect your way it won't work.
1) More common alternatives:
vector<boost::shared_ptr<Relation> >
vector<tr1::unique_ptr<Relation> >
2) Just
vector<Relation*>
Create large number of small individual objects in heap is overhead.
It sounds like Java to me.
The reason Java works like this is that it more or less assumes
(or almost requires) that every object is polymorphic. From
what you've described, that's the case you're in. As soon as
polymorphism comes into play, C++ starts allocating dynamically
as well.
works for those who do not want dependency on boost or C++0x
extensions. It is more error-prone when dealing with raw
pointers so enwrap it into something.
There are very few things as error prone as boost::shared_ptr.
At least for the sort of things one usually allocates
dynamically; his case may be the exception (but he's not told us
enough about the derived types to be sure).
3) You can remove the exposed polymorphism by using pimpl idiom so
Relation becomes envelope class and `Angle`, `Azimuth`, `Distance`,
`Height` are its hidden internal variants of implementation. Then
vector<Relation> works fine.
But he still ends up with a lot of small allocations:-).
From the names, I suspect that a single class, with a
discriminator indicating how to interpret the contents, and
perhaps a union with the actual data, might be appropriate.
Might be---one really can't say without knowing more about the
applications.
My approach a little bit similar:
Every of 5 derived classes in its own vector. (Instead of every single
object in a new block in heap)
A big vector with envelope class for derived classes implementing the
operator* to access base class which has the complete functionality.
Envelope class has the type of derivative class and the index in its vect=
or.
The problem is that I cannot use only one derived class to do something,
but different derived classes together. E.g. Distance and Angle (to
describe a new point) or angle and angle, or distance and distance and
clockwise.
And after I will use all of these as springs linear (Distance, Height)
or angular (Angle, Azimuth) to minimize the error.
I'm not sure I've understood what you're trying to do, so this
might be complete rubish, but it vaguely sounds like you're
trying to maintain a position (relative or absolute?) in several
different formats. The usual solution here is to unify the
format inside the class, and add manupulators along the lines of
changeAzimut, etc.
--
James Kanze