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
Attachment:
signature.asc
Description: OpenPGP digital signature