summaryrefslogtreecommitdiff
path: root/tour3_log/tour3_log.tex
diff options
context:
space:
mode:
Diffstat (limited to 'tour3_log/tour3_log.tex')
-rw-r--r--tour3_log/tour3_log.tex21
1 files changed, 21 insertions, 0 deletions
diff --git a/tour3_log/tour3_log.tex b/tour3_log/tour3_log.tex
index fbec0c8..5746a81 100644
--- a/tour3_log/tour3_log.tex
+++ b/tour3_log/tour3_log.tex
@@ -19,4 +19,25 @@ 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}