summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorBent Bisballe Nyeng <deva@aasimon.org>2023-07-25 21:18:43 +0200
committerBent Bisballe Nyeng <deva@aasimon.org>2023-07-25 21:18:43 +0200
commit5deeff26bd5309700aaf43ede0ed23217a0a5fd8 (patch)
tree8828fee4326a01595ecbc0973f231733fa6b7a90
parent48b880aaed4e53964758d7bfeeb5650f462a9f15 (diff)
Tour3Log: Chapter 5 and 6
-rw-r--r--tour3_log/tour3_log.tex78
1 files changed, 78 insertions, 0 deletions
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}