[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gtkmm
Subject:    Re: [gtkmm] More review text: signals, overrides
From:       Guillaume Laurent <glaurent () worldnet ! fr>
Date:       2000-02-27 11:29:54
[Download RAW message or body]

Data <data@gtf.org> writes:

> > > It also means that you'll rarely have to write an entirely new
> > > widget; you can almost always do what you want by subclassing.

[...]

> > But in what way is this related to signals ?
> 
> It's not - the section is on the virtues (no pun intended) of
> overriding, not signals.
> 
> Should these statements not be there?

No, leave them, that's fine.

> [ overriding non-virtual methods ]
>
> I did not know that.  I wrote a little test program tonight to find out
> how this really works, and I learned something.  For some reason I
> thought that if you put a member function in a derived class which has
> the same signature as a function in a parent class, the compiler would
> give an error unless the parent class' member was virtual.  Clearly this
> is not the case.  However, as you say, one should bear in mind that if
> the derived class is casted to a base, only the virtual functions will
> get called from the base.  You learn something new every day - I can see
> I'll learn even more from doing this than I expected :)

Yes, but IMHO you got it backwards :-).

If a method is not virtual, it means that a call to it will be
resolved at compile to a regular function call (with 'this' usually
being passed as 1st arg, just like GTK+ does).

However, this means that if you call the method from a ptr/ref to a
base class object, the base method will be called, because the static
type of the object is the one of the base, and the call has been
resolved at compile time. You lose polymorphism.

The reason why methods aren't virtual by default is because of two of
the C++ design principles : be compatible with C, and you don't pay
for what you don't use.

If methods were virtuals by default, then you could take a C struct
'foo', derive it to 'bar' and add a couple of methods to it, and still
be able to pass a 'bar' to a C function expecting a 'foo' (I'm doing
exactly this in the Gnome menu API) : they wouldn't have the same
size, because of the virtual function table.

And virtual methods have a (slight) call overhead : if you don't need
polymorphism, you don't pay for it and get blazing raw C speed.
 
> "More Effective C++" - I don't have that book; is it worth owning?

Yes. And it's predecessor, "Effective C++". Both are universally
recommended and reknown as being must-haves for any serious C++
programmer.

-- 
					Guillaume.
					http://www.telegraph-road.org

_______________________________________________
to unsubscribe or change your subscription parameters :
http://lists.sourceforge.net/mailman/listinfo/gtkmm-main

[prev in list] [next in list] [prev in thread] [next in thread]