Re: OptionMenu width ?

Jeff Franks wrote:

> Not proxy classes, static proxy functions. The proxy classes are those 
> things returned by calls to one of the sig_something() functions.

Ok, ok so no more about memory footprint's in proxy functions, sorry :-)

>> About the cost ! When I make a new Inti Widget I also make a 
>> WidgetClass instance too. 
>
>
> No you don't. A WidgetClass is never instantiated, not by the library 
> and not by an application. Only the static functions declared in the 
> WidgetClass are used, in the same way as if they were in a namespace. 
> I could replace "class WidgetClass" with "namespace WidgetClass" and 
> the result would be the same. No overhead incurred.

Other than the signal proxies are added, to the GtkWidget type, and will 
be called on every imitted signal, in ALL widgets in inti/2.

>>
>> But, the _proxy functions now do a "dynamic_cast" (on each signal)
>
> This does not include unused virtual tables anymore, nor the cost of 
> calling these, nice !
>
> Yes, but only on the signals you explicitly inherit from. For example:

Hmm, are your sure ... ?

When making a new GtkWidget type (done once per Widget, yes !) inti 
connects a static proxy function from the WidgetClass. This will just 
call the default Gtk handler if a signal is imitted, but before that, it 
will test if a WidgetSignal class is part of the Widget class by doing a 
dynamic_cast. That dynamic cast will be performed regardless of the 
presence of the WidgetSignals class, and this is somewhat costy.

The only way to prevent this is either to remove the dynamic_cast, or to 
attach the widget signal handlers only when needed (like in the 
WidgetSignal constructor). The problem in this is that the user NEED to 
be aware of this, when making his own derived classes.

> In EntrySignals there are only three virtual functions. That's it. If 
> you don't inherit from WidgetSignals also then your over head is 
> maximum of three dynamic_casts but not all the signals will be emitted 
> at the same time. The only one emitted over and over in Entry is 
> "insert_at_cursor".

Yeps, but how about the WidgetSignals (base class), or the other signals 
all the way up in the inheritance chain, they all gets to make a 
dynamic_cast in there attaced proxy classes. I don't know what is most 
expensive a dynamic_cast or a virtual function, but RTTI are not cheap 
to my best of knowledge.

> The reason I moved the virtual signal handlers out of the widget 
> classes was this - most of the time you connect widgets to signals 
> inside the parent window's or container's constructor using the 
> sig_something() functions. These connection functions have nothing to 
> do with the virtual signal handlers. They're a completetly separate 
> entity. The only reason the override a virtual signal handler is when 
> you want implement some custom behaviour and need to derive your own 
> class. It seemed a bit excessive to me having all those virtual 
> functions in a huge virtual function table (one for every widget) when 
> usually you wont use many of them at all. Now, you can  use only those 
> few you actually need and disregard the rest.

I understand, and like that too (as you know), I just like to know ALL 
the overhaed to be gone, not just hidden or moved away to a hidden place 
:-) I hate it when people say that C++ is a slow beast, when the problem 
is to be found i the C++ libraries.

> I guess it is a design issue. Your original idea was to only use those 
> signals you need, and you mentioned Java and inheritance. The only way 
> I could implenment anything remotely like that was like this. If it 
> turns out that I was wrong, and it actually slows things down or 
> increases an applications memory footprint I will get rid of them. 
> From my testing though, compiling and running applications does seem 
> faster.

I think my original idea was (maybe not propperly expressed in my 
mails), that the signal classes only was connected ( and signals emittet 
into the C++ "domain", at whatever cost) when in use. If no signal 
classes are added to my widget, the cost will be zip or only the cost 
gtk push upon me/us.

Thats why I keept babling about the constructor of the Signal class 
needed to have an instance of the Widget, as this is where it will 
connect its signals. Also this will make sure the enduser gets a propper 
compilation error if he/she adds a wrong signal class to a wrong widget. 
And only then will I need to pay the runtime fee of virtual functions 
(but no dynamic cast is needed) !

I know this may confuse some, but when a user starts to enherit Widgets 
he need to know the signals system anyway, and the binding between the 
Widget and the signal class is somewhat logical. And in the end we are 
able to make common signal handler classes outside the widget 
enheritance chain ... at no extra cost.

> If I was implementing some new behaviour in my own derived widget I 
> would tend to override virtual signals handlers.

I said it was a very "thougth" example, sorry.

> When I was using this widget I would connect to signals through the 
> sig_something() functions.

Me too, the point was the flexibility, and the fact that someting funny 
and unaware happends behind the back of the user ( that is me) and 
he/she have no way to control, nor know of this !

> BTW the signal classes are only meant to be inherited by the 
> associated widget. Only a Button can inherit from ButtonSignals. A 
> dialog is not a button.

I know, but the compiler can't help you here, and I like it when my 
compiler yield at me when I do dum things, which is why I have come to 
like C++ this much :-)

Sorry to be such a pain, but I think this is an important issue.

/BL



-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click