\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?

\end{document}