Tour3Log: Chapter 3 (and 4)

2 files changed, 22 insertions, 1 deletions

diff --git a/Makefile b/Makefile
index 0c83e52..2abe28b 100644
--- a/Makefile
+++ b/Makefile
@@ -1,5 +1,5 @@
 PRE=au_BentBisballeNyeng_
-all: A1 Log
+all: A1 Tour3_Log
 
 A1:
 	zip ${PRE}$@.zip a1/hello.cc
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}