Re: How to check if another object is my superclass from a function
in an even higher superclass?
On 3 mrt, 13:02, p...@informatimago.com (Pascal J. Bourguignon) wrote:
bart van deenen <bart.vandee...@gmail.com> writes:
On 3 mrt, 11:10, Kai-Uwe Bux <jkherci...@gmx.net> wrote:
bart van deenen wrote:
Hi
I have a pile of objects all derived from one baseclass, and I want =
to
have a generic function that an object can use to see if another
object is its superclass.
[snip: something using __typeof__]
I now know more about the function of the __typeof__ operator, so I
understand why it doesn't work.
First, __typeof__ does not exists in standard C++. There is a typeof
operator, though.
But how would you do this? Is there an elegant way?
Well, for starters, there is the use of virtual functions:
[...]
BTW: I don't know very much about object oriented programming, but fro=
m what
I hear, the need for a function like superclass() or subclass() is a d=
esign
Not necessarily (in more dynamic programming languages these methods
have their use). But indeed, when programming in C++, unless you want
a dynamic programming style, it will be better to stick to virtual
methods.
What is the underlying problem that you have to solve?
Thanks for your answer
My problem: I have a tree of displayable objects of different types.
These object types have an class inheritance tree, and also have the
capability to inherit attributes from their ancestor objects (in the
tree, not in the class hierarchy). A bit like html and css.
Now one of my nested objects might inherit an attribute (say 'color')
and it will have to loop through its ancestors to find one that can
provide it with the attribute 'color', but not all of its tree
ancestors might be part of its own class inheritance path, so it won't
even ask those if they have the attribute value available.
So my reasoning is that by asking another tree object if its part of
my class inheritance, is that if it says no, i don't have to ask it
for the 'color' attribute.
Hope this makes sense.
Do use virtual methods! All the objects that can belong to this tree
shall be of a subclass of some abstract class that will publish the
virtual methods needed.
The default implementation of a method such as color() could be to
return the parent's color, and then you don't have to write the loop
explicitely.
class TreeItem
{
protected:
TreeItem* parent;
public:
static Color* defaultColor;
TreeItem(TreeItem* anItem):parent(anItem){}
virtual Color* color(){ return((parent==0)?defaultColor:paren=
t->color()); }
// ...
};
class DisplayableObject:public TreeItem
{
public:
Color* color(){return(0);}
};
class Box:public DisplayableObject
{
// ...
virtual Color* color(){
Color* superColor=SUPERCLASS::color();
return((superColor==0)?parent->color():superColor);
}
};
--
Hi Pascal
one more thing, what I dislike about this approach is that a now have
a global namespace for attribute names via the getters and setters in
the top superclass. In my approach, I can have subclasses of different
types use the same named attribute 'color' for instance, without them
biting each other. I wonder if that's even a disadvantage though.
The problem is that the whole tree structure is completely dynamic,
driven from google protocol buffer encoded data, that already has
attribute names inside it, and I'm pretty sure I'll get attribute
collisions there.
I'll have to play with it a bit.
Thanks
Bart