Widgets

25.1.1 Normal C++ memory management

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:

25.1.1.1 Class Scope widgets

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
};

25.1.1.2 Function scope widgets

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();
}

25.1.1.3 Dynamic allocation with new and delete

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.

25.1.2 Managed Widgets

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.

25.1.2.1 Dynamic allocation with manage() and add()

gtkmm provides the manage() function 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 objects of type MyWidget are 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 the MyWidget object.

gtkmm also provides the set_manage() method for all widgets. This can be used to generate the same result as manage(), but is more tedious:

foo.add( (w=new Gtk::Label("Hello"), w->set_manage(), &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..

Widgets Shared resources

Sobre