On Mon, 2006-11-13 at 10:23 +0100, Bo Lorentsen wrote:
> Murray Cumming wrote:
> > On Sun, 2006-11-12 at 00:02 +0100, Bo Lorentsen wrote:
> >> Paul Pogonyshev wrote:
> >>> Bo Lorentsen wrote:
> >>>> If a standard widget class holds about 50 unused virtual functions, that
> >>>> is an extra 200 bytes in 32 bit, and 400 in 64 bit. In your case this
> >>>> will ends up using 200 * 2000 = 400 K bytes in 32 bit and 800K in 64 bit.
> >>> Mmm, there is one virtual function table per class, not per object...
> >> Sorry, you are right ...
> >
> > Really, I think it's per object. I think that's the point.
>
> I think this is worth looking into ... I am not sure how this is done by
> the (gnu) C++ compiler.
its part of the language definition. its not a hack in the compiler. all
that happens is that every object type that has any virtual functions
comes with a pointer (g++ happens to call it _vptr IIRC) that points to
the class-specific virtual function table. this isn't some clever new
thing, its fundamental to the way that C++ and several other OOP
languages work. i don't know wht i forgot this when i commented on the
issue. what this means it makes (almost) no difference how many virtual
functions a class has - every object has just one pointer to to the sole
instance of the virtual function table for that class. when you call a
virtual function, you indirect through the pointer and offset into the
table to get the actual address of the function to execute.
i have a suspicion that mr franks didn't understand or forgot this basic
element of how C++ works - not a big deal, since i did too :)
oh, also, his claims of "people didn't answer my emails about gtkmm so i
wrote GFC-or-whatever-its-called now" .... i googled for email from him
to the gtkmm-list and found almost nothing. he offered a patch for one
bug in a very early version of gtk-- (during 2000), then he showed up
again in 2003 to comment on the existence of GFC and wrapping C APIs. i
could find almost no other messages.
--p ("those who don't understand gtkmm are destined to reimplement
it ... badly")
_______________________________________________
gtkmm-list mailing list
gtkmm-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtkmm-list
