1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
|
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<link rel="stylesheet" href="highlight.min.css">
<script src="highlight.min.js"></script><script>
hljs.configure({languages: ['cpp']});
hljs.highlightAll();
</script><title>Chapter 25. Memory management</title>
<link rel="stylesheet" type="text/css" href="style.css">
<meta name="generator" content="DocBook XSL Stylesheets Vsnapshot">
<link rel="home" href="index.html" title="Programming with gtkmm 4">
<link rel="up" href="index.html" title="Programming with gtkmm 4">
<link rel="prev" href="sec-idle-functions.html" title="Idle Functions">
<link rel="next" href="sec-memory-shared-resources.html" title="Shared resources">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
<div class="navheader">
<table width="100%" summary="Navigation header">
<tr><th colspan="3" align="center">Chapter 25. Memory management</th></tr>
<tr>
<td width="20%" align="left">
<a accesskey="p" href="sec-idle-functions.html"><img src="icons/prev.png" alt="Prev"></a> </td>
<th width="60%" align="center"> </th>
<td width="20%" align="right"> <a accesskey="n" href="sec-memory-shared-resources.html"><img src="icons/next.png" alt="Next"></a>
</td>
</tr>
</table>
<hr>
</div>
<div class="chapter">
<div class="titlepage"><div><div><h1 class="title">
<a name="chapter-memory"></a>Chapter 25. Memory management</h1></div></div></div>
<div class="toc">
<p><b>Table of Contents</b></p>
<ul class="toc">
<li><span class="section"><a href="chapter-memory.html#sec-memory-widgets">Widgets</a></span></li>
<li><span class="section"><a href="sec-memory-shared-resources.html">Shared resources</a></span></li>
</ul>
</div>
<div class="section">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
<a name="sec-memory-widgets"></a>Widgets</h2></div></div></div>
<div class="section">
<div class="titlepage"><div><div><h3 class="title">
<a name="memory-normal"></a>Normal C++ memory management</h3></div></div></div>
<p>
<span class="application">gtkmm</span> 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 <code class="literal">new</code> and
<code class="literal">delete</code> 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.
</p>
<p>
An important difference in <span class="application">gtkmm</span>-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 <span class="application">gtkmm</span>-4.0 you must now remove the widget from its parent
first. See <a class="link" href="changes-gtkmm4.html" title="Chapter 5. Changes in gtkmm-4.0 and glibmm-2.68">Changes in <span class="application">gtkmm</span>-4.0</a>.
</p>
<p>Here are some examples of normal C++ memory management:</p>
<div class="section">
<div class="titlepage"><div><div><h4 class="title">
<a name="memory-class-scope"></a>Class Scope widgets</h4></div></div></div>
<p>
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 <code class="literal">delete</code> a widget.
</p>
<p>
The primary disadvantage of using class scope widgets is revealing
the class implementation rather than the class interface in the class header.
</p>
<pre class="programlisting"><code class="code">#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
};
</code></pre>
</div>
<div class="section">
<div class="titlepage"><div><div><h4 class="title">
<a name="memory-function-scope"></a>Function scope widgets</h4></div></div></div>
<p>
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.
</p>
<pre class="programlisting"><code class="code">{
Gtk::Button aButton;
aButton.set_visible(true);
...
app->run();
}
</code></pre>
<p>
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 <code class="methodname">Gtk::Application::run()</code> or
<code class="methodname">Gtk::Application::make_window_and_run()</code> returns.
</p>
</div>
<div class="section">
<div class="titlepage"><div><div><h4 class="title">
<a name="memory-dynamic-allocation"></a>Dynamic allocation with new and delete</h4></div></div></div>
<p>
Usually, the programmer will prefer to allow containers to automatically destroy
their children by creating them using <code class="function">Gtk::make_managed()</code>
(see below). This is not strictly required, as the <code class="literal">new</code> and
<code class="literal">delete</code> 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 <code class="function">Gtk::make_managed()</code> and
let their parent destroy them, than to manually perform dynamic allocation.
</p>
<pre class="programlisting"><code class="code">auto pButton = new Gtk::Button("Test");
// do something useful with pButton
delete pButton;
</code></pre>
<p>Here, the programmer deletes <code class="varname">pButton</code> to prevent a memory leak.
</p>
</div>
</div>
<div class="section">
<div class="titlepage"><div><div><h3 class="title">
<a name="memory-managed-widgets"></a>Managed Widgets</h3></div></div></div>
<p>
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 <code class="function">Gtk::make_managed()</code> and then
pack it into its container with <code class="methodname">Gtk::Box::append()</code> or
a similar method. Now the widget will be destroyed whenever its container is destroyed.
</p>
<div class="section">
<div class="titlepage"><div><div><h4 class="title">
<a name="memory-managed-dynamic"></a>Dynamic allocation with make_managed() and append()</h4></div></div></div>
<p>
<span class="application">gtkmm</span> provides ways including the <code class="function">make_managed()</code> function
and <code class="methodname">Gtk::Box::append()</code> method to simplify creation
and destruction of widgets whose lifetime can be managed by a parent.
</p>
<p>
Every widget except a top-level window must be added to a parent container in
order to be displayed. The <code class="function">manage()</code> 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 <code class="function">manage()</code>, passing in the result of a
<code class="literal">new</code> expression that created a dynamically allocated widget.
</p>
<p>
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 <code class="literal">new</code> operator, which was
required when passing a newly created widget to <code class="function">manage()</code>.
Therefore, <span class="application">gtkmm</span> has added <code class="function">make_managed()</code>, which combines
creation and marking with <code class="function">manage()</code> into a single step. This
avoids you having to write <code class="literal">new</code>, which is discouraged in
modern C++ style, and more clearly expresses intent to create a managed widget.
</p>
<pre class="programlisting"><code class="code">MyContainer::MyContainer()
{
auto pButton = Gtk::make_managed<Gtk::Button>("Test");
append(*pButton); //add *pButton to MyContainer
}
</code></pre>
<p>
Now, when objects of type <code class="classname">MyContainer</code> are destroyed, the
button will also be deleted. It is no longer necessary to delete <code class="varname">pButton</code>
to free the button's memory; its deletion has been delegated to the
<code class="classname">MyContainer</code> object.
</p>
<p>
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 <code class="methodname">Gtk::Box::remove()</code>),
it's deleted by the container.
</p>
<p>
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 <code class="methodname">Gtk::Application::make_window_and_run()</code>
create a top-level window and delete it when it's hidden.
</p>
</div>
</div>
</div>
</div>
<div class="navfooter">
<hr>
<table width="100%" summary="Navigation footer">
<tr>
<td width="40%" align="left">
<a accesskey="p" href="sec-idle-functions.html"><img src="icons/prev.png" alt="Prev"></a> </td>
<td width="20%" align="center"> </td>
<td width="40%" align="right"> <a accesskey="n" href="sec-memory-shared-resources.html"><img src="icons/next.png" alt="Next"></a>
</td>
</tr>
<tr>
<td width="40%" align="left" valign="top">Idle Functions </td>
<td width="20%" align="center"><a accesskey="h" href="index.html"><img src="icons/home.png" alt="Home"></a></td>
<td width="40%" align="right" valign="top"> Shared resources</td>
</tr>
</table>
</div>
</body>
</html>
|
