From fdee47f9a7d36325e4d4662b93b602a7b8b6a584 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?S=C3=A9bastien=20Gilles?= <sebastien.gilles@inria.fr>
Date: Thu, 8 Feb 2024 17:58:35 +0100
Subject: [PATCH 01/30] #29 Remove an ambiguous sentence.

---
 2-ObjectProgramming/2-Member-functions.ipynb | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/2-ObjectProgramming/2-Member-functions.ipynb b/2-ObjectProgramming/2-Member-functions.ipynb
index 856e353..4e1c205 100644
--- a/2-ObjectProgramming/2-Member-functions.ipynb
+++ b/2-ObjectProgramming/2-Member-functions.ipynb
@@ -93,7 +93,7 @@
    "source": [
     "## The `this` keyword\n",
     "\n",
-    "The `this->` may have puzzled you: it is a keyword to refer to the current object. So when you call `v.Init(...)`, this is an implicit reference to `v`.\n",
+    "The `this->` may have puzzled you: it is a keyword to refer to the current object.\n",
     "\n",
     "In most cases, it might be altogether removed; we have to put it explicitly here solely because we named the `Init` parameters with the same name as the data attribute. If not, we could have avoided to mention it completely.\n",
     "\n",
@@ -488,9 +488,7 @@
    "cell_type": "markdown",
    "metadata": {},
    "source": [
-    "[© Copyright](../COPYRIGHT.md)   \n",
-    "",
-    ""
+    "[© Copyright](../COPYRIGHT.md)   \n"
    ]
   }
  ],
-- 
GitLab


From 533c5f31648db6b46261cc63aea9d838408d3f71 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?S=C3=A9bastien=20Gilles?= <sebastien.gilles@inria.fr>
Date: Thu, 8 Feb 2024 18:11:58 +0100
Subject: [PATCH 02/30] #43 Update Copyright file.

---
 COPYRIGHT.md | 15 +++++++++++----
 1 file changed, 11 insertions(+), 4 deletions(-)

diff --git a/COPYRIGHT.md b/COPYRIGHT.md
index 4ba05bb..9c507a6 100644
--- a/COPYRIGHT.md
+++ b/COPYRIGHT.md
@@ -1,12 +1,19 @@
-© _CNRS 2016_ - _Inria 2018-2022_   
+© _CNRS 2016_ - _Inria 2018-2024_   
 
 This notebook is an adaptation of a [lecture](https://gitlab.inria.fr/formations/cpp/DebuterEnCpp) prepared by David Chamont (CNRS) with the help of Vincent Rouvreau (Inria) under the terms of the licence [Attribution-NonCommercial-ShareAlike 4.0 International (CC BY-NC-SA 4.0)](http://creativecommons.org/licenses/by-nc-sa/4.0/)
 
-Present version has been written by several Inria engineers:
+Present version has been written by several Inria engineers that acted as lecturers:
 
 - Sébastien Gilles (SED Saclay): _2018 - present_
 - Vincent Rouvreau (SED Saclay): _2018 - present_
 - Vicente Mataix Ferrandiz (SED Paris): _2021_
-- Laurent Steff (SED Saclay): _2021 - present_
+- Laurent Steff (SED Saclay): _2021 - 2023_
+- Jérôme Diaz (M3DISIM team): _2024 - present_
 
-and is using the same licence.
\ No newline at end of file
+and is using the same licence as the original training session.
+
+Many thanks for contributors:
+
+- Mathias Malandain (SED Rennes)
+
+and the participants of former training sessions whose comments help us improve the support over time!
\ No newline at end of file
-- 
GitLab


From 86061baddf019993a9b8f63525678963f63856ef Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?S=C3=A9bastien=20Gilles?= <sebastien.gilles@inria.fr>
Date: Thu, 8 Feb 2024 19:16:06 +0100
Subject: [PATCH 03/30] #97 Add a paragraph to explain in C functions overload
 are not possible.

---
 1-ProceduralProgramming/4-Functions.ipynb | 54 ++++++++++++++++++++++-
 1 file changed, 53 insertions(+), 1 deletion(-)

diff --git a/1-ProceduralProgramming/4-Functions.ipynb b/1-ProceduralProgramming/4-Functions.ipynb
index df8425f..79ad50e 100644
--- a/1-ProceduralProgramming/4-Functions.ipynb
+++ b/1-ProceduralProgramming/4-Functions.ipynb
@@ -529,7 +529,7 @@
    "cell_type": "markdown",
    "metadata": {},
    "source": [
-    "### [WARNING] Return type doesn't count!\n",
+    "### **[WARNING]** Return type doesn't count!\n",
     "\n",
     "It's not the entire signature of the function that is taken into account when possible ambiguity is sought by the compiler: the return type isn't taken into account. So the following cases won't be accepted:"
    ]
@@ -552,6 +552,58 @@
     "If we think about it, it is rather logical: in C++ we are not required to use the return type of a function (it's not the case in all languages: Go follows a different path on that topic for instance). The issue then is that the compiler has no way to know which `g(int)` is supposed to be called with `g(5)` for instance."
    ]
   },
+  {
+   "cell_type": "markdown",
+   "metadata": {},
+   "source": [
+    "### **[WARNING]** This is a C++ only feature and won't work in C!"
+   ]
+  },
+  {
+   "cell_type": "markdown",
+   "metadata": {},
+   "source": [
+    "In C you can't do that: if you run a simple program with overload:\n",
+    "\n",
+    "````c\n",
+    "#include <stdio.h>\n",
+    "\n",
+    "void f()\n",
+    "{\n",
+    "    printf(\"No argument version\");   \n",
+    "}\n",
+    "\n",
+    "void f(int a)\n",
+    "{\n",
+    "    printf(\"Int argument version\");   \n",
+    "}\n",
+    "\n",
+    "int main()\n",
+    "{\n",
+    "    return 0;\n",
+    "}\n",
+    "````\n",
+    "\n",
+    "you will get error messages such as: \n",
+    "\n",
+    "````shell\n",
+    "prog.c:8:6: error: redefinition of 'f'\n",
+    "    8 | void f(int a)\n",
+    "      |      ^\n",
+    "prog.c:3:6: note: previous definition of 'f' with type 'void()'\n",
+    "    3 | void f()\n",
+    "````\n",
+    "\n",
+    "(you may check this with [Wandbox](https://wandbox.org/) and select C instead of C++ as language).\n"
+   ]
+  },
+  {
+   "cell_type": "markdown",
+   "metadata": {},
+   "source": [
+    "If you're interested to understand why, you may read [this Wikipedia page](https://en.wikipedia.org/wiki/Name_mangling) (to put in a nutshell, C and C++ chose to handle very differently how to handle the symbols; C++ will use something called _mangling_ to be able to disambiguate between the different overloads)."
+   ]
+  },
   {
    "cell_type": "markdown",
    "metadata": {},
-- 
GitLab


From 46b2a8451708c60ea4616a76a0cf682765368f49 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?S=C3=A9bastien=20Gilles?= <sebastien.gilles@inria.fr>
Date: Thu, 8 Feb 2024 19:17:18 +0100
Subject: [PATCH 04/30] #60 Detail a bit more the data attribute initialization
 through the `:` syntax.

---
 .../3-constructors-destructor.ipynb           | 93 +++++++++++++++++--
 1 file changed, 83 insertions(+), 10 deletions(-)

diff --git a/2-ObjectProgramming/3-constructors-destructor.ipynb b/2-ObjectProgramming/3-constructors-destructor.ipynb
index acd05ac..99e6bd6 100644
--- a/2-ObjectProgramming/3-constructors-destructor.ipynb
+++ b/2-ObjectProgramming/3-constructors-destructor.ipynb
@@ -186,9 +186,14 @@
    "cell_type": "markdown",
    "metadata": {},
    "source": [
-    "## Initializing a reference data attribute\n",
+    "## The importance of the `:` syntax\n",
     "\n",
-    "We saw above a new syntax to initialize data attributes, but there is no harm defining the same as we did in our former `Init()` method. That is however not true when there is a reference data attribute, for which the reference must absolutely be defined with the new syntax:"
+    "We saw just above that we may init data attributes either in the body of the constructor or before the body with the `:` syntax.\n",
+    "\n",
+    "In the above example, both are fine and work as expected.\n",
+    "\n",
+    "However, there are several cases for which you **must** use the `:` syntax; here are two of them.\n",
+    "\n"
    ]
   },
   {
@@ -213,7 +218,9 @@
     "    \n",
     "    const First& first_;\n",
     "    \n",
-    "    Second(const First& first);\n",
+    "    Second(const First& first, int value);\n",
+    "\n",
+    "    const int value_;\n",
     "};"
    ]
   },
@@ -223,9 +230,11 @@
    "metadata": {},
    "outputs": [],
    "source": [
-    "Second::Second(const First& first)\n",
+    "Second::Second(const First& first, int value)\n",
     "{\n",
     "    first_ = first; // COMPILATION ERROR: can't initialize a reference data attribute here!    \n",
+    "\n",
+    "    value_ = value; // COMPILATION ERROR: can't change the value of a const variable!\n",
     "}"
    ]
   },
@@ -235,8 +244,9 @@
    "metadata": {},
    "outputs": [],
    "source": [
-    "Second::Second(const First& first)\n",
-    ": first_(first) // OK!\n",
+    "Second::Second(const First& first, int value)\n",
+    ": first_(first), // OK!\n",
+    "value_(value)\n",
     "{ } "
    ]
   },
@@ -244,9 +254,74 @@
    "cell_type": "markdown",
    "metadata": {},
    "source": [
-    "The reason for this behaviour is that the reference must be defined at the very moment the object is created, and in fact the body of a constructor is run _after_ the actual creation occurs. With the proper syntax, the data is properly initialized in the same time the object is created.\n",
+    "With the `:` syntax, the attributes are filled with their expected values _as soon as_ the object is created.\n",
+    "\n",
+    "On the other hand, the body of the constructor is run _after_ the actual creation occurs.\n",
+    "\n",
+    "So concerning data attributes if their value is set in the constructor it is actually an _assignment_ that takes place and replace the default value built at construction.\n",
     "\n",
+    "The cases in which the data attributes **must** be defined by the `:` constructor are:\n",
     "\n",
+    "- When the data attribute can't be copied (this case covers both cases already seen).\n",
+    "- When the type of the data attribute doesn't foresee a default constructor (i.e. a constructor without arguments).\n",
+    "\n",
+    "Anyway, when you can you should really strive to use the `:` syntax to define data attributes.\n"
+   ]
+  },
+  {
+   "cell_type": "markdown",
+   "metadata": {},
+   "source": [
+    "### **[WARNING]** In the `:` syntax to initialize data attributes, define them in the same order as in the class declaration"
+   ]
+  },
+  {
+   "cell_type": "markdown",
+   "metadata": {},
+   "source": [
+    "For instance, don't do that:"
+   ]
+  },
+  {
+   "cell_type": "code",
+   "execution_count": null,
+   "metadata": {},
+   "outputs": [],
+   "source": [
+    "struct PoorlyDefinedVector\n",
+    "{\n",
+    "    double x_;\n",
+    "    double y_;\n",
+    "\n",
+    "    PoorlyDefinedVector(double x, double y);\n",
+    "};"
+   ]
+  },
+  {
+   "cell_type": "code",
+   "execution_count": null,
+   "metadata": {},
+   "outputs": [],
+   "source": [
+    "PoorlyDefinedVector::PoorlyDefinedVector(double x, double y)\n",
+    ": y_(y), // y_ is defined first, whereas x_ comes first in data attribute list!\n",
+    "x_(x)\n",
+    "{ }\n"
+   ]
+  },
+  {
+   "cell_type": "markdown",
+   "metadata": {},
+   "source": [
+    "You may have unwanted effects if you do not respect the same ordering.\n",
+    "\n",
+    "Fortunately, compilers are able to emit warnings to advise you to remedy this if you have properly activated them with options such as `-Wall` (we shall discuss this in a [later notebook](../6-InRealEnvironment/3-Compilers.ipynb)). You may check the very example [in Coliru](https://coliru.stacked-crooked.com/a/f783f09ff4395aa1); both clang++ and g++ provide an adequate warning."
+   ]
+  },
+  {
+   "cell_type": "markdown",
+   "metadata": {},
+   "source": [
     "## Delegating constructor\n",
     "\n",
     "Since C++ 11, it is possible to use a base constructor when defining another constructor:"
@@ -874,9 +949,7 @@
    "cell_type": "markdown",
    "metadata": {},
    "source": [
-    "[© Copyright](../COPYRIGHT.md)   \n",
-    "",
-    ""
+    "[© Copyright](../COPYRIGHT.md)   \n"
    ]
   }
  ],
-- 
GitLab


From e7b5c6cbd29ebe5121b92d0dafad02cb32b08358 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?S=C3=A9bastien=20Gilles?= <sebastien.gilles@inria.fr>
Date: Thu, 8 Feb 2024 21:41:26 +0100
Subject: [PATCH 05/30] #108 Fix a dead link. Many thanks to Mathias Malandain
 for finding it out and providing a link to the web archives!

---
 4-Templates/1-Intro.ipynb | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/4-Templates/1-Intro.ipynb b/4-Templates/1-Intro.ipynb
index beaadf8..0b0cb57 100644
--- a/4-Templates/1-Intro.ipynb
+++ b/4-Templates/1-Intro.ipynb
@@ -541,7 +541,7 @@
    "cell_type": "markdown",
    "metadata": {},
    "source": [
-    "This way of declaring friendship works but is not entirely fullproof: `Print<int>` is hence a friend of `HoldAValue4<double>`, which was not what was sought. Most of the time it's ok but there are 2 other ways to declare friendship; have a look at [this link](https://web.mst.edu/~nmjxv3/articles/templates.html) if you want to learn more about it."
+    "This way of declaring friendship works but is not entirely fullproof: `Print<int>` is hence a friend of `HoldAValue4<double>`, which was not what was sought. Most of the time it's ok but there are 2 other ways to declare friendship; have a look at [this link](https://web.archive.org/web/20211003194958/https://web.mst.edu/~nmjxv3/articles/templates.html) if you want to learn more about it."
    ]
   },
   {
@@ -672,9 +672,7 @@
    "metadata": {},
    "source": [
     "\n",
-    "[© Copyright](../COPYRIGHT.md)   \n",
-    "",
-    ""
+    "[© Copyright](../COPYRIGHT.md)   \n"
    ]
   }
  ],
-- 
GitLab


From 5302faddd2890fafa3ad7b0cecc38f082c991e78 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?S=C3=A9bastien=20Gilles?= <sebastien.gilles@inria.fr>
Date: Fri, 9 Feb 2024 08:07:17 +0100
Subject: [PATCH 06/30] #61 Lift a possible ambiguity between class name
 `Array` and its data `attribute array_` by renaming the latter.

---
 2-ObjectProgramming/3-constructors-destructor.ipynb | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/2-ObjectProgramming/3-constructors-destructor.ipynb b/2-ObjectProgramming/3-constructors-destructor.ipynb
index 99e6bd6..552a9a3 100644
--- a/2-ObjectProgramming/3-constructors-destructor.ipynb
+++ b/2-ObjectProgramming/3-constructors-destructor.ipynb
@@ -842,7 +842,7 @@
     "    \n",
     "    ~Array(); // Destructor!    \n",
     "    \n",
-    "    double* array_ = nullptr;\n",
+    "    double* underlying_array_ = nullptr;\n",
     "    const int unique_id_;\n",
     "};"
    ]
@@ -856,7 +856,7 @@
     "Array::Array(int unique_id, std::size_t array_size)\n",
     ": unique_id_(unique_id)\n",
     "{\n",
-    "    array_ = new double[array_size];\n",
+    "    underlying_array_ = new double[array_size];\n",
     "}"
    ]
   },
@@ -871,7 +871,7 @@
     "Array::~Array()\n",
     "{\n",
     "    std::cout << \"Memory for array \" << unique_id_ << \" is properly freed here.\" << std::endl;\n",
-    "    delete[] array_;\n",
+    "    delete[] underlying_array_;\n",
     "}"
    ]
   },
-- 
GitLab


From 1652c2e75256e979772b41465d0f022d524fa0c3 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?S=C3=A9bastien=20Gilles?= <sebastien.gilles@inria.fr>
Date: Fri, 9 Feb 2024 08:45:46 +0100
Subject: [PATCH 07/30] #63 Add an example of write access through friendship.

---
 2-ObjectProgramming/4-encapsulation.ipynb | 31 ++++++++++++++++++++---
 1 file changed, 28 insertions(+), 3 deletions(-)

diff --git a/2-ObjectProgramming/4-encapsulation.ipynb b/2-ObjectProgramming/4-encapsulation.ipynb
index 3c78c14..2546f03 100644
--- a/2-ObjectProgramming/4-encapsulation.ipynb
+++ b/2-ObjectProgramming/4-encapsulation.ipynb
@@ -728,6 +728,8 @@
     "        friend double Norm(const Vector&);\n",
     "    \n",
     "        friend class PrintVector; // In C++11 `class` became optional here.\n",
+    "\n",
+    "        friend void Reset(Vector&); // inane design here, just to illustrate friendship grants write access as well - a method would be much more appropriate here!\n",
     "    \n",
     "    private:\n",
     "    \n",
@@ -822,6 +824,31 @@
     "printer.Print();\n"
    ]
   },
+  {
+   "cell_type": "code",
+   "execution_count": null,
+   "metadata": {},
+   "outputs": [],
+   "source": [
+    "void Reset(Vector& vector)\n",
+    "{\n",
+    "    vector.x_ = 0.;\n",
+    "    vector.y_ = 0.;\n",
+    "    vector.z_ = 0.;\n",
+    "}"
+   ]
+  },
+  {
+   "cell_type": "code",
+   "execution_count": null,
+   "metadata": {},
+   "outputs": [],
+   "source": [
+    "printer.Print();\n",
+    "Reset(v);\n",
+    "printer.Print();"
+   ]
+  },
   {
    "cell_type": "markdown",
    "metadata": {},
@@ -846,9 +873,7 @@
    "cell_type": "markdown",
    "metadata": {},
    "source": [
-    "[© Copyright](../COPYRIGHT.md)   \n",
-    "",
-    ""
+    "[© Copyright](../COPYRIGHT.md)   \n"
    ]
   }
  ],
-- 
GitLab


From fabed5e1f068ddb57e5b6cb5d51e200f3aadec56 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?S=C3=A9bastien=20Gilles?= <sebastien.gilles@inria.fr>
Date: Fri, 9 Feb 2024 11:03:52 +0100
Subject: [PATCH 08/30] #72 Put more emphasis on the fact it is an overload and
 not a template partial specialization that takes place in the example.

---
 4-Templates/2-Specialization.ipynb | 13 +++++++------
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/4-Templates/2-Specialization.ipynb b/4-Templates/2-Specialization.ipynb
index f3b7172..7b78e50 100644
--- a/4-Templates/2-Specialization.ipynb
+++ b/4-Templates/2-Specialization.ipynb
@@ -425,7 +425,7 @@
    "source": [
     "You might have the impress it works if you try defining the function without specifying the brackets\n",
     "\n",
-    "_(please use [@Coliru](https://coliru.stacked-crooked.com/a/b1504e7033fd9346) - the code below no longer works in Xeus-cling as of September 2022)_"
+    "_(please use [@Coliru](https://coliru.stacked-crooked.com/a/ad6d2ceca1d05b0f) - the code below no longer works in Xeus-cling as of September 2022)_"
    ]
   },
   {
@@ -444,6 +444,8 @@
     "{\n",
     "    std::cout << \"Generic instantiation\" << std::endl;\n",
     "    std::cout << \"(t^2, u^2) = (\" << t * t << \", \" << u * u << \")\" << std::endl;\n",
+    "    // As '*' is not defined for std::string, one would expect a failure if invoked with\n",
+    "    // `std::string` for T or U \n",
     "}\n",
     "\n",
     "\n",
@@ -460,10 +462,11 @@
     "    std::string hello(\"Hello\");\n",
     "    PrintSquare(5., hello);\n",
     "    \n",
-    "    // But if you uncomment this line, the compilation will fail...\n",
+    "    // But if you uncomment this line which explicitly calls the template function\n",
+    "    // with both types explicitly given the compilation will fail...\n",
     "    // PrintSquare<double, std::string>(5., std::string(\"Hello\"));\n",
     "    \n",
-    "    // ... whereas it is a perfectly legit rule of instantiation, as you may check with:\n",
+    "    // ... whereas it is a perfectly legit way of calling a template instantiation, as you may check with:\n",
     "    // PrintSquare<double, int>(5., 3);\n",
     "    \n",
     "    \n",
@@ -646,9 +649,7 @@
    "metadata": {},
    "source": [
     "\n",
-    "[© Copyright](../COPYRIGHT.md)   \n",
-    "",
-    ""
+    "[© Copyright](../COPYRIGHT.md)   \n"
    ]
   }
  ],
-- 
GitLab


From ecdf883ce611a1752698c3e85b4b2126261d1fcf Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?S=C3=A9bastien=20Gilles?= <sebastien.gilles@inria.fr>
Date: Fri, 9 Feb 2024 11:16:15 +0100
Subject: [PATCH 09/30] #73 Explain explicitly why a `for` loop doesn't work
 for tuples, and add reminder of the trick to work around the impossibility to
 specialize template functions.

---
 4-Templates/4-Metaprogramming.ipynb | 29 ++++++++++++++++++++++++-----
 1 file changed, 24 insertions(+), 5 deletions(-)

diff --git a/4-Templates/4-Metaprogramming.ipynb b/4-Templates/4-Metaprogramming.ipynb
index 07c649c..d0c4a3b 100644
--- a/4-Templates/4-Metaprogramming.ipynb
+++ b/4-Templates/4-Metaprogramming.ipynb
@@ -53,7 +53,21 @@
    "cell_type": "markdown",
    "metadata": {},
    "source": [
-    "What if we want to apply the same treatment of all of the entries? Let's roll with just printing each of them:"
+    "What if we want to apply the same treatment of all of the entries? "
+   ]
+  },
+  {
+   "cell_type": "markdown",
+   "metadata": {},
+   "source": [
+    "In more usual containers, we would just write a `for` loop, but this is not an option here: to access the `I`-th element of the tuple syntax is `std::get<I>`, so `I` has to be known as compiled time... which is not the case for the mutable variable used in a typical `for` loop!"
+   ]
+  },
+  {
+   "cell_type": "markdown",
+   "metadata": {},
+   "source": [
+    "Let's roll with just printing each of them:"
    ]
   },
   {
@@ -99,11 +113,18 @@
     "    {\n",
     "        std::cout << std::get<IndexT>(tuple) << std::endl;\n",
     "        PrintTuple<IndexT + 1ul, TupleSizeT>::Do(tuple); // that's the catch: call recursively the next one!\n",
-    "    }    \n",
+    "    }  \n",
     "    \n",
     "};"
    ]
   },
+  {
+   "cell_type": "markdown",
+   "metadata": {},
+   "source": [
+    "A side reminder here: we need to use a combo of template specialization of `struct` and static method here to work around the fact template specialization of functions is not possible (see [here](2-Specialization.ipynb#Mimicking-the-partial-template-specialization-for-functions) for more details)"
+   ]
+  },
   {
    "cell_type": "markdown",
    "metadata": {},
@@ -359,9 +380,7 @@
    "cell_type": "markdown",
    "metadata": {},
    "source": [
-    "[© Copyright](../COPYRIGHT.md)\n",
-    "",
-    ""
+    "[© Copyright](../COPYRIGHT.md)\n"
    ]
   }
  ],
-- 
GitLab


From 090c3fc414f39e8b2ae12e40dceb44bfc0937165 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?S=C3=A9bastien=20Gilles?= <sebastien.gilles@inria.fr>
Date: Fri, 9 Feb 2024 12:18:17 +0100
Subject: [PATCH 10/30] #91 Metaprogramming notebook:

* Add a refinement to the example that uses up `if constexpr`.
* Add an example of `std::apply`
---
 4-Templates/4-Metaprogramming.ipynb | 124 ++++++++++++++++++++++++++++
 1 file changed, 124 insertions(+)

diff --git a/4-Templates/4-Metaprogramming.ipynb b/4-Templates/4-Metaprogramming.ipynb
index d0c4a3b..05299b5 100644
--- a/4-Templates/4-Metaprogramming.ipynb
+++ b/4-Templates/4-Metaprogramming.ipynb
@@ -230,6 +230,130 @@
     "}"
    ]
   },
+  {
+   "cell_type": "markdown",
+   "metadata": {},
+   "source": [
+    "## Slight improvement with C++ 17 `if constexpr`\n",
+    "\n",
+    "With C++ 17 compile-time check `if constexpr`, you may even do the same with much less boilerplate:"
+   ]
+  },
+  {
+   "cell_type": "code",
+   "execution_count": null,
+   "metadata": {},
+   "outputs": [],
+   "source": [
+    "#include <iostream>\n",
+    "\n",
+    "template <std::size_t IndexT, class TupleT>\n",
+    "void PrintTupleIfConstexpr(const TupleT& tuple)\n",
+    "{\n",
+    "    constexpr auto size = std::tuple_size<TupleT>();\n",
+    "\n",
+    "    static_assert(IndexT <= size);\n",
+    "    \n",
+    "    if constexpr (IndexT < size)\n",
+    "    {\n",
+    "        std::cout << std::get<IndexT>(tuple) << std::endl;\n",
+    "        PrintTupleIfConstexpr<IndexT + 1, TupleT>(tuple);\n",
+    "    }\n",
+    "};"
+   ]
+  },
+  {
+   "cell_type": "code",
+   "execution_count": null,
+   "metadata": {},
+   "outputs": [],
+   "source": [
+    "template<class TupleT>\n",
+    "void PrintTupleIfConstexprWrapper(const TupleT& tuple)\n",
+    "{\n",
+    "    PrintTupleIfConstexpr<0ul>(tuple);\n",
+    "}"
+   ]
+  },
+  {
+   "cell_type": "code",
+   "execution_count": null,
+   "metadata": {},
+   "outputs": [],
+   "source": [
+    "{\n",
+    "    std::tuple<int, std::string, double, float, long> tuple = std::make_tuple(5, \"hello\", 5., 3.2f, -35l);\n",
+    "    PrintTupleIfConstexprWrapper(tuple);\n",
+    "}"
+   ]
+  },
+  {
+   "cell_type": "code",
+   "execution_count": null,
+   "metadata": {},
+   "outputs": [],
+   "source": [
+    "{\n",
+    "    int a = 5;\n",
+    "    std::tuple<std::string, int*> tuple = std::make_tuple(\"Hello\", &a);\n",
+    "    PrintTupleIfConstexprWrapper(tuple);\n",
+    "}"
+   ]
+  },
+  {
+   "cell_type": "markdown",
+   "metadata": {},
+   "source": [
+    "The geist of it remains the same (it amounts to a recursive call) but the compile-time check makes us avoid entirely the use of the stopping specialization and the use of a struct with `static` method."
+   ]
+  },
+  {
+   "cell_type": "markdown",
+   "metadata": {},
+   "source": [
+    "## `std::apply`\n",
+    "\n",
+    "Another option provided by C++ 17 is to use `std::apply`, which purpose is to apply upon all elements of a same tuple a same operation.\n",
+    "\n",
+    "[Cppreference](https://en.cppreference.com/w/cpp/utility/apply) provides a snippet that solves the exact problem we tackled above in a slightly different way: they wrote a generic overload of `operator<<` for any instance of a `std::tuple` object.\n",
+    "\n",
+    "I have simplified somehow their snippet as they complicated a bit the reading with unrelated niceties to handle the comma separators.\n",
+    "\n",
+    "Don't bother if you do not understand all of it:\n",
+    "\n",
+    "- The weird `...` syntax is for variadic templates, that we will present [briefly in next notebook](../5-MoreAdvanced.ipynb#Variadic-templates). Sorry we avoid as much as possible to refer to future stuff in the training session, but current paragraph is a late addition and doesn't mesh completely well with the structure of this document. You just have to know it's a way to handle a variable number of arguments (here template arguments of `std::tuple`).\n"
+   ]
+  },
+  {
+   "cell_type": "code",
+   "execution_count": null,
+   "metadata": {},
+   "outputs": [],
+   "source": [
+    "template<typename... Ts>\n",
+    "std::ostream& operator<<(std::ostream& os, std::tuple<Ts...> const& theTuple)\n",
+    "{\n",
+    "    std::apply\n",
+    "    (\n",
+    "        [&os](Ts const&... tupleArgs)\n",
+    "        {\n",
+    "            std::size_t n{0};\n",
+    "            ((os << tupleArgs << std::endl), ...);            \n",
+    "        }, theTuple\n",
+    "    );\n",
+    "    return os;\n",
+    "}"
+   ]
+  },
+  {
+   "cell_type": "code",
+   "execution_count": null,
+   "metadata": {},
+   "outputs": [],
+   "source": [
+    "std::cout << tuple << std::endl;"
+   ]
+  },
   {
    "cell_type": "markdown",
    "metadata": {},
-- 
GitLab


From 31e26805d76f25e199309bb0c826e85faec6733a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?S=C3=A9bastien=20Gilles?= <sebastien.gilles@inria.fr>
Date: Fri, 9 Feb 2024 13:22:59 +0100
Subject: [PATCH 11/30] #74 Missing parenthesis.

---
 5-UsefulConceptsAndSTL/1-ErrorHandling.ipynb | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/5-UsefulConceptsAndSTL/1-ErrorHandling.ipynb b/5-UsefulConceptsAndSTL/1-ErrorHandling.ipynb
index 8e02a38..a185eab 100644
--- a/5-UsefulConceptsAndSTL/1-ErrorHandling.ipynb
+++ b/5-UsefulConceptsAndSTL/1-ErrorHandling.ipynb
@@ -27,7 +27,7 @@
     "\n",
     "## Compiler warnings and errors\n",
     "\n",
-    "The first way to find out possible errors are during compilation time: you may ensure your code is correct by making its compilation fails if not (that's exactly the spirit of the example we provided for [template template parameter](../4-Templates/5-MoreAdvanced.ipynb#Template-template-parameters-(not-a-mistake...)). There are many ways to do so, even more so if templates are involved; here are few of them we have already seen:\n",
+    "The first way to find out possible errors are during compilation time: you may ensure your code is correct by making its compilation fails if not (that's exactly the spirit of the example we provided for [template template parameter](../4-Templates/5-MoreAdvanced.ipynb#Template-template-parameters-(not-a-mistake...))). There are many ways to do so, even more so if templates are involved; here are few of them we have already seen:\n",
     "\n",
     "* `static_assert` we saw in [template introduction](../4-Templates/1-Intro.ipynb#static_assert)\n",
     "* Duck typing failure: if a template argument used somewhere doesn't comply with the expected API.\n",
@@ -587,9 +587,7 @@
    "metadata": {},
    "source": [
     "\n",
-    "[© Copyright](../COPYRIGHT.md)   \n",
-    "",
-    ""
+    "[© Copyright](../COPYRIGHT.md)   \n"
    ]
   }
  ],
-- 
GitLab


From 30e71490853d7d5d9486a2cd12d9548c71f03f26 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?S=C3=A9bastien=20Gilles?= <sebastien.gilles@inria.fr>
Date: Fri, 9 Feb 2024 13:26:14 +0100
Subject: [PATCH 12/30] #75 Add Coliru link.

---
 5-UsefulConceptsAndSTL/1-ErrorHandling.ipynb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/5-UsefulConceptsAndSTL/1-ErrorHandling.ipynb b/5-UsefulConceptsAndSTL/1-ErrorHandling.ipynb
index a185eab..4142904 100644
--- a/5-UsefulConceptsAndSTL/1-ErrorHandling.ipynb
+++ b/5-UsefulConceptsAndSTL/1-ErrorHandling.ipynb
@@ -65,7 +65,7 @@
    "cell_type": "markdown",
    "metadata": {},
    "source": [
-    "(here in Xeus-cling it breaks the kernel...)\n",
+    "(here in Xeus-cling it breaks the kernel; you may check on [Coliru](https://coliru.stacked-crooked.com/a/5fb74d5ae0118cb2))\n",
     "\n",
     "The perk of `assert` is that it checks the condition is `true` *only in debug mode*! \n",
     "\n",
-- 
GitLab


From a3549af15780c7e0554ab246b256c39da36f8586 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?S=C3=A9bastien=20Gilles?= <sebastien.gilles@inria.fr>
Date: Fri, 9 Feb 2024 13:44:07 +0100
Subject: [PATCH 13/30] #78 Add the contiguity in memory for `std::array` which
 was a glaring overlook, especially with the line related to `std::string`
 that told it was the sole container besides `std::vector` to guarantee it.

---
 5-UsefulConceptsAndSTL/3-Containers.ipynb | 8 +++-----
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/5-UsefulConceptsAndSTL/3-Containers.ipynb b/5-UsefulConceptsAndSTL/3-Containers.ipynb
index 7f68bcc..582847d 100644
--- a/5-UsefulConceptsAndSTL/3-Containers.ipynb
+++ b/5-UsefulConceptsAndSTL/3-Containers.ipynb
@@ -724,8 +724,8 @@
     "* `std::list`: A double-linked list: the idea is that each element knows the addresses of the element before and the element after. It might be considered if you need to add often elements at specific locations in the list: adding a new element is just changing 2 pointers and setting 2 new ones. You can't access directly an element by its index with a `std::list`.\n",
     "* `std::slist`: A single-linked list: similar as a `std::list` except only the pointer to the next element is kept.\n",
     "* `std::deque`: For \"double ended queue\"; this container may be helpful if you need to store a really huge amount of data that might not fit within a `std::vector`. It might also be of use if you are to add often elements in front on the list: there is `push_front()` method as well as a `push_back` one. Item 18 of \\cite{Meyers2001} recommends using `std::deque` with `bool`: `std::vector<bool>` was an experiment to provide a specific implementation to spare memory when storing booleans that went wrong and should therefore be avoided...\n",
-    "* `std::array`: You should use this one if the number of elements is known at compile time and doesn't change at all.\n",
-    "* `std::string`: Yes, it is actually a container! I will not tell much more about it; just add that it is the sole container besides `std::vector` that ensures continuous storage."
+    "* `std::array`: You should use this one if the number of elements is known at compile time and doesn't change at all, as compiler may provide even more optimizations than for `std::vector` (and your end user can't by mistake modify its size).\n",
+    "* `std::string`: Yes, it is actually a container! I will not tell much more about it; just add that it is the sole container besides `std::vector` and `std::array` that ensures continuous storage."
    ]
   },
   {
@@ -743,9 +743,7 @@
    "metadata": {},
    "source": [
     "\n",
-    "[© Copyright](../COPYRIGHT.md)   \n",
-    "",
-    ""
+    "[© Copyright](../COPYRIGHT.md)   \n"
    ]
   }
  ],
-- 
GitLab


From ada6f217d1ae2f037205eb921ef610190d521ca4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?S=C3=A9bastien=20Gilles?= <sebastien.gilles@inria.fr>
Date: Fri, 9 Feb 2024 14:07:29 +0100
Subject: [PATCH 14/30] #82 Add mention of the parallelism policy for STL
 algorithms.

---
 5-UsefulConceptsAndSTL/7-Algorithms.ipynb | 23 +++++++++++++++++++++++
 1 file changed, 23 insertions(+)

diff --git a/5-UsefulConceptsAndSTL/7-Algorithms.ipynb b/5-UsefulConceptsAndSTL/7-Algorithms.ipynb
index 37c73cc..f6f332c 100644
--- a/5-UsefulConceptsAndSTL/7-Algorithms.ipynb
+++ b/5-UsefulConceptsAndSTL/7-Algorithms.ipynb
@@ -527,6 +527,29 @@
     "}"
    ]
   },
+  {
+   "cell_type": "markdown",
+   "metadata": {},
+   "source": [
+    "## Parallel execution of algorithm\n",
+    "\n",
+    "C++ 17 introduced an optional first argument for many STL algorithms to enable to use them in parallel and/or vectorized content; see [here](https://en.cppreference.com/w/cpp/algorithm/execution_policy_tag) and [there](https://en.cppreference.com/w/cpp/algorithm/execution_policy_tag_t) on Cppreference for more details.\n",
+    "\n",
+    "As indicated there there are currently four policies available: \n",
+    "\n",
+    "- `std::execution::sequenced_policy`\n",
+    "- `std::execution::parallel_policy`\n",
+    "- `std::execution::parallel_unsequenced_policy`\n",
+    "- `std::execution::unsequenced_policy`\n",
+    "\n",
+    "with others under study (`std::parallel::cuda` and `std::parallel::opencl` are mentioned.\n",
+    "\n",
+    "I have no direct experience with it as it is not wildly supported yet by compilers (my very recent Apple Clang 15.0.0 from February 2024 doesn't support it yet) and relies upon other libraries under the hood such as tbb.\n",
+    "\n",
+    "However, it is a compelling argument to use algorithms instead of hand-made loops and functions: it should provide an easy way to optimize your code (even if as noted [on Cppreference](https://en.cppreference.com/w/cpp/algorithm/execution_policy_tag_t) you need to take usual precautions against data races).\n",
+    "\n"
+   ]
+  },
   {
    "cell_type": "markdown",
    "metadata": {},
-- 
GitLab


From 6650c157c353f1d7a601a7d7bc5dbeffe9e8633c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?S=C3=A9bastien=20Gilles?= <sebastien.gilles@inria.fr>
Date: Fri, 9 Feb 2024 15:27:43 +0100
Subject: [PATCH 15/30] #84 Add link to page with support of new features by
 compilers.

---
 6-InRealEnvironment/3-Compilers.ipynb | 16 +++++++++++++---
 1 file changed, 13 insertions(+), 3 deletions(-)

diff --git a/6-InRealEnvironment/3-Compilers.ipynb b/6-InRealEnvironment/3-Compilers.ipynb
index cd9177d..5517709 100644
--- a/6-InRealEnvironment/3-Compilers.ipynb
+++ b/6-InRealEnvironment/3-Compilers.ipynb
@@ -160,6 +160,18 @@
     "As a side note: macOS provides for few years now a customized clang with its developer environment. This one is not the standard clang and is usually slightly older than the bleeding-edge clang you may find on LLVM site. The drawback is that they stopped indicating the base version upon which their version is built; so it's not that easy to find on the Web whether a feature is supported or not."
    ]
   },
+  {
+   "cell_type": "markdown",
+   "metadata": {},
+   "source": [
+    "## State of compiler support\n",
+    "\n",
+    "There is currently a new C++ standard every three years, but there is a very noticeable lag for all features to be supported by both the compilers and their associated standard library (some C++ 20 features such as `std::format` library still aren't supported in February 2024).\n",
+    "\n",
+    "You may check [here](https://en.cppreference.com/w/cpp/compiler_support) what is the state of support for any given features; each compiler also gets its own page but this one has the merit of providing information for many compilers at once.\n",
+    "\n"
+   ]
+  },
   {
    "cell_type": "markdown",
    "metadata": {},
@@ -174,9 +186,7 @@
    "metadata": {},
    "source": [
     "\n",
-    "[© Copyright](../COPYRIGHT.md)   \n",
-    "",
-    ""
+    "[© Copyright](../COPYRIGHT.md)   \n"
    ]
   }
  ],
-- 
GitLab


From c674ae1304c1b1348970e7d7a214eff4df0f757b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?S=C3=A9bastien=20Gilles?= <sebastien.gilles@inria.fr>
Date: Fri, 9 Feb 2024 15:29:18 +0100
Subject: [PATCH 16/30] #86 Replace concurrent by competitor.

---
 6-InRealEnvironment/6-Tools.ipynb | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/6-InRealEnvironment/6-Tools.ipynb b/6-InRealEnvironment/6-Tools.ipynb
index 952f723..c64957b 100644
--- a/6-InRealEnvironment/6-Tools.ipynb
+++ b/6-InRealEnvironment/6-Tools.ipynb
@@ -51,7 +51,7 @@
     "\n",
     "## Address sanitizer\n",
     "\n",
-    "A [recent \"concurrent\"](https://github.com/google/sanitizers/wiki/AddressSanitizer) (once again use both if possible!) to Valgrind, which has the advantage of running with a much better runtime (Valgrind slows down your program tremendously). Might be integrated in some IDEs (it is in XCode on macOS).\n",
+    "A [recent competitor](https://github.com/google/sanitizers/wiki/AddressSanitizer) (once again use both if possible!) to Valgrind, which has the advantage of running with a much better runtime (Valgrind slows down your program tremendously). Might be integrated in some IDEs (it is in XCode on macOS).\n",
     "\n",
     "\n",
     "## Sonarqube\n",
@@ -131,9 +131,7 @@
    "metadata": {},
    "source": [
     "\n",
-    "[© Copyright](../COPYRIGHT.md)   \n",
-    "",
-    ""
+    "[© Copyright](../COPYRIGHT.md)   \n"
    ]
   }
  ],
-- 
GitLab


From 32121f856c1e520241343d52c32ed6be00ae0e4e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?S=C3=A9bastien=20Gilles?= <sebastien.gilles@inria.fr>
Date: Fri, 9 Feb 2024 15:30:56 +0100
Subject: [PATCH 17/30] #87 Remove redundant sentence.

---
 6-InRealEnvironment/6-Tools.ipynb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/6-InRealEnvironment/6-Tools.ipynb b/6-InRealEnvironment/6-Tools.ipynb
index c64957b..fae909f 100644
--- a/6-InRealEnvironment/6-Tools.ipynb
+++ b/6-InRealEnvironment/6-Tools.ipynb
@@ -97,7 +97,7 @@
     "\n",
     "I can mention [Uncrustify](http://uncrustify.sourceforge.net/): plenty of options to configure, even if they're not easy to figure out.\n",
     "\n",
-    "[clang-format](https://clang.llvm.org/docs/ClangFormat.html) probably provides a better trade-off power/complexity but requires LLVM clang to be installed on your system (AppleClang won't do, but you can easily install it on macOS with Homebrew). Can be easily installed through Homebrew though.\n",
+    "[clang-format](https://clang.llvm.org/docs/ClangFormat.html) probably provides a better trade-off power/complexity but requires LLVM clang to be installed on your system (AppleClang won't do, but you can easily install it on macOS with Homebrew).\n",
     "\n",
     "\n",
     "## Doxygen\n",
-- 
GitLab


From 1b091edcb3d16fd0e8e9e0e532bdfcf5886d7cbd Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?S=C3=A9bastien=20Gilles?= <sebastien.gilles@inria.fr>
Date: Fri, 9 Feb 2024 15:35:35 +0100
Subject: [PATCH 18/30] #88 Tools: add a reference to codespell.

---
 6-InRealEnvironment/6-Tools.ipynb | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/6-InRealEnvironment/6-Tools.ipynb b/6-InRealEnvironment/6-Tools.ipynb
index fae909f..80afef9 100644
--- a/6-InRealEnvironment/6-Tools.ipynb
+++ b/6-InRealEnvironment/6-Tools.ipynb
@@ -115,6 +115,13 @@
     "\n",
     "I have observed Doxygen is not very efficient on macOS for sizeable projects: time is much more important than the one observed in Alpine Docker images...\n",
     "\n",
+    "## Codespell\n",
+    "\n",
+    "[codespell](https://github.com/codespell-project/codespell) is a very neat projet to check english errors in your code. It may be used upon code directly or upon the associated README and is rather helpful to notice typos or some english errors (for instance it found out we used _informations_ a lot in these notebooks whereas it is incorrect and should be _information_).\n",
+    "\n",
+    "A strong point for this tool is that it is very easy to use; no steep learning curve for it. \n",
+    "\n",
+    "We wouldn't however advice to use the options to automatically correct your documents; there might be some false positive.\n",
     "\n",
     "## More...\n",
     "\n",
-- 
GitLab


From 32e7846e5c133b103b9be488fd71bc77850d837e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?S=C3=A9bastien=20Gilles?= <sebastien.gilles@inria.fr>
Date: Fri, 9 Feb 2024 15:37:25 +0100
Subject: [PATCH 19/30] #89 Doxygen: remove the sentences related to its
 slowness that are no longer true.

---
 6-InRealEnvironment/6-Tools.ipynb | 9 ---------
 1 file changed, 9 deletions(-)

diff --git a/6-InRealEnvironment/6-Tools.ipynb b/6-InRealEnvironment/6-Tools.ipynb
index 80afef9..0c5e366 100644
--- a/6-InRealEnvironment/6-Tools.ipynb
+++ b/6-InRealEnvironment/6-Tools.ipynb
@@ -106,15 +106,6 @@
     "\n",
     "It is rather easy to set up to easy task but may become a tad more difficult once you want to tackle more advanced features. Nonetheless it is the de-facto standard for C++ documentation and it's really something you should set up quite early if you're working on a project meant to stay for a while: it's really a hassle to spend countless hours providing after the fact such guidance in the code. As for compilers, you should strive to provide a documentation without any warning.\n",
     "\n",
-    "An important drawback of Doxygen is that its \"compilation\" of your project is much less advanced than the one provided by your compiler (even if they clearly upped their game in recent years):\n",
-    "\n",
-    "* No parallelism in some steps.\n",
-    "* A lot is done again at each Doxygen call.\n",
-    "\n",
-    "So expect for important projects the time to generate Doxygen documentation to be bigger than compilation time. \n",
-    "\n",
-    "I have observed Doxygen is not very efficient on macOS for sizeable projects: time is much more important than the one observed in Alpine Docker images...\n",
-    "\n",
     "## Codespell\n",
     "\n",
     "[codespell](https://github.com/codespell-project/codespell) is a very neat projet to check english errors in your code. It may be used upon code directly or upon the associated README and is rather helpful to notice typos or some english errors (for instance it found out we used _informations_ a lot in these notebooks whereas it is incorrect and should be _information_).\n",
-- 
GitLab


From ccebb9f8eb1f70ba3b076e792334a57f4e8bb89c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?S=C3=A9bastien=20Gilles?= <sebastien.gilles@inria.fr>
Date: Fri, 9 Feb 2024 15:48:02 +0100
Subject: [PATCH 20/30] #92 Add prints to illustrate accuracy loss.

---
 1-ProceduralProgramming/3-Types.ipynb | 12 ++++++++++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/1-ProceduralProgramming/3-Types.ipynb b/1-ProceduralProgramming/3-Types.ipynb
index 2a2e537..efc312e 100644
--- a/1-ProceduralProgramming/3-Types.ipynb
+++ b/1-ProceduralProgramming/3-Types.ipynb
@@ -400,11 +400,19 @@
    "metadata": {},
    "outputs": [],
    "source": [
+    "#include <iostream>\n",
+    "#include <iomanip>\n",
     "{\n",
-    "    float f = 1.12345678901234567890;\n",
-    "    double d = 2.12345678901234567890;\n",
+    "    float f = 1.1234567890123;\n",
+    "    double d = 2.1234567890123;\n",
     "    float f_d(d);\n",
     "    float f_dd = d;\n",
+    "\n",
+    "    std::cout << \"A double may print around 15 significant digits, d = \" << std::setprecision(16) << d << std::endl;\n",
+    "    std::cout << \"A float may print around 7 significant digits, f_d = \" << std::setprecision(16) << f_d << \" so we see here the value was altered from the initial double value.\" <<  std::endl;\n",
+    "\n",
+    "    std::cout << \"Even without conversion involved there is an accuracy loss: f = \" << std::setprecision(16) << f << std::endl;\n",
+    "    \n",
     "}"
    ]
   },
-- 
GitLab


From c79510513b4d6a0467462bbfa819d8897e4fbbbb Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?S=C3=A9bastien=20Gilles?= <sebastien.gilles@inria.fr>
Date: Fri, 9 Feb 2024 15:53:50 +0100
Subject: [PATCH 21/30] #93 Update Openclassroom link.

---
 5-UsefulConceptsAndSTL/1-ErrorHandling.ipynb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/5-UsefulConceptsAndSTL/1-ErrorHandling.ipynb b/5-UsefulConceptsAndSTL/1-ErrorHandling.ipynb
index 4142904..d1ca57f 100644
--- a/5-UsefulConceptsAndSTL/1-ErrorHandling.ipynb
+++ b/5-UsefulConceptsAndSTL/1-ErrorHandling.ipynb
@@ -396,7 +396,7 @@
     "\n",
     "The only case in which it might be very valuable to use a tailored exception is for your integration tests: if you are writing a test in which an exception is expected, it is better to check the exception you caught is exactly the one that was expected and not a completely unrelated exception which was thrown for another reason.\n",
     "\n",
-    "STL provides many derived class from `std::exception` which you might use directly or as base of your own class; see [cppreference](https://en.cppreference.com/w/cpp/error/exception) for more details. [OpenClassrooms](https://openclassrooms.com/fr/courses/1894236-programmez-avec-le-langage-c/1903837-gerez-des-erreurs-avec-les-exceptions) (which despite its name is in french) sorted out the go-to exceptions for lazy developers which cover most of the cases (don't get me wrong: laziness is often an asset for a software developer!):\n",
+    "STL provides many derived class from `std::exception` which you might use directly or as base of your own class; see [cppreference](https://en.cppreference.com/w/cpp/error/exception) for more details. [OpenClassrooms](https://openclassrooms.com/fr/courses/7137751-programmez-en-oriente-objet-avec-c/7532931-gerez-des-erreurs-avec-les-exceptions) (in french) sorted out the go-to exceptions for lazy developers which cover most of the cases (don't get me wrong: laziness is often an asset for a software developer!):\n",
     "\n",
     "* `std::domain_error`\n",
     "* `std::invalid_argument`\n",
-- 
GitLab


From e3fd39dee2e318d92b6a74c00adf8472133699a1 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?S=C3=A9bastien=20Gilles?= <sebastien.gilles@inria.fr>
Date: Fri, 9 Feb 2024 15:58:41 +0100
Subject: [PATCH 22/30] #96 PrintDivision does not show what the example
 should.

---
 1-ProceduralProgramming/4-Functions.ipynb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/1-ProceduralProgramming/4-Functions.ipynb b/1-ProceduralProgramming/4-Functions.ipynb
index 79ad50e..9d50d8a 100644
--- a/1-ProceduralProgramming/4-Functions.ipynb
+++ b/1-ProceduralProgramming/4-Functions.ipynb
@@ -107,7 +107,7 @@
     "    {\n",
     "        int division ;\n",
     "        division = numerator / denominator ;\n",
-    "        std::cout << numerator << \" / \" << numerator << \" = \" << division << std::endl ;  \n",
+    "        std::cout << numerator << \" / \" << denominator << \" = \" << division << std::endl ;  \n",
     "    }\n",
     "}"
    ]
-- 
GitLab


From 4ad1c1a25f7595521aae45ce31ac1f983712bbf1 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?S=C3=A9bastien=20Gilles?= <sebastien.gilles@inria.fr>
Date: Fri, 9 Feb 2024 16:00:20 +0100
Subject: [PATCH 23/30] #98 In Streams, manipulators section, `#include
 <iomanip>` is missing for `setprecision`.

---
 1-ProceduralProgramming/6-Streams.ipynb | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/1-ProceduralProgramming/6-Streams.ipynb b/1-ProceduralProgramming/6-Streams.ipynb
index ab1522c..0e57209 100644
--- a/1-ProceduralProgramming/6-Streams.ipynb
+++ b/1-ProceduralProgramming/6-Streams.ipynb
@@ -529,6 +529,7 @@
    "outputs": [],
    "source": [
     "#include <iostream>\n",
+    "#include <iomanip> // for std::setprecision\n",
     "\n",
     "{\n",
     "    std::cout.setf(std::ios::showpos); // Add the `+` sign explicitly\n",
@@ -549,8 +550,6 @@
    "source": [
     "\n",
     "[© Copyright](../COPYRIGHT.md)   \n",
-    "",
-    "",
     "\n"
    ]
   }
-- 
GitLab


From e88bcd4cc966b989837d05049e19133af6ecd789 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?S=C3=A9bastien=20Gilles?= <sebastien.gilles@inria.fr>
Date: Fri, 9 Feb 2024 16:04:35 +0100
Subject: [PATCH 24/30] #102 Add a sentence to underline C++ functor is not FP
 functor.

---
 3-Operators/5-Functors.ipynb | 10 +++++++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/3-Operators/5-Functors.ipynb b/3-Operators/5-Functors.ipynb
index 17e5a6a..b836084 100644
--- a/3-Operators/5-Functors.ipynb
+++ b/3-Operators/5-Functors.ipynb
@@ -23,6 +23,12 @@
    "source": [
     "## What is a functor?\n",
     "\n",
+    "### Disclaimer: not a functional programming functor!\n",
+    "\n",
+    "First of call, for those of you with a background in functional programming, what C++ calls a `functor` is [not what you are used to](https://en.wikipedia.org/wiki/Functor_(functional_programming)).\n",
+    "\n",
+    "### Functor in C++\n",
+    "\n",
     "We can provide a class with an `operator()` that allows to give its objects a function behavior. In other words: if you write an expression in which an object is used as if it were a function, it is its execution operator that is invoked. \n",
     "\n",
     "We can also see these *functional objects*, or *functors*, as functions to which we would have added state parameters from one call to another.\n",
@@ -129,9 +135,7 @@
    "metadata": {},
    "source": [
     "\n",
-    "[© Copyright](../COPYRIGHT.md)   \n",
-    "",
-    ""
+    "[© Copyright](../COPYRIGHT.md)   \n"
    ]
   }
  ],
-- 
GitLab


From 699a29605527544e9718156be322c6c86270b992 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?S=C3=A9bastien=20Gilles?= <sebastien.gilles@inria.fr>
Date: Fri, 9 Feb 2024 16:31:43 +0100
Subject: [PATCH 25/30] Update Changelog.

---
 Changelog.md | 42 ++++++++++++++++++++++++++++++++++++++++--
 1 file changed, 40 insertions(+), 2 deletions(-)

diff --git a/Changelog.md b/Changelog.md
index 6fdef4c..72e1a73 100644
--- a/Changelog.md
+++ b/Changelog.md
@@ -1,5 +1,42 @@
 We are using here tghe same convention as Ubuntu: a release is typically named vYY.MM, where YY is the last two digits of current year and MM two digits representing the month.
 
+# rc24.03
+
+There were 3 lecturers for this session:
+
+- Jérôme Diaz [^m3disim]
+- Sébastien Gilles [^sed-saclay]
+- Vincent Rouvreau [^sed-saclay]
+
+- #102 Add a sentence to underline C++ functor is not FP functor.
+- #98 In Streams, manipulators section, `#include <iomanip>` is missing for `setprecision`.
+- #96 PrintDivision does not show what the example should.
+- #93 Update Openclassroom link.
+- #92 Add prints to illustrate accuracy loss.
+- #89 Doxygen: remove the sentences related to its slowness that are no longer true.
+- #88 Tools: add a reference to codespell.
+- #87 Remove redundant sentence.
+- #86 Replace concurrent by competitor.
+- #84 Add link to page with support of new features by compilers.
+- #82 Add mention of the parallelism policy for STL algorithms.
+- #78 Add the contiguity in memory for `std::array` which was a glaring overlook, especially with the line related to `std::string` that told it was the sole container besides `std::vector` to guarantee it.
+- #75 Add Coliru link.
+- #74 Missing parenthesis.
+- #91 Metaprogramming notebook:    
+    * Add a refinement to the example that uses up `if constexpr`.
+    * Add an example of `std::apply`
+- #73 Explain explicitly why a `for` loop doesn't work for tuples, and add reminder of the trick to work around the impossibility to specialize template functions.
+- #72 Put more emphasis on the fact it is an overload and not a template partial specialization that takes place in the example.
+- #63 Add an example of write access through friendship.
+- #61 Lift a possible ambiguity between class name `Array` and its data `attribute array_` by renaming the latter.
+- #108 Fix a dead link. Many thanks to Mathias Malandain for finding it out and providing a link to the web archives!
+- #60 Detail a bit more the data attribute initialization through the `:` syntax.
+- #97 Add a paragraph to explain in C functions overload are not possible.
+- #43 Update Copyright file.
+- #29 Remove an ambiguous sentence.
+
+
+
 # [v22.10](https://gitlab.inria.fr/formations/cpp/gettingstartedwithmoderncpp/-/releases/v22.10)
 
 This version was not emitted properly right after the training session and has been created just now in February 2024.
@@ -80,6 +117,7 @@ This original version was in French and didn't use Jupyter notebooks; the bulk o
 
 
 
-[^sed-saclay]: [Center Inria Saclay-Ile-de France](https://www.inria.fr/fr/centre-inria-saclay-ile-de-france) - SED[^sed]
-[^sed-paris]: [Center Inria Paris](https://www.inria.fr/fr/centre-inria-de-paris) - SED[^sed]
+[^sed-saclay]: [Center Inria Saclay-Ile-de France](https://www.inria.fr/fr/centre-inria-saclay-ile-de-france) - [SED](https://sed.saclay.inria.fr/)[^sed]
+[^sed-paris]: [Center Inria Paris](https://www.inria.fr/fr/centre-inria-de-paris) - [SED](https://sed.paris.inria.fr/)[^sed]
+[^m3disim]: [Center Inria Saclay-Ile-de France](https://www.inria.fr/fr/centre-inria-saclay-ile-de-france) - [M3DISIM team](https://m3disim.saclay.inria.fr)
 [^sed]: SED is an acronym meaning _Experimentation and Development Department_; there is one such department per [Inria](https://www.inria.fr) center. 
\ No newline at end of file
-- 
GitLab


From 436b16d780ca55e6f77afc5ef8600f399ece2585 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?S=C3=A9bastien=20Gilles?= <sebastien.gilles@inria.fr>
Date: Thu, 15 Feb 2024 15:43:46 +0100
Subject: [PATCH 26/30] #61 Rename data attribute array_ in the RAII notebook.

---
 5-UsefulConceptsAndSTL/2-RAII.ipynb | 12 +++++-------
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/5-UsefulConceptsAndSTL/2-RAII.ipynb b/5-UsefulConceptsAndSTL/2-RAII.ipynb
index 847cb2f..e2002df 100644
--- a/5-UsefulConceptsAndSTL/2-RAII.ipynb
+++ b/5-UsefulConceptsAndSTL/2-RAII.ipynb
@@ -66,7 +66,7 @@
     "    \n",
     "        std::string name_;\n",
     "    \n",
-    "        double* array_ = nullptr;    \n",
+    "        double* underlying_array_ = nullptr;    \n",
     "};"
    ]
   },
@@ -80,9 +80,9 @@
     ": name_(name)\n",
     "{\n",
     "    std::cout << \"Acquire resources for \" << name_ << std::endl;\n",
-    "    array_ = new double[dimension];\n",
+    "    underlying_array_ = new double[dimension];\n",
     "    for (auto i = 0ul; i < dimension; ++i)\n",
-    "        array_[i] = 0.;\n",
+    "        underlying_array_[i] = 0.;\n",
     "}"
    ]
   },
@@ -95,7 +95,7 @@
     "Array::~Array()\n",
     "{\n",
     "    std::cout << \"Release resources for \" << name_ << std::endl;\n",
-    "    delete[] array_;\n",
+    "    delete[] underlying_array_;\n",
     "}"
    ]
   },
@@ -134,9 +134,7 @@
    "cell_type": "markdown",
    "metadata": {},
    "source": [
-    "[© Copyright](../COPYRIGHT.md)   \n",
-    "",
-    ""
+    "[© Copyright](../COPYRIGHT.md)   \n"
    ]
   }
  ],
-- 
GitLab


From f83f588fa3257fc338da6904faac5d457b34b086 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?S=C3=A9bastien=20Gilles?= <sebastien.gilles@inria.fr>
Date: Thu, 15 Feb 2024 15:45:28 +0100
Subject: [PATCH 27/30] Remove unrequired line.

---
 4-Templates/4-Metaprogramming.ipynb | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/4-Templates/4-Metaprogramming.ipynb b/4-Templates/4-Metaprogramming.ipynb
index 05299b5..7f6b13c 100644
--- a/4-Templates/4-Metaprogramming.ipynb
+++ b/4-Templates/4-Metaprogramming.ipynb
@@ -336,8 +336,7 @@
     "    std::apply\n",
     "    (\n",
     "        [&os](Ts const&... tupleArgs)\n",
-    "        {\n",
-    "            std::size_t n{0};\n",
+    "        {            \n",
     "            ((os << tupleArgs << std::endl), ...);            \n",
     "        }, theTuple\n",
     "    );\n",
-- 
GitLab


From 08deccc43381f9df8148f738c67ef15953c848a3 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?S=C3=A9bastien=20Gilles?= <sebastien.gilles@inria.fr>
Date: Thu, 15 Feb 2024 15:46:51 +0100
Subject: [PATCH 28/30] Typo.

---
 4-Templates/4-Metaprogramming.ipynb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/4-Templates/4-Metaprogramming.ipynb b/4-Templates/4-Metaprogramming.ipynb
index 7f6b13c..2eec213 100644
--- a/4-Templates/4-Metaprogramming.ipynb
+++ b/4-Templates/4-Metaprogramming.ipynb
@@ -60,7 +60,7 @@
    "cell_type": "markdown",
    "metadata": {},
    "source": [
-    "In more usual containers, we would just write a `for` loop, but this is not an option here: to access the `I`-th element of the tuple syntax is `std::get<I>`, so `I` has to be known as compiled time... which is not the case for the mutable variable used in a typical `for` loop!"
+    "In more usual containers, we would just write a `for` loop, but this is not an option here: to access the `I`-th element of the tuple syntax is `std::get<I>`, so `I` has to be known at compiled time... which is not the case for the mutable variable used in a typical `for` loop!"
    ]
   },
   {
-- 
GitLab


From 375b4433ec0e7f936016c9f8db2e746341f032ff Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?S=C3=A9bastien=20Gilles?= <sebastien.gilles@inria.fr>
Date: Thu, 15 Feb 2024 15:48:29 +0100
Subject: [PATCH 29/30] Fix most erroneous typo (thanks Vincent!)

---
 5-UsefulConceptsAndSTL/3-Containers.ipynb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/5-UsefulConceptsAndSTL/3-Containers.ipynb b/5-UsefulConceptsAndSTL/3-Containers.ipynb
index 582847d..0f473ac 100644
--- a/5-UsefulConceptsAndSTL/3-Containers.ipynb
+++ b/5-UsefulConceptsAndSTL/3-Containers.ipynb
@@ -725,7 +725,7 @@
     "* `std::slist`: A single-linked list: similar as a `std::list` except only the pointer to the next element is kept.\n",
     "* `std::deque`: For \"double ended queue\"; this container may be helpful if you need to store a really huge amount of data that might not fit within a `std::vector`. It might also be of use if you are to add often elements in front on the list: there is `push_front()` method as well as a `push_back` one. Item 18 of \\cite{Meyers2001} recommends using `std::deque` with `bool`: `std::vector<bool>` was an experiment to provide a specific implementation to spare memory when storing booleans that went wrong and should therefore be avoided...\n",
     "* `std::array`: You should use this one if the number of elements is known at compile time and doesn't change at all, as compiler may provide even more optimizations than for `std::vector` (and your end user can't by mistake modify its size).\n",
-    "* `std::string`: Yes, it is actually a container! I will not tell much more about it; just add that it is the sole container besides `std::vector` and `std::array` that ensures continuous storage."
+    "* `std::string`: Yes, it is actually a container! I will not tell much more about it; just add that it is the sole container besides `std::vector` and `std::array` that ensures contiguous storage."
    ]
   },
   {
-- 
GitLab


From fae06885275448ff707a338a0fb2885732a26f1d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?S=C3=A9bastien=20Gilles?= <sebastien.gilles@inria.fr>
Date: Fri, 16 Feb 2024 10:51:02 +0100
Subject: [PATCH 30/30] Remove one semi-redundant reference as suggested by
 Vincent.

---
 5-UsefulConceptsAndSTL/7-Algorithms.ipynb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/5-UsefulConceptsAndSTL/7-Algorithms.ipynb b/5-UsefulConceptsAndSTL/7-Algorithms.ipynb
index f6f332c..8c7e2f1 100644
--- a/5-UsefulConceptsAndSTL/7-Algorithms.ipynb
+++ b/5-UsefulConceptsAndSTL/7-Algorithms.ipynb
@@ -533,7 +533,7 @@
    "source": [
     "## Parallel execution of algorithm\n",
     "\n",
-    "C++ 17 introduced an optional first argument for many STL algorithms to enable to use them in parallel and/or vectorized content; see [here](https://en.cppreference.com/w/cpp/algorithm/execution_policy_tag) and [there](https://en.cppreference.com/w/cpp/algorithm/execution_policy_tag_t) on Cppreference for more details.\n",
+    "C++ 17 introduced an optional first argument for many STL algorithms to enable to use them in parallel and/or vectorized content; see [here](https://en.cppreference.com/w/cpp/algorithm/execution_policy_tag) on Cppreference for more details.\n",
     "\n",
     "As indicated there there are currently four policies available: \n",
     "\n",
-- 
GitLab