diff options
| -rw-r--r-- | Makefile | 2 | ||||
| -rw-r--r-- | tour3_log/tour3_log.tex | 21 |
2 files changed, 22 insertions, 1 deletions
@@ -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} |