Table of Contents
|
gtkmm allows the programmer to control the lifetime (that is, the construction
and destruction) of any widget in the same manner as any other C++ object.
This flexibility allows you to use new and
delete to create and destroy objects dynamically
or to use regular class members (that are destroyed automatically when the
class is destroyed) or to use local instances (that are destroyed when the
instance goes out of scope). This flexibility is not present in some C++ GUI
toolkits, which restrict the programmer to only a subset of C++'s memory
management features.
Here are some examples of normal C++ memory management: If a programmer does not need dynamic memory allocation, automatic widgets in class scope may be used. One advantage of automatic widgets in class scope is that memory management is grouped in one place. The programmer does not risk memory leaks from failing to delete a widget. The primary disadvantages of using class scope widgets are revealing the class implementation rather than the class interface in the class header. Class scope widgets also require Automatic widgets in class scope suffer the same disadvantages as any other class scope automatic variable.
#include <gtkmm/button.h>
class Foo
{
private:
Gtk::Button theButton;
// will be destroyed when the Foo object is destroyed
};
If a programmer does not need a class scope widget, a function scope widget may also be used. The advantages to function scope over class scope are the increased data hiding and reduced dependencies.
{
Gtk::Button aButton;
aButton.show();
...
kit.run();
}
Although, in most cases, the programmer will prefer to allow containers to automatically destroy their children using manage() (see below), the programmer is not required to use manage(). The traditional new and delete operators may also be used.
Gtk::Button* pButton = new Gtk::Button("Test");
// do something useful with pButton
delete pButton;
Here, the programmer deletes pButton to prevent a memory leak.
Alternatively, you can let a widget's container control when the widget is destroyed. In most cases, you want a widget to last only as long as the container it is in. To delegate the management of a widget's lifetime to its container, first create it with manage() and pack it into its container with add(). Now, the widget will be destroyed whenever its container is destroyed. gtkmm provides the manage() and add() methods to create and destroy widgets. Every widget except a top-level window must be added or packed into a container in order to be displayed. The manage() function marks a packed widget so that when the widget is added to a container, the container becomes responsible for deleting the widget.
MyWidget::MyWidget()
{
Gtk::Button* pButton = manage(new Gtk::Button("Test"));
add(*pButton); //add aButton to MyWidget
}
Now, when MyWidget is destroyed, the button will also be deleted. It is no
longer necessary to delete pButton to free the button's memory; its deletion
has been delegated to MyWidget.
gtkmm also provides the set_dynamic() method for all widgets. set_dynamic() can be used to generate the same result as manage(), but is more tedious: foo.add( (w=new Gtk::Label("Hello"), w->set_dynamic(), &w) ); is the same as foo.add( manage(new Gtk::Label("Hello")) ); Of course, a top level container will not be added to another container. The programmer is responsible for destroying the top level container using one of the traditional C++ techniques. For instance, your top-level Window might just be an instance in your main() function.. |