Re: [inti] OptionMenu width ?

Jeff Franks wrote:

> I was trying to reduce the size of the memory foot print of the 
> application and improve its speed. The proxy connection occurs in the 
> library itself but not in the application. Each proxy function is 
> static so there is only one of each type for the entire library. The 
> run time fee is no more than for GTK itself because this is what GTK 
> does in an object's class_init function. It assigns an object specific 
> function to the function pointers declared in a base object's class 
> structure.

Hmm, ok so connecting the proxy classes, are not the most expensive 
thing to do, I agree.

> The point is that you're objects wont have such a big virtual function 
> table and wont be slowed down by calls to the table. Just think of all 
> the widgets in a average application. In Gtk::Widget there are about 
> 60 virtual functions. Most classes that derive from Gtk::Widget add 
> there own virtual functions. All up, at a guess, each end widget could 
> have up to 100 virtual functions. Multiply that memory by all the 
> widgets in an application and there is a lot of memory. The thing I 
> realized is that most widgets don't override these virtual functions 
> and so that meant there was a potential memory saving. You still need 
> to have these virtual functions though, because unlike proxy signals 
> (that is, the sig_something() functions) they do not need to be 
> connected. Instead they get called before the default handlers in GTK. 
> You can override the default GTK handlers simply by not calling the 
> parent virtual function. Calling the parent virtual function calls the 
> default GTK signal handler. If you want the default behaviour then you 
> must call the parent virtual function.

About the cost ! When I make a new Inti Widget I also make a WidgetClass 
instance too. This does not include unused virtual tables anymore, nor 
the cost of calling these, nice !

But, the _proxy functions now do a "dynamic_cast" (on each signal), 
including all the RTTI mombo jumbo, and the "default" action code, ends 
up as redundant code (both in the Signals and Class functions) :-( Or, 
have I again failed to understand ?

As a last detail. If I liked to make a common Buttom action handler (no 
good reason comes to my mind, yet), for more than one buttom at the same 
time, I need to connect my own function and not using the Signals class, 
so tricks like this will not work :

class MyModal : public Dialog, ButtonSignals
{
    Button m_bnt1, m_btn2:

    void on_activate( void ) {
       cout << "A buttom have been pressed" << endl;
    }
}

As I have no way to connect the signal class, other than indirectly, but 
to trust the internal "magic" cast. What this will provide is some 
wasted footprint overhead, no compiling error, not even a runtime error :-)

I do understand Your complain about the hard to understand Widget 
argument, for the Signals class constructor, but it make sense in order 
to make things like the above possible, and you get rid of the dyncast 
and if signals are registred late (when connection a signal), the 
default code redundancy (is this a valid word ?) too.

> Now, the virtual function mechanism only gets added to your classes if 
> you multiplely inherit from the new signal classes. Otherwise, it may 
> be in the library but it's not in your application, and your 
> application doesn't use these virtual fucntions if it was compiled 
> without them.

Ok, I think I understand now ... I hope.

>        type = G::TypeInstance::register_type(GTK_TYPE_BUTTON, 
> (GClassInitFunc)init);

Ahh, thanks I see it now, I was just hoping that even the proxy 
functions was first connected when the signal class was "added", to keep 
things at a absolut minimum.

> so, Gtk::ButtonClass::create() calls Gtk::ButtonClass::get_type() 
> which installs Gtk::ButtonClass::init() as the class initialization 
> function, instead of GTK's. The first thing the init() function does 
> is call the Inti parent class init() function and then it assigns 
> function pointers the GTK widget class's function pointers. The proxy 
> functions then call the GTK functions by default, as do the default 
> implementations of all the virtual signal handlers (the on_something() 
> functions). 

Ahh, thanks for the explaination.

> You can override this but that can be dangerous if you are not sure 
> what your doing. For example, you might loose the default behaviour 
> and a button wont click or an entry wont allow text to be entered.

Ok.

> And remeber, it seems like alot of code but it's all static. For 
> example, there is only one Gtk::EntryClass and all the functions in it 
> are static so there is only one each of them, shared by all entry 
> widgets. The overhead is in the virtual signal handlers, not the 
> _proxy functions.

But now in the dynamic_cast instead ?

> Well, each call to a sig_something() fucntion adds several template 
> classes to your application code, behind ther scenes. Multiply this by 
> all the calls to all the sig_something() functions your application 
> makes and there is some more overhead. Before you got the virtual 
> fucntion overhead whether you used it or not. Now you have a choice, 
> and I think it can be used to optomize an application.

Agreed, I'm just a little resource greedy :-)

Hope this make just a little sense, or am I totaly off the track ?

/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