From 5deeff26bd5309700aaf43ede0ed23217a0a5fd8 Mon Sep 17 00:00:00 2001
From: Bent Bisballe Nyeng <deva@aasimon.org>
Date: Tue, 25 Jul 2023 21:18:43 +0200
Subject: Tour3Log: Chapter 5 and 6

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

(limited to 'tour3_log/tour3_log.tex')

diff --git a/tour3_log/tour3_log.tex b/tour3_log/tour3_log.tex
index 5746a81..b512b44 100644
--- a/tour3_log/tour3_log.tex
+++ b/tour3_log/tour3_log.tex
@@ -40,4 +40,82 @@ I guess this is exactly what advice 13 is about?
 \section*{Chapter 4: Error Handling}
 Well covered topic. No comments or questions
 
+\section*{Chapter 5: Classes}
+It is curious how, when overloading the virtual destructor, both the
+overloaded and base-class destructors are called - in contrast to
+other member functions where only the overloaded member function is
+called.
+It would be instructive to also see how the base-class member
+functions can be called from the overloaded one, whenever needed.
+
+\bigskip
+
+At the bottom of page 68 (in section 5.5.3) there is an example of usage of
+the \texttt{unique\_ptr} to avoid memory leaks. Is this intentionally
+not using \texttt{make\_unique} to construct the object?
+
+\bigskip
+
+How does performance compare between classes inheriting an abstract
+interface vs. classes inheriting a ``regular'' virtual class?
+Is there for example an optimization shortcut when inheriting an
+abstract interface that makes it possible to not carry around on
+a \texttt{vtbl}?
+
+\section*{Chapter 6: Essential Operations}
+Is it considered good or bad practice to simply call the copy
+assignment operator on a default constructed object inside the copy
+constructor?
+(or vice versa) instead of ``duplicating'' the code itself:
+\begin{verbatim}
+class O
+{
+public:
+  O() = default;
+  O(const O& o) : O()
+  {
+    *this = o; // call assignment operator
+  }
+
+  O& operator=(const O& o)
+  {
+    // .. do member assignments
+    return *this;
+  }
+};
+\end{verbatim}
+I imagine that most implementations of copy constructor and copy
+assignment would be very similar.
+Would something similar make sense for move?
+And keeping with that thought, wouldn't it be possible to only provide
+one of them and have the compiler generate the other?
+
+\bigskip
+
+When is returned \texttt{*this} in the copy operator actually used?
+Is this for chained assignments such as: \texttt{Obj o = a = b;} ?
+
+\bigskip
+
+When working on older C++ code (pre-C++11, from before introduction of
+move semantics) what would be considered a good strategy for ``upgrading''
+to a modern version of C++? Would simply altering of the compiler
+arguments potentially leave classes without move constructors leading
+to corrupt pointer members as described in section 6.2.1?
+Or perhaps the compiler knows that it can just never be moved?
+
+\bigskip
+
+This section talks a bit about garbage collectors and it reminded me
+that in one of the first lectures you mentioned an open source garbage
+collector that could be plugged into C++, but you couldn't recall the
+name of it. I would be very interesting to know more about this topic
+- especially for use in debugging or testing.
+
+\bigskip
+
+What does the comma operator usually do? Would it be possible to have
+\texttt{a} and \texttt{b} interact through the comma operator when
+supplied as parameters to a function \texttt{func(a,b)}?
+
 \end{document}
-- 
cgit v1.2.3