Re: [glade--] Could raw C++ pointers be eliminated?

Paul Elliott schrieb:
> My (and others) C++ memory philosophy is that raw C++ pointers
> should be very rare in application programs. They cause
> problems in an exception environment:
> 
> http://www.io.com/~pelliott/notes/philo.html
> http://austinlug.org/ALG/Presentations/elliott_peless/peless.sxi
> (see especially slide 40)

I do not consider autogenerated code part of an application program. You 
do not have to maintain it manually!

So autogenerated code should be measured differently from human 
maintained code.

You are right though that glademm's generated code is not exception 
safe. Patches or even sane (!) design proposals are welcome. It's not 
trivial at all.

> When I need to create a complex widgit or dialog, I run
> glademm, glade--, then I hack the hell out of the generated
> code, changing all the pointers to sub-widgits to contained
> ("has-a") subobjects.
> 
> What would be involved in changing glade-- to generate
> this code automaticly?
> 
> If this is not easy, what would be involved in changing
> all the raw pointers to some kind of smart pointer?
> std::auto_ptr, boost::shared_ptr or Gtk::RefPtr?

IIRC Gtk::RefPtr-s are not fully supported for widgets, yet. I didn't 
check lately (2.4.x) but 2.2 had issues. Do you sincerely know that it 
will work with all widget types?

It might be worth trying to use RefPtr.

> One of the selling points of Gtkmm is that member instances
> can be used:
> 	(4) Member instances can be used, simplifying memory
> 	management. All GTK+ C widgets are dealt with by use of
> 	pointers. As a C++ coder you know that pointers should be
> 	avoided where possible.
> 
> From the Gtkmm FAQ:
> http://www.gtkmm.org/docs/gtkmm-2.4/docs/FAQ/html/index.html#id2486512
> 
> So my question is, how much trouble would it be to make glade-- take
> advantge of this?

Glade-- (at some point in the past, around gtkmm 1.0) supported inlined 
members. There's one drawback when using these though:

The order of declaration matches the order of construction. Since some 
widgets depend on other widgets being initialized the logic to emit 
widget members (and to emit the ctors being called with the right 
arguments) would get much more complicated.

At the time I implemented Toolbars, Dialogs and Menus I simply gave up 
to bother about member variable order. [variable order is spread between 
two to three different functions, the ctor code emitter is much more 
linear and local to write].

     Christof

_______________________________________________
glademm-list mailing list
[email protected]
http://mail.gnome.org/mailman/listinfo/glademm-list

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Debian - http://enigmail.mozdev.org

iD8DBQFBdhlMng+R+0ucfO0RApwLAKCjdBiLlDTNc/B0l/fygIHlIZpDYgCcDCWl
dtjvlRcbrbtzEdnl+0Y2Hc0=
=ERHV
-----END PGP SIGNATURE-----