forked from HowardHinnant/HowardHinnant.github.io
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathclassdecl.html
546 lines (455 loc) · 14 KB
/
classdecl.html
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
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8" />
<title>C++ class declarations</title>
<style>
p {text-align:justify}
li {text-align:justify}
blockquote.note
{
background-color:#E0E0E0;
padding-left: 15px;
padding-right: 15px;
padding-top: 1px;
padding-bottom: 1px;
}
ins {color:#00A000}
del {color:#A00000}
code {white-space:pre;}
</style>
</head>
<body>
<address align=right>
<br/>
<br/>
<a href="mailto:[email protected]">Howard E. Hinnant</a><br/>
2020-02-24<br/>
</address>
<hr/>
<h1 align=center>How I Declare My <code>class</code> And Why</h1>
<p>
When I first learned C++ decades ago, I was taught that data members should be private
and appear at the bottom of the class declaration. The rationale for this was that
the data members were just implementation details, and less important than the class'
API.
</p>
<p>
And I followed this rule for decades ...
</p>
<p>
But I've since come to the conclusion that this is exactly wrong.
</p>
<p>
When I'm reading a class declaration, the very first things I want to know are:
</p>
<ol>
<li>
What resources does this class own?
</li>
<li>
Can the class be default constructed?
</li>
<li>
Can the class be copied or moved?
</li>
<li>
How can the class be constructed (other than by default, copy or move)?
</li>
<li>
What else can one do with the class?
</li>
</ol>
<p>
Note that this is an <i>ordered</i> list: top priority is listed first.
</p>
<p>
Why is it so important that I first learn about resources?
</p>
<p><b>data members:</b></p>
<p>
Once I know that a class owns a dynamically sized array of integers, or several strings,
or a pointer to an incomplete class, or whatever, I immediately start to get a feel for
what this class does. Getting an overview of the data members and their names gives me
that first impression:
</p>
<blockquote>
<pre>
class year_month_day
{
year y_;
month m_;
day d_;
public:
// ...
</pre>
</blockquote>
<p><b>destructor:</b></p>
<p>
With the data members in view, the next most important item for knowing what resources
are owned is the destructor. Is that pointer data member owning or not owning? The
destructor will say. So after the data members, the destructor, if it is to be user-declared
is next:
</p>
<blockquote>
<pre>
class tzdb_list
{
std::atomic<tzdb*> head_{nullptr};
public:
~tzdb_list();
// ...
</pre>
</blockquote>
<p>
Even if the definition of the destructor is not visible (and it shouldn't be at this point),
just the existence of the user-declared destructor, combined with the list of data members,
usually gives a pretty good general idea of what a class owns or doesn't own.
<code>~tzdb_list()</code> apparently needs to do something with the <code>head_</code>
data member which is an atomic pointer. The most likely scenario is that it is going
to delete one or more <code>tzdb</code>.
</p>
<p>
And if the destructor is implicitly compiler declared and provided, then it is not
explicitly listed first. If the reader expects to see the destructor as the first thing
after the data members, then when it is missing, the reader can clearly see it is missing,
as opposed to searching the entire class declaration for a destructor.
</p>
<blockquote>
<pre>
class year_month_day
{
year y_;
month m_;
day d_;
public:
year_month_day() = default;
// ...
</pre>
</blockquote>
<p>
<code>year_month_day</code> clearly has a compiler-declared destructor, otherwise it
would appear prior to the default constructor. And this means that simply running the
destructor for each data member (still clearly visible) is sufficient to destruct the
<code>year_month_day</code>. Indeed, having the data members close by <i>is key</i> to
understanding what the compiler-provided special members do!
</p>
<p>
With the data members and the destructor known, and knowing <i>nothing else</i> about a
class, I know what resources a class owns. And no other information is as important and
concise as this for a quick overview of a class's purpose.
</p>
<p><b>default constructor:</b></p>
<p>
Next, and only if it needs to be user-declared, I list the default constructor.
</p>
<blockquote>
<pre>
class day
{
unsigned char d_;
public:
day() = default;
// ...
</pre>
</blockquote>
<p>
Even if it is compiler-provided, it is often necessary to user-declare it if you want one,
since if you declare <i>any</i> other constructor, the default constructor is inhibited if
not user-declared. And by declaring right after the destructor (if needed), the reader
knows where to look for it, and does <i>not</i> have to search the entire class
declaration to find out if the default constructor is user-declared or not.
</p>
<p>
And if the default constructor is compiler-provided (either implicitly or explicitly),
with the data members nearby, it is easy for the reader to see what the compiler-provided
default constructor does.
</p>
<p>
In the above example for <code>class day</code> it is easy to see that <code>~day()</code>
is compiler-provided, and is trivial because of the single <code>unsigned char</code>
data member. And that it has a trivial default constructor that works just the same way
as default constructing an <code>unsigned char</code>. We've only looked at a few lines of
code of <code>class day</code> and we already know a lot about it.
</p>
<p><b>copy special members: copy constructor, copy assignment operator</b></p>
<p>
If the class needs user-declared copy members, they are declared next, copy constructor
first, copy assignment operator second.
</p>
<blockquote>
<pre>
template <class T>
class shared_ptr
{
T* ptr_ = nullptr;
shared_weak_count* cntl_ = nullptr;
public:
~shared_ptr();
shared_ptr() = default;
shared_ptr(shared_ptr const& sp) noexcept;
shared_ptr& operator=(shared_ptr const& sp) noexcept;
// ...
</pre>
</blockquote>
<p>
As we get into more complicated class types, readability becomes more and more important.
In the above example, we can see that something non-trivial needs to happen in the
destructor, likely leading to ownership of the two pointer data members.
</p>
<p>
We can also see that the default constructor consists of the state that both pointer
data members are set to <code>nullptr</code>. This constructor is implicitly both
<code>constexpr</code> and <code>noexcept</code>.
</p>
<p>
And we can see that this class is copyable, but (most likely) not trivially copyable.
However we can copy without risk of throwing exceptions! Except for the descriptive
name <code>shared_ptr</code> we do not yet know exactly how this class copies, but we
do know that it can be copied.
</p>
<p><b>move special members: move constructor, move assignment operator</b></p>
<p>
If the class needs user-declared move members, they are declared next, move constructor
first, move assignment operator second.
</p>
<blockquote>
<pre>
template <class T, class D = default_delete<T>>
class unique_ptr
{
public:
using deleter_type = D;
using pointer = compute_pointer_t<T, deleter_type>;
private:
pointer ptr_ = nullptr;
deleter_type d_;
public:
~unique_ptr();
unique_ptr() = default;
unique_ptr(unique_ptr&& ptr) noexcept;
unique_ptr& operator=(unique_ptr&& ptr) noexcept;
// ...
</pre>
</blockquote>
<p>
In the above example we can quickly see that <code>ptr_</code> is likely an owned resource
because of the user-declared destructor. And that the type is default constructible by
setting <code>ptr_</code> to <code>nullptr</code>. We can also quickly see that
<code>unique_ptr</code> is <i>not</i> copyable because the copy members are noticeably
missing between the default constructor and the move members. User-declared move members
will implicitly delete the copy members. With very few lines of code we can quickly see
that <code>unique_ptr</code> is a move-only type that owns a resource.
</p>
<p><b>Everything else:</b></p>
<p>
In the first few lines of code we can see the data members, and all six of the special
member functions, whether or not they are user-declared. And where any of the six
special members are compiler-provided, the list of data members (and bases if any) tell
us what the special members do.
</p>
<p>
Next I like to provide the rest of the constructors, followed by the rest of the member
functions.
</p>
<p><b>Rule of what?</b></p>
<p>
So I don't follow a "rule of 5". After all, there are 6 special members:
</p>
<ol>
<li>destructor</li>
<li>default constructor</li>
<li>copy constructor</li>
<li>copy assignment</li>
<li>move constructor</li>
<li>move assignment</li>
</ol>
<p>
Nor do I follow the newer "rule of 0". I follow
<a href="coding_guidelines.html">my own priorities</a>.
</p>
<ol>
<li>Correctness</li>
<li>Run time performance</li>
<li>Compile time performance</li>
<li>Maintainability / Easy to read</li>
<li>Easy to write</li>
</ol>
<p>
Nothing is more important than correctness. And each of the 6 special members must be
correct, no matter whether it is user-provided, user-declared and compiler-provided,
implicitly compiler-provided, or does not exist at all.
</p>
<p>
Additionally I have found that this ordering of the declarations, including omitting any
that are not needed, provides the best readability in class declarations. It is
consistent and concise as possible. It provides the most important characteristics of a
class as soon as possible to the reader. It prevents the reader from having to search the
entire class declaration for compiler-declared special members which are otherwise
invisible to the reader.
</p>
<p><b>Testing</b></p>
<p>
No matter how you declare your class and its special members, unit tests are the place
to be verbose.
</p>
<hr>
<p>This:</p>
<blockquote>
<pre>
class year_month_day
{
year y_;
month m_;
day d_;
public:
year_month_day() = default;
// ...
</pre>
</blockquote>
<p>
Can be tested with:
</p>
<blockquote>
<pre>
static_assert(std::is_trivially_destructible<year_month_day>{});
static_assert(std::is_trivially_default_constructible<year_month_day>{});
static_assert(std::is_trivially_copy_constructible<year_month_day>{});
static_assert(std::is_trivially_copy_assignable<year_month_day>{});
static_assert(std::is_trivially_move_constructible<year_month_day>{});
static_assert(std::is_trivially_move_assignable<year_month_day>{});
</pre>
</blockquote>
<hr>
<p>
This:
</p>
<blockquote><pre>
class tzdb_list
{
std::atomic<tzdb*> head_{nullptr};
public:
~tzdb_list();
tzdb_list() = default;
tzdb_list(tzdb_list&& x) noexcept;
// ...
</pre></blockquote>
<p>
Can be tested with:
</p>
<blockquote>
<pre>
static_assert( std::is_nothrow_destructible<tzdb_list>{});
static_assert( std::is_nothrow_default_constructible<tzdb_list>{});
static_assert(!std::is_copy_constructible<tzdb_list>{});
static_assert(!std::is_copy_assignable<tzdb_list>{});
static_assert( std::is_nothrow_move_constructible<tzdb_list>{});
static_assert(!std::is_move_assignable<tzdb_list>{});
</pre>
</blockquote>
<hr>
<p>This:</p>
<blockquote>
<pre>
class day
{
unsigned char d_;
public:
day() = default;
// ...
</pre>
</blockquote>
<p>
Can be tested with:
</p>
<blockquote>
<pre>
static_assert(std::is_trivially_destructible<day>{});
static_assert(std::is_trivially_default_constructible<day>{});
static_assert(std::is_trivially_copy_constructible<day>{});
static_assert(std::is_trivially_copy_assignable<day>{});
static_assert(std::is_trivially_move_constructible<day>{});
static_assert(std::is_trivially_move_assignable<day>{});
</pre>
</blockquote>
<hr>
<p>This:</p>
<blockquote>
<pre>
template <class T>
class shared_ptr
{
T* ptr_ = nullptr;
shared_weak_count* cntl_ = nullptr;
public:
~shared_ptr();
shared_ptr() = default;
shared_ptr(shared_ptr const& sp) noexcept;
shared_ptr& operator=(shared_ptr const& sp) noexcept;
// ...
</pre>
</blockquote>
<p>
Can be tested with:
</p>
<blockquote>
<pre>
static_assert(std::is_nothrow_destructible<shared_ptr<int>>{});
static_assert(std::is_nothrow_default_constructible<shared_ptr<int>>{});
static_assert(std::is_nothrow_copy_constructible<shared_ptr<int>>{});
static_assert(std::is_nothrow_copy_assignable<shared_ptr<int>>{});
static_assert(std::is_nothrow_move_constructible<shared_ptr<int>>{});
static_assert(std::is_nothrow_move_assignable<shared_ptr<int>>{});
</pre>
</blockquote>
<hr>
<p>And this:</p>
<blockquote>
<pre>
template <class T, class D = default_delete<T>>
class unique_ptr
{
public:
using deleter_type = D;
using pointer = compute_pointer_t<T, deleter_type>;
private:
pointer ptr_ = nullptr;
deleter_type d_;
public:
~unique_ptr();
unique_ptr() = default;
unique_ptr(unique_ptr&& ptr) noexcept;
unique_ptr& operator=(unique_ptr&& ptr) noexcept;
// ...
</pre>
</blockquote>
<p>
Can be tested with:
</p>
<blockquote>
<pre>
static_assert( std::is_nothrow_destructible<unique_ptr<int>>{});
static_assert( std::is_nothrow_default_constructible<unique_ptr<int>>{});
static_assert(!std::is_copy_constructible<unique_ptr<int>>{});
static_assert(!std::is_copy_assignable<unique_ptr<int>>{});
static_assert( std::is_nothrow_move_constructible<unique_ptr<int>>{});
static_assert( std::is_nothrow_move_assignable<unique_ptr<int>>{});
</pre>
</blockquote>
<hr>
<p>
In each case, readable and concise in the declaration, thorough and verbose in the unit
test.
</p>
<p><b>Education</b></p>
<p>
And perhaps this now-well-known table can help with knowing which special member functions
get implicitly defaulted, deleted or inhibited when the user declares other special member functions:
</p>
<img src="smf.jpg" width=800>
<p>
See <a href="https://www.youtube.com/watch?v=vLinb2fgkHk&feature=youtu.be"> this
presentation for a detailed description of this table.</a>
</p>
</body>
</html>