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
|
\title{Tour 3 Log}
\input{preamble.tex}
\section*{Chapter 1}
This chapter is quite a lot to take in at once, but looking back at
it, I don't see any thing that could meaningfully be left out - and it
leaves the reader in a known ``minimal'' state, for the rest of the
book to build on.
Drawing perspective to other languages, that might be known to the
reader might make it easier to grasp the different concepts, but since
the readers are not all familiar with the same set of languages, it
might end up having the opposite effect...
\section*{Chapter 2}
The introduction of the concept of a class along with the constructor
happens in this chapter, but it confused me that the destructor is not
mentioned until chapter 5.
Mentioning it here might help give a better overall picture of what a
class is. I recognize the fact that it might be hard to do without
also starting to talk about free'ing of the memory for the Vector
which clearly belongs in chapter 5...
\section*{Chapter 3: Modularity}
I find enum class forward declaration and the option of specifying
the underlying type incredibly useful, but this is not mentioned
here. Should it be?
With modules, how does one get access to what is the ``header file''
for non-modules? A header file acts both as declarations for the
compiler but also as specification/documentation for the developer.
In a module (as I have seen them imeplemented), the declarations and
implementations are put in the same file, so would a developer have to
read this file to know how to use the module?
When doing structured binding, are we not in danger of relying too
heavily on implementation specific details of the returned type? If
for example it is a struct supplied by someone else, and this someone
decides to alter the order of the members or add a new one in the middle?
I guess this is exactly what advice 13 is about?
\section*{Chapter 4: Error Handling}
Well covered topic. No comments or questions
\section*{Chapter 5: Classes}
It is curious how, when overloading the virtual destructor, both the
overloaded and base-class destructors are called - in contrast to
other member functions where only the overloaded member function is
called.
It would be instructive to also see how the base-class member
functions can be called from the overloaded one, whenever needed.
\bigskip
At the bottom of page 68 (in section 5.5.3) there is an example of usage of
the \texttt{unique\_ptr} to avoid memory leaks. Is this intentionally
not using \texttt{make\_unique} to construct the object?
\bigskip
How does performance compare between classes inheriting an abstract
interface vs. classes inheriting a ``regular'' virtual class?
Is there for example an optimization shortcut when inheriting an
abstract interface that makes it possible to not carry around on
a \texttt{vtbl}?
\section*{Chapter 6: Essential Operations}
Is it considered good or bad practice to simply call the copy
assignment operator on a default constructed object inside the copy
constructor?
(or vice versa) instead of ``duplicating'' the code itself:
\begin{verbatim}
class O
{
public:
O() = default;
O(const O& o) : O()
{
*this = o; // call assignment operator
}
O& operator=(const O& o)
{
// .. do member assignments
return *this;
}
};
\end{verbatim}
I imagine that most implementations of copy constructor and copy
assignment would be very similar.
Would something similar make sense for move?
And keeping with that thought, wouldn't it be possible to only provide
one of them and have the compiler generate the other?
\bigskip
When is returned \texttt{*this} in the copy operator actually used?
Is this for chained assignments such as: \texttt{Obj o = a = b;} ?
\bigskip
When working on older C++ code (pre-C++11, from before introduction of
move semantics) what would be considered a good strategy for ``upgrading''
to a modern version of C++? Would simply altering of the compiler
arguments potentially leave classes without move constructors leading
to corrupt pointer members as described in section 6.2.1?
Or perhaps the compiler knows that it can just never be moved?
\bigskip
This section talks a bit about garbage collectors and it reminded me
that in one of the first lectures you mentioned an open source garbage
collector that could be plugged into C++, but you couldn't recall the
name of it. I would be very interesting to know more about this topic
- especially for use in debugging or testing.
\bigskip
What does the comma operator usually do? Would it be possible to have
\texttt{a} and \texttt{b} interact through the comma operator when
supplied as parameters to a function \texttt{func(a,b)}?
\section*{Chapter 18: Concurrency}
%Would using a std::atomic<bool> for stopping threads result in
%problems, compared to
%using \texttt{std::stop\_source}/\texttt{std::stop\_token}?
%\begin{verbatim}
%void thread_func(std::atomic<bool>& running)
%{
% while(running.load())
% {
% // do something useful
% }
%}
%
%int main()
%{
% std::atomic<bool> running{true};
% std::thread t([&](){ thread_func(running); });
%
% // do stuff
%
% running.store(false); // request to stop
% t.join();
%}
%\end{verbatim}
%
%\bigskip
It is mentioned that coroutines can execute in parallel. Is this when
used alongside for example \texttt{std::async}?
It would be interesting to see an example of this?
\end{document}
|
