Widgets

25.1.1. Normal C++ memory management
25.1.2. Managed Widgets

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
25.1.1.2. Function scope widgets
25.1.1.3. Dynamic allocation with new and delete

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 disadvantage of using class scope widgets is revealing the class implementation rather than the class interface in the class header.

#include <gtkmm/button.h>
#include <gtkmm/window.h>
class Foo : public Gtk::Window
{
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();
  ...
  app->run();
}

Although, in most cases, the programmer will prefer to allow containers to automatically destroy their children using Gtk::manage() (see below), the programmer is not required to use Gtk::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 Gtk::manage() and pack it into its container with Gtk::Container::add(), Gtk::Box::pack_start(), or a similar method. 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 widget so that when the widget is added to a container, the container becomes responsible for deleting the widget.

MyContainer::MyContainer()
{
  Gtk::Button* pButton = Gtk::manage(new Gtk::Button("Test"));
  add(*pButton); //add *pButton to MyContainer
}

Now, when objects of type MyContainer 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 MyContainer object.

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

25.1.1. Normal C++ memory management

25.1.1.1. Class Scope widgets

25.1.1.2. Function scope widgets

25.1.1.3. Dynamic allocation with new and delete

25.1.2. Managed Widgets

25.1.2.1. Dynamic allocation with manage() and add()

About