\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

\end{document}