From 48b880aaed4e53964758d7bfeeb5650f462a9f15 Mon Sep 17 00:00:00 2001
From: Bent Bisballe Nyeng <deva@aasimon.org>
Date: Mon, 24 Jul 2023 21:06:56 +0200
Subject: Tour3Log: Chapter 3 (and 4)

---
 tour3_log/tour3_log.tex | 21 +++++++++++++++++++++
 1 file changed, 21 insertions(+)

(limited to 'tour3_log/tour3_log.tex')

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}
-- 
cgit v1.2.3

