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
|
\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?
\section*{Chapter 7: Templates}
Does the full template implementation always have to be available at
instantiation time? (ie. in a header file) or can parts of the code be in
its own compilation unit so a developer does not have to be
``exposed'' to all the implementation details of a templated class.
\bigskip
Is a lambda always allocated on the stack or will it use the
freestore under certains circumstances, like std::string's SSO?
\bigskip
Is it possible to somehow know, with a constexpr if, inside a
constexpr function if it is currently being invoked in a constexpr
context?
\section*{Chapter 8: Concepts and Generic Programming}
Is it somehow possible to indicate which specific types are allowed as
template parameters? If for example it is unwanted to generate both a
\texttt{Foo<int>} and \texttt{Foo<long int>} by accident? My guess is
that this can be done with a concept/requires?
\bigskip
%In the example with \texttt{advance} it is stated
%that \texttt{random\_access\_iterator} is ``stronger''
%than \texttt{forward\_iterator}. Where/how is this relationship
%established? does one extend the other for example?
%In particular, how would two concepts be ranked if they are
%completely disjoint in their respective requirement rules?
In the case of a concept overload ambiguity, what can a developer do
to point to a specific one and fix the ambiguity?
\bigskip
Are there any concepts required to be ``pre'' defined by the compiler
that would otherwise be hard to express with \texttt{requires} clauses?
Some of the fundamental language concepts for example.
\end{document}
|
