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);
}
};
--
__Pascal Bourguignon__
I think I like your approach, it will just mean a huge number of
setters and getters all of them with that default behavior.
What I really don't like about this approach is that for instance a
property 'linewidth' which probably does not exist in half of the
treeitem class types now has to have an accessor function in the
toplevel superclass. That's an ugly contamination of the top
superclass, but it's probably unavoidable. :-(
Thanks for thinking along.
Bart
P.S. I've been programming a lot in Python recently, and that really
is much nicer for this kind of thing :-)