Chapter 25. Memory management

# Chapter 25. Memory management

## Widgets

### 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.

An important difference in gtkmm-4.0 vs. older versions is that a C++ widgetʼs destruction no longer causes the widget to be destroyed if itʼs within a parent; in that case the C GtkWidget stays alive. If you had relied on that behavior in an older version, in gtkmm-4.0 you must now remove the widget from its parent first. See Changes in gtkmm-4.0.

Here are some examples of normal C++ memory management:

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

#### 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.set_visible(true);
      ...
      app->run();
    }

However, this technique is rarely useful. Most widgets can't safely be created before the application has been registered or activated. They can't safely be deleted after `Gtk::Application::run()` or `Gtk::Application::make_window_and_run()` returns.

#### Dynamic allocation with new and delete

Usually, the programmer will prefer to allow containers to automatically destroy their children by creating them using `Gtk::make_managed()` (see below). This is not strictly required, as the `new` and `delete` operators may also be used, but modern C++ style discourages those in favor of safer models of memory management, so it is better to create widgets using `Gtk::make_managed()` and let their parent destroy them, than to manually perform dynamic allocation.

    auto pButton = new Gtk::Button("Test");
    // do something useful with pButton
    delete pButton;

Here, the programmer deletes `pButton` to prevent a memory leak.

### 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, create it with `Gtk::make_managed()` and then pack it into its container with `Gtk::Box::append()` or a similar method. Now the widget will be destroyed whenever its container is destroyed.

#### Dynamic allocation with make_managed() and append()

gtkmm provides ways including the `make_managed()` function and `Gtk::Box::append()` method to simplify creation and destruction of widgets whose lifetime can be managed by a parent.

Every widget except a top-level window must be added to a parent container in order to be displayed. The `manage()` function marks a widget so that when that widget is added to a parent container, said container becomes responsible for deleting the widget, meaning the user no longer needs to do so. The original way to create widgets whose lifetime is managed by their parent in this way was to call `manage()`, passing in the result of a `new` expression that created a dynamically allocated widget.

However, usually, when you create such a widget, you will already know that its parent container should be responsible for destroying it. In addition, modern C++ style discourages use of the `new` operator, which was required when passing a newly created widget to `manage()`. Therefore, gtkmm has added `make_managed()`, which combines creation and marking with `manage()` into a single step. This avoids you having to write `new`, which is discouraged in modern C++ style, and more clearly expresses intent to create a managed widget.

    MyContainer::MyContainer()
    {
      auto pButton = Gtk::make_managed<Gtk::Button>("Test");
      append(*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.

If you never added the widget to any parent container, it's your responsibility to delete it. If you add it to a container widget, and later remove it (for instance with `Gtk::Box::remove()`), it's deleted by the container.

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. Or you can let `Gtk::Application::make_window_and_run()` create a top-level window and delete it when it's closed.

Idle Functions |  | Shared resources