diff --git a/1-ProceduralProgramming/3-Types.ipynb b/1-ProceduralProgramming/3-Types.ipynb
index fab40c48ff3a7e650542f7b304108d13d269a859..0fda66a7ac7bd6378a8cc4c050936982caf979f9 100644
--- a/1-ProceduralProgramming/3-Types.ipynb
+++ b/1-ProceduralProgramming/3-Types.ipynb
@@ -819,9 +819,7 @@
{
"cell_type": "code",
"execution_count": null,
- "metadata": {
- "scrolled": true
- },
+ "metadata": {},
"outputs": [],
"source": [
"#include <vector>\n",
@@ -948,7 +946,7 @@
"\n",
"A way to circumvent this is `auto& k = j`.\n",
"\n",
- "`decltype(auto)` was introduced to fill this hole: contrary to `auto` it retains all these informations:"
+ "`decltype(auto)` was introduced to fill this hole: contrary to `auto` it retains all these information:"
]
},
{
@@ -977,9 +975,9 @@
"cell_type": "markdown",
"metadata": {},
"source": [
- "### `auto` and string litterals\n",
+ "### `auto` and string literals\n",
"\n",
- "**Beware:** when you declare a string litterals with `auto`, the type deduction makes it a `const char*`, not a `std::string`:"
+ "**Beware:** when you declare a string literals with `auto`, the type deduction makes it a `const char*`, not a `std::string`:"
]
},
{
@@ -1002,7 +1000,7 @@
"cell_type": "markdown",
"metadata": {},
"source": [
- "C++ 14 introduced a suffix to facilitate declaration of a `std::string` from a string litterals... but which requires to add a specific `using namespace` first (we will see that those are in a [much later notebook](../6-InRealEnvironment/5-Namespace.ipynb)). "
+ "C++ 14 introduced a suffix to facilitate declaration of a `std::string` from a string literals... but which requires to add a specific `using namespace` first (we will see that those are in a [much later notebook](../6-InRealEnvironment/5-Namespace.ipynb)). "
]
},
{
diff --git a/1-ProceduralProgramming/4-Functions.ipynb b/1-ProceduralProgramming/4-Functions.ipynb
index 19a94d783f2b88a793d602bfd674bfb4bcaca98f..10742995079c936b59ec9895824ca51cee8d4045 100644
--- a/1-ProceduralProgramming/4-Functions.ipynb
+++ b/1-ProceduralProgramming/4-Functions.ipynb
@@ -116,7 +116,7 @@
"cell_type": "markdown",
"metadata": {},
"source": [
- "and when the function is invoked at some point, the implementation above is direcly put in motion:"
+ "and when the function is invoked at some point, the implementation above is directly put in motion:"
]
},
{
@@ -328,7 +328,7 @@
"source": [
"### A bit of wandering: using C-like error codes\n",
"\n",
- "The function above gets two outputs: the quotient and the remainder of the euclidian division. Moreover, this function returns an error code: by convention this function returns 0 when everything is alright and -1 in case of a zero divider. \n",
+ "The function above gets two outputs: the quotient and the remainder of the euclidean division. Moreover, this function returns an error code: by convention this function returns 0 when everything is alright and -1 in case of a zero divider. \n",
"\n",
"Using such an error code is a very common pattern in C, that might as well be used in C++... The issue is that it requires a lot of discipline from the user of the function: there are no actual incentive to use the return value! Just calling `compute_division()` as if it was a void function is perfectly fine (and yet completely ill-advised). We will see [later](../5-UsefulConceptsAndSTL/1-ErrorHandling.ipynb) the `exception` mechanism C++ recommends instead of error codes (and discuss a bit more error codes as well).\n",
"\n",
@@ -349,7 +349,7 @@
" \n",
" ComputeDivision(arg1, arg2, quotient, remainder); // the dev 'forgot' to check the error code.\n",
" \n",
- " std::cout << \"Euclidian division of \" << arg1 << \" by \" << arg2 << \" yields a quotient of \" \n",
+ " std::cout << \"Euclidean division of \" << arg1 << \" by \" << arg2 << \" yields a quotient of \" \n",
" << quotient << \" and a remainder of \" << remainder << std::endl; \n",
"}\n",
"\n",
@@ -1095,9 +1095,7 @@
{
"cell_type": "code",
"execution_count": null,
- "metadata": {
- "scrolled": true
- },
+ "metadata": {},
"outputs": [],
"source": [
"#include <iostream>\n",
diff --git a/1-ProceduralProgramming/5-DynamicAllocation.ipynb b/1-ProceduralProgramming/5-DynamicAllocation.ipynb
index d33e97c344e90c7b944ec44f1ff088cb3d834bc3..6aaa27e877e563ef521b498f500edf67fcb13d1f 100644
--- a/1-ProceduralProgramming/5-DynamicAllocation.ipynb
+++ b/1-ProceduralProgramming/5-DynamicAllocation.ipynb
@@ -27,7 +27,7 @@
"\n",
"## Stack\n",
"\n",
- "The ordinary variables of C++ have a lifetime limited to the current instruction block, whether it is the current function, or an instruction block attached to an `if`, `for` or just independant.\n",
+ "The ordinary variables of C++ have a lifetime limited to the current instruction block, whether it is the current function, or an instruction block attached to an `if`, `for` or just independent.\n",
"\n",
"The memory allocated to them is located in an area called a **stack**, and is automatically relieved when exiting the current block using the **last in, first out** principle.\n",
"\n",
@@ -107,7 +107,7 @@
" \n",
"In sophisticated programs, this could lead in serious and tedious bookkeeping to ensure all variables are properly handled, even if tools such as [Valgrind](http://www.valgrind.org/) or [Address sanitizer](https://github.com/google/sanitizers/wiki/AddressSanitizer) may help to find out those you will probably have forgotten somewhere along the way.\n",
"\n",
- "To be honest, C++ gets quite a bad name due to this tedious memory handling; fortunately the RAII idiom provides a neat way to automatize nicely memory management (which we'll study [later](../5-UsefulConceptsAndSTL/2-RAII.ipynb)) and some vocal critics on forums that regret the lack of [garbage collection](https://en.wikipedia.org/wiki/Garbage_collection_(computer_science)) might actually not be aware of this fundamental (from my point of view at least) idiom."
+ "To be honest, C++ gets quite a bad name due to this tedious memory handling; fortunately the RAII idiom provides a neat way to automate nicely memory management (which we'll study [later](../5-UsefulConceptsAndSTL/2-RAII.ipynb)) and some vocal critics on forums that regret the lack of [garbage collection](https://en.wikipedia.org/wiki/Garbage_collection_(computer_science)) might actually not be aware of this fundamental (from my point of view at least) idiom."
]
},
{
diff --git a/2-ObjectProgramming/2-Member-functions.ipynb b/2-ObjectProgramming/2-Member-functions.ipynb
index 13ddecd55b7bb27aa097d91fad2c61307a488db4..c2c3ece33d76498e7539c224e17672476b62ce34 100644
--- a/2-ObjectProgramming/2-Member-functions.ipynb
+++ b/2-ObjectProgramming/2-Member-functions.ipynb
@@ -84,7 +84,7 @@
"- **Method** is used in other programming languages, but for some reason Julia creators used this exact term for an entirely different concept. So to put in a nutshell a C++ method is akin to a Python one but not to what Julia calls a method.\n",
"- **Attributes** are in fact the data attributes AND the methods. It is however often used only to designate the data attributes.\n",
"\n",
- "**WARNING**: In C++ you can't complete a class after the fact as you could for instance in Python. So all the methods and data atttributes have to be declared within the struct brackets here; if you need to add something you will have to recompile the class. This means especially you can't add directly a member function to a class provided by a third party library; we'll see shortly the mechanism you may use instead to do your bidding."
+ "**WARNING**: In C++ you can't complete a class after the fact as you could for instance in Python. So all the methods and data attributes have to be declared within the struct brackets here; if you need to add something you will have to recompile the class. This means especially you can't add directly a member function to a class provided by a third party library; we'll see shortly the mechanism you may use instead to do your bidding."
]
},
{
diff --git a/2-ObjectProgramming/4-encapsulation.ipynb b/2-ObjectProgramming/4-encapsulation.ipynb
index 983115c5f8bff8699e41cdf66750c27d5234f05a..1dea93280227ef81935daeddf8a37bb3f1890378 100644
--- a/2-ObjectProgramming/4-encapsulation.ipynb
+++ b/2-ObjectProgramming/4-encapsulation.ipynb
@@ -55,9 +55,7 @@
{
"cell_type": "code",
"execution_count": null,
- "metadata": {
- "scrolled": true
- },
+ "metadata": {},
"outputs": [],
"source": [
"{\n",
@@ -169,7 +167,7 @@
"cell_type": "markdown",
"metadata": {},
"source": [
- "As you may see on our example, there might be as many public and private sections as you wish, and their ordering doesn't matter (often coding standards recommend such an ordering, saying for instance to put public interface first, but the langage itself does not care in the least).\n",
+ "As you may see on our example, there might be as many public and private sections as you wish, and their ordering doesn't matter (often coding standards recommend such an ordering, saying for instance to put public interface first, but the language itself does not care in the least).\n",
"\n",
"One side note for those accustomed to other languages: C++ is really hell bent about privacy status. It is not a gentleman's agreement as in Python where the `_` prefix is an indication an attribute should not be used publicly but a user may supersede the choice anyway; in C++ you can't call directly a private method of a class\n",
"without modifying the class interface yourself - which is ill-advised, especially if we're talking about code from a third-party library.\n",
diff --git a/2-ObjectProgramming/4b-hands-on.ipynb b/2-ObjectProgramming/4b-hands-on.ipynb
index c0b411f60c6b1cb36125b3cc35b90dd54b87e021..b49270313beeab1df02c919e6fec5d3f1552c53a 100644
--- a/2-ObjectProgramming/4b-hands-on.ipynb
+++ b/2-ObjectProgramming/4b-hands-on.ipynb
@@ -39,7 +39,7 @@
"\n",
"The method will take as argument only the integer coefficient.\n",
"\n",
- "`DisplayMultiply()` will of course need also some light rewriting to accomodate that change.\n",
+ "`DisplayMultiply()` will of course need also some light rewriting to accommodate that change.\n",
"\n",
"Expected output is the same as previously.\n"
]
diff --git a/2-ObjectProgramming/5-static.ipynb b/2-ObjectProgramming/5-static.ipynb
index 5d1c41649b95935bcdea5403c019191ee322fbca..ce87014645c6e5bfd3a6c6deccc9a2e727264759 100644
--- a/2-ObjectProgramming/5-static.ipynb
+++ b/2-ObjectProgramming/5-static.ipynb
@@ -100,7 +100,7 @@
"## Static data attributes - to avoid... (see next section to understand why!)\n",
"\n",
"\n",
- "**Xeus-Cling Warning:** cling doesn't enable proper initialization of a static data atribute... Please considered the following code, available [@Coliru](https://coliru.stacked-crooked.com/a/f43bcc4548a4f160):"
+ "**Xeus-Cling Warning:** cling doesn't enable proper initialization of a static data attribute... Please considered the following code, available [@Coliru](https://coliru.stacked-crooked.com/a/f43bcc4548a4f160):"
]
},
{
diff --git a/2-ObjectProgramming/7-polymorphism.ipynb b/2-ObjectProgramming/7-polymorphism.ipynb
index 5d9e885d40c51e5106fec082814ee87071d11fa7..c06c1e0cfa11365db269303a4b6fb983d71d5973 100644
--- a/2-ObjectProgramming/7-polymorphism.ipynb
+++ b/2-ObjectProgramming/7-polymorphism.ipynb
@@ -426,7 +426,7 @@
"\n",
"Our issue here is that `PolymorphicButClumsyVehicle` has no business being instantiated directly: it is merely an **abstract class** which should never be instantiated but is there to provide a skeleton to more substantiated derived classes.\n",
"\n",
- "The mechanism to indicate that is to provide at least one **pure virtual method**: a method which prototype is given in the base class but that **must** be overriden in derived classes (at least if you want them to become concrete). The syntax to do so is to add `= 0` after the prototype."
+ "The mechanism to indicate that is to provide at least one **pure virtual method**: a method which prototype is given in the base class but that **must** be overridden in derived classes (at least if you want them to become concrete). The syntax to do so is to add `= 0` after the prototype."
]
},
{
@@ -614,7 +614,7 @@
"source": [
"void Concrete2::Method()\n",
"{\n",
- " std::cout << \"Overriden implementation.\" << std::endl;\n",
+ " std::cout << \"Overridden implementation.\" << std::endl;\n",
"}"
]
},
diff --git a/3-Operators/2-Comparison.ipynb b/3-Operators/2-Comparison.ipynb
index 5b593ac8d33fbfbda6caccca5d4f71ed139a6d43..135f055afc2b287d112bb856a37c4841cba10218 100644
--- a/3-Operators/2-Comparison.ipynb
+++ b/3-Operators/2-Comparison.ipynb
@@ -99,7 +99,7 @@
"## Operator == and !=\n",
"\n",
"* None is defined by default.\n",
- "* They are independant from each other: defining one **doesn't** define the other one...\n",
+ "* They are independent from each other: defining one **doesn't** define the other one...\n",
"* ... but **never** define `operator!=` as something other than `!(operator==)`\n",
"* As we've seen above, they are not involved at all in implicit definitions of `<=` or `>=` if only `<` or `>` is explicitly defined. Same remark as the line above though!\n",
"* Make sure you're thought well the result of your comparison:\n"
diff --git a/3-Operators/4-CanonicalForm.ipynb b/3-Operators/4-CanonicalForm.ipynb
index 8941a57ef9b1699e4e22a0e9267db930da88a03d..1fd0da34e64cec307ac50b371724a19a9b3560ef 100644
--- a/3-Operators/4-CanonicalForm.ipynb
+++ b/3-Operators/4-CanonicalForm.ipynb
@@ -457,7 +457,7 @@
"source": [
"## Canonical form of a class\n",
"\n",
- "So a typicall class of mine looks like:"
+ "So a typical class of mine looks like:"
]
},
{
diff --git a/4-Templates/3-Syntax.ipynb b/4-Templates/3-Syntax.ipynb
index 96610e517462e6410e989b86416f662e0d09c0ee..5315132c5afb2d8ff90864cab18ade3afd0d32c7 100644
--- a/4-Templates/3-Syntax.ipynb
+++ b/4-Templates/3-Syntax.ipynb
@@ -269,7 +269,7 @@
"cell_type": "markdown",
"metadata": {},
"source": [
- "The error message (with gcc) includes all the relevant information fo understand what is wrong the the `int` case:\n",
+ "The error message (with gcc) includes all the relevant information to understand what is wrong the the `int` case:\n",
"\n",
"````\n",
"main.cpp: In function 'int main(int, char**)':\n",
diff --git a/4-Templates/4-Metaprogramming.ipynb b/4-Templates/4-Metaprogramming.ipynb
index 47f588e472e6c3516226ee0b244dbba7903e8de3..77b415d75a8e771a8b4d7fe3dbcaf222ee9dccb5 100644
--- a/4-Templates/4-Metaprogramming.ipynb
+++ b/4-Templates/4-Metaprogramming.ipynb
@@ -14,7 +14,7 @@
},
"source": [
"<h1>Table of contents<span class=\"tocSkip\"></span></h1>\n",
- "<div class=\"toc\"><ul class=\"toc-item\"><li><span><a href=\"#Introduction\" data-toc-modified-id=\"Introduction-1\">Introduction</a></span></li><li><span><a href=\"#Example:-same-action-upon-a-collection-of-heterogenous-objets\" data-toc-modified-id=\"Example:-same-action-upon-a-collection-of-heterogenous-objets-2\">Example: same action upon a collection of heterogenous objets</a></span></li></ul></div>"
+ "<div class=\"toc\"><ul class=\"toc-item\"><li><span><a href=\"#Introduction\" data-toc-modified-id=\"Introduction-1\">Introduction</a></span></li><li><span><a href=\"#Example:-same-action-upon-a-collection-of-heterogeneous-objects\" data-toc-modified-id=\"Example:-same-action-upon-a-collection-of-heterogeneous-objects-2\">Example: same action upon a collection of heterogeneous objects</a></span></li></ul></div>"
]
},
{
@@ -27,10 +27,10 @@
"\n",
"You can be a very skilled C++ developer and never use this; however it opens some really interesting prospects that can't be achieved easily (or at all...) without it.\n",
"\n",
- "I recommand the reading of \\cite{Alexandrescu2001} to get the gist of it: even if it relies upon older versions of C++ (and therefore some of its hand-made constructs are now in one form or another in modern C++ or STL) it is very insightful to understand the reasoning behind metaprogrammation.\n",
+ "I recommend the reading of \\cite{Alexandrescu2001} to get the gist of it: even if it relies upon older versions of C++ (and therefore some of its hand-made constructs are now in one form or another in modern C++ or STL) it is very insightful to understand the reasoning behind metaprogrammation.\n",
"\n",
"\n",
- "## Example: same action upon a collection of heterogenous objets\n",
+ "## Example: same action upon a collection of heterogeneous objects\n",
"\n",
"Let's say we want to put together in a same container multiple objects of heterogeneous type (one concrete case for which I have used that: reading an input data file with each entry is handled differently by a dedicated object).\n",
"\n",
diff --git a/4-Templates/5-MoreAdvanced.ipynb b/4-Templates/5-MoreAdvanced.ipynb
index 8c8ff28b6ba29eafe084947dd4fc2871262b8058..2a56ec7a55c14f5aed248503473a1c85c4251c0e 100644
--- a/4-Templates/5-MoreAdvanced.ipynb
+++ b/4-Templates/5-MoreAdvanced.ipynb
@@ -222,7 +222,7 @@
"source": [
"A more complete example with an uncopyable class and the proof the alternate syntax works is available [@Coliru](https://coliru.stacked-crooked.com/a/698eb583b5a94bc7).\n",
"\n",
- "In fact sometimes you may even have **traits class**: class which sole purpose is to provide type informations! Such classes are often used as template parameters of other classes."
+ "In fact sometimes you may even have **traits class**: class which sole purpose is to provide type information! Such classes are often used as template parameters of other classes."
]
},
{
@@ -447,7 +447,7 @@
"cell_type": "markdown",
"metadata": {},
"source": [
- "You may use it on seemlessly on usual STL containers:"
+ "You may use it on seamlessly on usual STL containers:"
]
},
{
diff --git a/5-UsefulConceptsAndSTL/1b-hands-on.ipynb b/5-UsefulConceptsAndSTL/1b-hands-on.ipynb
index 248e6b16532716aae283ccfc59518530e9175ed2..969f827dad09faa72da080e44ddc354910299e3d 100644
--- a/5-UsefulConceptsAndSTL/1b-hands-on.ipynb
+++ b/5-UsefulConceptsAndSTL/1b-hands-on.ipynb
@@ -48,7 +48,7 @@
"source": [
"### EXERCICE 36: proper handling of overflow\n",
"\n",
- "We are now well equiped to deal with the overflow issue we saw earlier. \n",
+ "We are now well equipped to deal with the overflow issue we saw earlier. \n",
"\n",
"We would like to print _Overflow!_ in the lines when the chosen number of bits is not compatible with the chosen integer type. Contrary to what we did in previous exercice, we want to recover after such an exception, not to terminate immediately the program.\n",
"\n",
@@ -127,7 +127,7 @@
"\n",
"To handle this properly, you should:\n",
"\n",
- "* Add a data atribute in `PowerOfTwoApprox` which will keep the information about the sign.\n",
+ "* Add a data attribute in `PowerOfTwoApprox` which will keep the information about the sign.\n",
"* Make the computation on the absolute value of the floating point number, and properly put on the sign whenever necessary.\n",
"\n",
"*Expected result*:\n",
diff --git a/5-UsefulConceptsAndSTL/2-RAII.ipynb b/5-UsefulConceptsAndSTL/2-RAII.ipynb
index 6e3a7031c910a54aa4ba9bbf6d8c12e1d72d9ea3..da3ce80b67313e548ba33705421f6d618ba1af2c 100644
--- a/5-UsefulConceptsAndSTL/2-RAII.ipynb
+++ b/5-UsefulConceptsAndSTL/2-RAII.ipynb
@@ -31,8 +31,8 @@
"\n",
"C++ provides in fact the best of both worlds: a way to provide safe freeing of memory as soon as possible... provided you know how to adequately use it.\n",
"\n",
- "The **Ressource Acquisition Is Initialization** or **RAII** idiom is the key mechanism for this; the idea is just to use an object with:\n",
- "* The constructor in charge of allocating the ressources (memory, mutexes, etc...)\n",
+ "The **Resource Acquisition Is Initialization** or **RAII** idiom is the key mechanism for this; the idea is just to use an object with:\n",
+ "* The constructor in charge of allocating the resources (memory, mutexes, etc...)\n",
"* The destructor in charge of freeing all that as soon as the object becomes out-of-scope.\n",
"\n",
"And that's it!"
@@ -79,7 +79,7 @@
"Array::Array(std::string name, std::size_t dimension)\n",
": name_(name)\n",
"{\n",
- " std::cout << \"Acquire ressources for \" << name_ << std::endl;\n",
+ " std::cout << \"Acquire resources for \" << name_ << std::endl;\n",
" array_ = new double[dimension];\n",
" for (auto i = 0ul; i < dimension; ++i)\n",
" array_[i] = 0.;\n",
@@ -94,7 +94,7 @@
"source": [
"Array::~Array()\n",
"{\n",
- " std::cout << \"Release ressources for \" << name_ << std::endl;\n",
+ " std::cout << \"Release resources for \" << name_ << std::endl;\n",
" delete[] array_;\n",
"}"
]
@@ -127,7 +127,7 @@
"source": [
"Of course, don't use such a class: STL `std::vector` and `std::array` are already there for that (and use up RAII principle under the hood!) and provide also more complicated mechanisms such as the copy.\n",
"\n",
- "The ressource itself needs not be memory; for instance `std::ofstream` also use up RAII: its destructor calls `close()` if not done manually before, ensuring the file on disk features properly the changes you might have done on it during the run of your program."
+ "The resource itself needs not be memory; for instance `std::ofstream` also use up RAII: its destructor calls `close()` if not done manually before, ensuring the file on disk features properly the changes you might have done on it during the run of your program."
]
},
{
diff --git a/5-UsefulConceptsAndSTL/3-Containers.ipynb b/5-UsefulConceptsAndSTL/3-Containers.ipynb
index 426ca33cb41217a27ceb14da5ded59d7a051a3fc..6a689b368f2c4224fadaab92537a6f2d2fa4d272 100644
--- a/5-UsefulConceptsAndSTL/3-Containers.ipynb
+++ b/5-UsefulConceptsAndSTL/3-Containers.ipynb
@@ -168,7 +168,7 @@
"source": [
"### Size\n",
"\n",
- "A useful perk is that in true object paradigm, `std::vector` knows its size at every moment (in C with dynamic arrays you needed to keep track of the size independantly: the array was actually a pointer which indicates where the array started, but absolutely not when it ended.).\n",
+ "A useful perk is that in true object paradigm, `std::vector` knows its size at every moment (in C with dynamic arrays you needed to keep track of the size independently: the array was actually a pointer which indicates where the array started, but absolutely not when it ended.).\n",
"\n",
"The method to know it is `size()`:\n",
"\n",
diff --git a/5-UsefulConceptsAndSTL/4-AssociativeContainers.ipynb b/5-UsefulConceptsAndSTL/4-AssociativeContainers.ipynb
index 427b472c7b38ce52a32cf6fa0f16dea2b4a45cd5..f1cc300bc5ef959da6acbe856100e96501e2342c 100644
--- a/5-UsefulConceptsAndSTL/4-AssociativeContainers.ipynb
+++ b/5-UsefulConceptsAndSTL/4-AssociativeContainers.ipynb
@@ -408,7 +408,7 @@
"\n",
"This is another associative container introduced in C++ 11, with a different trade-off (and closer to a `dict` in Python for instance):\n",
"\n",
- "* Access is much more efficient (~O(1), i.e. independant on the number of elements!)\n",
+ "* Access is much more efficient (~O(1), i.e. independent on the number of elements!)\n",
"* Memory imprint is bigger.\n",
"* Adding new elements is more expensive.\n",
"* The result is not ordered, and there are no rules whatsoever: two runs on the same computer might not yield the list in the same order.\n",
diff --git a/5-UsefulConceptsAndSTL/5-MoveSemantics.ipynb b/5-UsefulConceptsAndSTL/5-MoveSemantics.ipynb
index 298c4ff7d25046acc89c7753e759dbb4223dc818..e426b5fc24de1e7bfc947b19f4ba56b91aa046f6 100644
--- a/5-UsefulConceptsAndSTL/5-MoveSemantics.ipynb
+++ b/5-UsefulConceptsAndSTL/5-MoveSemantics.ipynb
@@ -264,7 +264,7 @@
"cell_type": "markdown",
"metadata": {},
"source": [
- "Look carefully at the error message: the issue is not between `const char[6]` and `std::string` (implicit conversion from `char*` to `std::string` exists) but due to the reference; same function with pass-by-copy works seemlessly:"
+ "Look carefully at the error message: the issue is not between `const char[6]` and `std::string` (implicit conversion from `char*` to `std::string` exists) but due to the reference; same function with pass-by-copy works seamlessly:"
]
},
{
@@ -856,7 +856,7 @@
"source": [
"With all this move semantics, the operations above are comparable to what we achieved with the `Swap` function for `Text` earlier... with the additional benefit that this semantic is not only used for swapping two values.\n",
"\n",
- "As already mentioned [there](../3-Operators/4-CanonicalForm.ipynb#[Advanced]-The-true-canonical-class), there are specific rules called __Rule of 0__, __Rule of 3__ and __Rule of 5__, which explains which constructor(s), destructor and assigmnent operator you ought to define for your class.\n",
+ "As already mentioned [there](../3-Operators/4-CanonicalForm.ipynb#[Advanced]-The-true-canonical-class), there are specific rules called __Rule of 0__, __Rule of 3__ and __Rule of 5__, which explains which constructor(s), destructor and assignment operator you ought to define for your class.\n",
"\n",
"\n",
"## Temporary reference argument within a function\n",
diff --git a/5-UsefulConceptsAndSTL/6-SmartPointers.ipynb b/5-UsefulConceptsAndSTL/6-SmartPointers.ipynb
index 9ce068b6709ffcc2283a30292e95589b8414e76c..eca21f62190a4bc098ba9f91d7d00f1d9c2f82f3 100644
--- a/5-UsefulConceptsAndSTL/6-SmartPointers.ipynb
+++ b/5-UsefulConceptsAndSTL/6-SmartPointers.ipynb
@@ -47,7 +47,7 @@
"\n",
"This does not mean they supersede entirely ordinary (often called **raw** or more infrequently **dumb**) pointers: raw pointers might be a good choice to pass an object as a function parameter (see the discussion for the third question in this [Herb Sutter's post blog](https://herbsutter.com/2013/06/05/gotw-91-solution-smart-pointer-parameters/)). The raw pointer behind a smart pointer may be accessed through the `get()` method.\n",
"\n",
- "Both smart pointers exposed below may be constructed directly from a raw pointer; in this case they take the responsability of destroying the pointer:"
+ "Both smart pointers exposed below may be constructed directly from a raw pointer; in this case they take the responsibility of destroying the pointer:"
]
},
{
@@ -86,7 +86,7 @@
"\n",
"This should be your first choice for a smart pointer.\n",
"\n",
- "The idea behind this smart pointer is that it can't be copied: there is exactly one instance of the smart pointer, and when this instance becomes out of scope the ressources are properly released.\n",
+ "The idea behind this smart pointer is that it can't be copied: there is exactly one instance of the smart pointer, and when this instance becomes out of scope the resources are properly released.\n",
"\n",
"In C++ 11 you had to use the classic `new` syntax to create one, but C++ 14 introduced a specific syntax `make_unique`:"
]
@@ -262,7 +262,7 @@
"Doing so:\n",
"\n",
"* `Content` is stored by a `unique_ptr`, which will manage the destruction in due time of the object (when the `WithUniquePtr` object will be destroyed).\n",
- "* `Content` object might be manipulated through its reference; end-user don't even need to know ressource was stored through a (smart) pointer:"
+ "* `Content` object might be manipulated through its reference; end-user don't even need to know resource was stored through a (smart) pointer:"
]
},
{
@@ -374,7 +374,7 @@
"\n",
"`shared_ptr` are clearly useful, but you should always wonder first if you really need them: for most uses a `unique_ptr` eventually seconded by raw pointers extracted by `get()` is enough.\n",
"\n",
- "There is also a risk of not releasing properly the memory is there is a circular dependancy between two `shared_ptr`. A variation of this pointer named `weak_ptr` enables to circumvent this issue, but is a bit tedious to put into motion. I have written in [appendix](../7-Appendix/WeakPtr.ipynb) a notebook to describe how to do so.\n",
+ "There is also a risk of not releasing properly the memory is there is a circular dependency between two `shared_ptr`. A variation of this pointer named `weak_ptr` enables to circumvent this issue, but is a bit tedious to put into motion. I have written in [appendix](../7-Appendix/WeakPtr.ipynb) a notebook to describe how to do so.\n",
"\n"
]
},
diff --git a/6-InRealEnvironment/2-FileStructure.ipynb b/6-InRealEnvironment/2-FileStructure.ipynb
index 45dc4d5294a835e20a76007c5b4a03e095c2b257..2a72d63104c221f07fb01961dd21e4ee3f0fc1aa 100644
--- a/6-InRealEnvironment/2-FileStructure.ipynb
+++ b/6-InRealEnvironment/2-FileStructure.ipynb
@@ -245,7 +245,7 @@
"source": [
"## Header file\n",
"\n",
- "The issue above is that we need to inform the compiler when it attemps to compile `main.cpp` that `hello()` function is something that exists. We need to **declare** it in a dedicated **header file** and **include** this file in each source file that needs it:"
+ "The issue above is that we need to inform the compiler when it attempts to compile `main.cpp` that `hello()` function is something that exists. We need to **declare** it in a dedicated **header file** and **include** this file in each source file that needs it:"
]
},
{
@@ -896,7 +896,7 @@
"cell_type": "markdown",
"metadata": {},
"source": [
- "* Include that are here for implementation details should on the other hand be preferrably in source files. Of course, you may not be able to do that in any case: for instance templates are by construction defined in header files!"
+ "* Include that are here for implementation details should on the other hand be preferably in source files. Of course, you may not be able to do that in any case: for instance templates are by construction defined in header files!"
]
},
{
diff --git a/6-InRealEnvironment/3-Compilers.ipynb b/6-InRealEnvironment/3-Compilers.ipynb
index 4b5be5c25a7b5926f31cdec1932a2d85967df293..f7f828e75e575c7b6c93b05f1c68a91b18a9e5d2 100644
--- a/6-InRealEnvironment/3-Compilers.ipynb
+++ b/6-InRealEnvironment/3-Compilers.ipynb
@@ -36,7 +36,7 @@
"\n",
"[GCC](http://gcc.gnu.org/) is a free-to-use compiler which has now been around for decades; it is mostly for Unix systems but may be used with Windows with some additional set-up (I don't master this but see for instance this [StackOverflow question](https://stackoverflow.com/questions/771756/what-is-the-difference-between-cygwin-and-mingw)).\n",
"\n",
- "As many others softwares, GCC changed its version system: gcc 3 and 4 were there for decades, and now the versions change more swiftly, with gcc 12.2 the current stable version (as of September 2022; it was published on the 19th of August 2022).\n",
+ "As many others software, GCC changed its version system: gcc 3 and 4 were there for decades, and now the versions change more swiftly, with gcc 12.2 the current stable version (as of September 2022; it was published on the 19th of August 2022).\n",
"\n",
"`gcc` was long known for its terse user interface: until recently color were not provided in outputs, and error messages were a bit cryptic for the beotians. It changed though when `clang` appeared.\n",
"\n",
@@ -84,7 +84,7 @@
"\n",
"`-Wall -Wextra -Wcast-align -Wcast-qual -Wconversion -Wdisabled-optimization -Wfloat-equal -Wformat=2 -Wformat-nonliteral -Wformat-security -Wformat-y2k -Wimport -Winit-self -Winvalid-pch -Wmissing-field-initializers -Wmissing-format-attribute -Wmissing-include-dirs -Wpacked -Wpointer-arith -Wredundant-decls -Wstack-protector -Wstrict-aliasing=2 -Wswitch-enum -Wunreachable-code -Wunused -Wunused-parameter -Wvariadic-macros -Wwrite-strings`\n",
"\n",
- "Some are intentionaly deactivated, and plenty others I probably don't know - especially if they were introduced since I established this list (by adapting one provided on StackOverflow...).\n",
+ "Some are intentionally deactivated, and plenty others I probably don't know - especially if they were introduced since I established this list (by adapting one provided on StackOverflow...).\n",
"\n",
"### Standard library\n",
"\n",
diff --git a/6-InRealEnvironment/4-ThirdParty.ipynb b/6-InRealEnvironment/4-ThirdParty.ipynb
index 329e41427e8edb7bf9dc5f3518fc7e596227d0c8..93bc67657e15e200d599a4e1053e0b4ff7d8d2af 100644
--- a/6-InRealEnvironment/4-ThirdParty.ipynb
+++ b/6-InRealEnvironment/4-ThirdParty.ipynb
@@ -44,7 +44,7 @@
"\n",
"As we shall see, there are two very different mechanisms that are present to work around the issue.\n",
"\n",
- "To illustrate them we will tackle a very basic example: a program which calls Boost filesystem library to copy a file. We also purposedly add code below that should raise a warning:"
+ "To illustrate them we will tackle a very basic example: a program which calls Boost filesystem library to copy a file. We also purposely add code below that should raise a warning:"
]
},
{
diff --git a/6-InRealEnvironment/5-Namespace.ipynb b/6-InRealEnvironment/5-Namespace.ipynb
index 312ea0db2125e65eaa6d5aae20a3799f082f0a55..80e0b796e94c69888b3aa467986ea3b94f45e0b0 100644
--- a/6-InRealEnvironment/5-Namespace.ipynb
+++ b/6-InRealEnvironment/5-Namespace.ipynb
@@ -33,7 +33,7 @@
"\n",
"## Defining a namespace and using its content\n",
"\n",
- "A namespace is just defined as a block preffixed by `namespace XXX` where XXX is the name of the namespace. Contrary to a class, a same namespace block may be used in as many file as you wish; declaration and definition may therefore be defined in separate files as usual.\n",
+ "A namespace is just defined as a block prefixed by `namespace XXX` where XXX is the name of the namespace. Contrary to a class, a same namespace block may be used in as many file as you wish; declaration and definition may therefore be defined in separate files as usual.\n",
"\n",
"\n",
"\n",
@@ -302,7 +302,7 @@
"source": [
"## The `std` namespace\n",
"\n",
- "We've actually used one namespace extensively so far even if I didn't tell what it was: the `std::` preffix was just to indicate the namespace in which the STL constructs are defined.\n",
+ "We've actually used one namespace extensively so far even if I didn't tell what it was: the `std::` prefix was just to indicate the namespace in which the STL constructs are defined.\n",
"\n",
"There is a specific rule for that namespace: it is **forbidden** to try to add content in that namespace except for very specific case such as `std::hash` specialization (see [the cppreference page](https://en.cppreference.com/w/cpp/language/extending_std) for more details). Unfortunately, compilers will not tell you something is amiss; the standard says that doing so leads to undefined behaviour.\n",
"\n"
@@ -450,7 +450,7 @@
"metadata": {},
"outputs": [],
"source": [
- "cout << \"Without std:: preffix!\"; // Won't work before following cell is activated"
+ "cout << \"Without std:: prefix!\"; // Won't work before following cell is activated"
]
},
{
@@ -468,7 +468,7 @@
"metadata": {},
"outputs": [],
"source": [
- "cout << \"Without std:: preffix!\"; // Works! - or at least should work: Xeus Cling seems lost here..."
+ "cout << \"Without std:: prefix!\"; // Works! - or at least should work: Xeus Cling seems lost here..."
]
},
{
diff --git a/6-InRealEnvironment/6-Tools.ipynb b/6-InRealEnvironment/6-Tools.ipynb
index 4602377e59291e2c7a2b7775ede376bcbb83ecdf..d315ef0048d5c5bb8730106bd284782fd7822943 100644
--- a/6-InRealEnvironment/6-Tools.ipynb
+++ b/6-InRealEnvironment/6-Tools.ipynb
@@ -68,7 +68,7 @@
"### Google test\n",
"\n",
"[GoogleTest](https://google.github.io/googletest/) includes everything that is needed for testing: [xUnit](https://en.wikipedia.org/wiki/XUnit), test discovery, rich test assertions, death tests, XML test report generation, ... \n",
- "It is also the only one we know that provide mocks. It is worth saying that mocking in C++ requires your application to be specially designed for it, more informations are available on the [gMock cookbook](https://google.github.io/googletest/gmock_cook_book.html).\n",
+ "It is also the only one we know that provide mocks. It is worth saying that mocking in C++ requires your application to be specially designed for it, more information are available on the [gMock cookbook](https://google.github.io/googletest/gmock_cook_book.html).\n",
"\n",
"\n",
"### Doctest\n",
diff --git a/7-Appendix/Crtp.ipynb b/7-Appendix/Crtp.ipynb
index bb3e95469eb8fce07207fc63ac72c16e5aadff9d..b02d74bfb2e74c0780f8ef2115b2f74b23533858 100644
--- a/7-Appendix/Crtp.ipynb
+++ b/7-Appendix/Crtp.ipynb
@@ -14,7 +14,7 @@
},
"source": [
"<h1>Table of contents<span class=\"tocSkip\"></span></h1>\n",
- "<div class=\"toc\"><ul class=\"toc-item\"><li><span><a href=\"#Introduction\" data-toc-modified-id=\"Introduction-1\">Introduction</a></span></li><li><span><a href=\"#Attempt-without-CRTP\" data-toc-modified-id=\"Attempt-without-CRTP-2\">Attempt without CRTP</a></span><ul class=\"toc-item\"><li><span><a href=\"#First-attempt:-public-inheritance\" data-toc-modified-id=\"First-attempt:-public-inheritance-2.1\">First attempt: public inheritance</a></span></li><li><span><a href=\"#Second-attempt:-private-inheritance\" data-toc-modified-id=\"Second-attempt:-private-inheritance-2.2\">Second attempt: private inheritance</a></span></li><li><span><a href=\"#Third-attempt:-composition\" data-toc-modified-id=\"Third-attempt:-composition-2.3\">Third attempt: composition</a></span></li></ul></li><li><span><a href=\"#CRTP\" data-toc-modified-id=\"CRTP-3\">CRTP</a></span><ul class=\"toc-item\"><li><span><a href=\"#Refering-to-the-base-class\" data-toc-modified-id=\"Refering-to-the-base-class-3.1\">Refering to the base class</a></span></li><li><span><a href=\"#Never-call-a-CRTP-method-in-base-constructor!\" data-toc-modified-id=\"Never-call-a-CRTP-method-in-base-constructor!-3.2\">Never call a CRTP method in base constructor!</a></span></li></ul></li></ul></div>"
+ "<div class=\"toc\"><ul class=\"toc-item\"><li><span><a href=\"#Introduction\" data-toc-modified-id=\"Introduction-1\">Introduction</a></span></li><li><span><a href=\"#Attempt-without-CRTP\" data-toc-modified-id=\"Attempt-without-CRTP-2\">Attempt without CRTP</a></span><ul class=\"toc-item\"><li><span><a href=\"#First-attempt:-public-inheritance\" data-toc-modified-id=\"First-attempt:-public-inheritance-2.1\">First attempt: public inheritance</a></span></li><li><span><a href=\"#Second-attempt:-private-inheritance\" data-toc-modified-id=\"Second-attempt:-private-inheritance-2.2\">Second attempt: private inheritance</a></span></li><li><span><a href=\"#Third-attempt:-composition\" data-toc-modified-id=\"Third-attempt:-composition-2.3\">Third attempt: composition</a></span></li></ul></li><li><span><a href=\"#CRTP\" data-toc-modified-id=\"CRTP-3\">CRTP</a></span><ul class=\"toc-item\"><li><span><a href=\"#Referring-to-the-base-class\" data-toc-modified-id=\"Referring-to-the-base-class-3.1\">Referring to the base class</a></span></li><li><span><a href=\"#Never-call-a-CRTP-method-in-base-constructor!\" data-toc-modified-id=\"Never-call-a-CRTP-method-in-base-constructor!-3.2\">Never call a CRTP method in base constructor!</a></span></li></ul></li></ul></div>"
]
},
{
@@ -540,7 +540,7 @@
"cell_type": "markdown",
"metadata": {},
"source": [
- "### Refering to the base class\n",
+ "### Referring to the base class\n",
"\n",
"Sometimes however, you need to access something from the derived class in the CRTP, and I must admit in this case the syntax could have been more sweet..."
]
diff --git a/7-Appendix/HomemadeException.ipynb b/7-Appendix/HomemadeException.ipynb
index a5ddc92d352c1faff645771d3ff134c7a673f3d0..4ae0fbab21629f568b533058d8890f119b8a1270 100644
--- a/7-Appendix/HomemadeException.ipynb
+++ b/7-Appendix/HomemadeException.ipynb
@@ -181,7 +181,7 @@
" * finite element space 1: Domain 1 is not defined!\n",
" * \\endverbatim\n",
" *\n",
- " * \\return Exception error message withou information about file and line in which the exception was invoked.\n",
+ " * \\return Exception error message without information about file and line in which the exception was invoked.\n",
" */\n",
" const std::string& GetRawMessage() const noexcept;\n",
"\n",
diff --git a/7-Appendix/StringView.ipynb b/7-Appendix/StringView.ipynb
index 1e0887b9c6747b9f0ce27ab512732d45e0fed247..3135eaf59746fcf9b902252203fc8034585a8e38 100644
--- a/7-Appendix/StringView.ipynb
+++ b/7-Appendix/StringView.ipynb
@@ -121,7 +121,7 @@
"\n",
"So whenever possible, using `std::string_view` instead of `const std::string&` is advised - provided of course your project is firmly grounded in C++ 17 or later.\n",
"\n",
- "That doesn't mean there are no costs involved: when you are using `std::string_view`, you are essentially taking the responsability to ensure the memory area still exists (very similarly to the kind of contract you pass when you define a reference). [CppReference](https://en.cppreference.com/w/cpp/string/basic_string_view) illustrates this on a very basic case:\n",
+ "That doesn't mean there are no costs involved: when you are using `std::string_view`, you are essentially taking the responsibility to ensure the memory area still exists (very similarly to the kind of contract you pass when you define a reference). [CppReference](https://en.cppreference.com/w/cpp/string/basic_string_view) illustrates this on a very basic case:\n",
"\n"
]
},
diff --git a/7-Appendix/WeakPtr.ipynb b/7-Appendix/WeakPtr.ipynb
index 7056799957d9d64b957d47ff2e919b48cf5acef4..0b06e83639905e7c078cd0f4edf13a5864b578ec 100644
--- a/7-Appendix/WeakPtr.ipynb
+++ b/7-Appendix/WeakPtr.ipynb
@@ -399,7 +399,7 @@
"source": [
"Now we will tackle the remaining design issues:\n",
"\n",
- "- Making the end-user call `AddChild()` himself is very ill-advised, as you put on him the burden of making sure the objects are consistant. \n",
+ "- Making the end-user call `AddChild()` himself is very ill-advised, as you put on him the burden of making sure the objects are consistent. \n",
"- If a `Child` is removed at some point, it remains present in the `Father` dedicated data attribute `children_`; taking the size of this vector thus yields a wrong result. This second issue is not as bad as the first one: `children_` is a private data attribute that is not exposed publicly at all; it might be acceptable to keep this behaviour and provide a method that yields the number of children (and in this case documenting it properly in Doxygen or equivalent: if someone fiddles with the class implementation in the future he must be fully aware of it... and this someone could be yourself in few months!).\n",
"\n",
"What would be the neater way to solve the first issue would be to do this step during the `Child` constructor: we set the relationship both ways at the same time. What we lacked is a way to derive a `shared_ptr` from the `this` pointer; STL provides a CRTP to do exactly that: `std::enable_shared_from_this`. With this CRTP, we gain a `shared_from_this()` method that provides exactly what we need (you should have a look at [cppreference](https://en.cppreference.com/w/cpp/memory/enable_shared_from_this) for more details about why you shouldn't try to create the shared pointer from this yourself).\n",
@@ -634,7 +634,7 @@
" }\n",
" catch(const std::exception& e)\n",
" {\n",
- " std::cerr << \"An exception occured in Child3 destructor; it is neutralized and \"\n",
+ " std::cerr << \"An exception occurred in Child3 destructor; it is neutralized and \"\n",
" \"the program will abort.\" << std::endl;\n",
" abort();\n",
" }\n",
@@ -681,7 +681,7 @@
"source": [
"With this, we have a perfectly valid and safe circular loop between two classes. \n",
"\n",
- "As you can surmise, you shouldn't rely too much on such circular dependancies that are clearly a lot of work to set-up to be full-proof; it is best to think from the beginning in which way your relationship is defined and stick to it as much as possible. "
+ "As you can surmise, you shouldn't rely too much on such circular dependencies that are clearly a lot of work to set-up to be full-proof; it is best to think from the beginning in which way your relationship is defined and stick to it as much as possible. "
]
},
{
diff --git a/HandsOn/HowTo.ipynb b/HandsOn/HowTo.ipynb
index 33a058b1f1dc58b074707b2e6996cceff9dba65c..73ecef912a9386273d730be5ce51f51585c5eb49 100644
--- a/HandsOn/HowTo.ipynb
+++ b/HandsOn/HowTo.ipynb
@@ -63,7 +63,7 @@
"\n",
"`./initial`\n",
"\n",
- "and if everything is allright you should see (in the case of the [first hands-on](../1-ProceduralProgramming/2b-hands-on.ipynb#EXERCICE-1:-Adding-a-loop)):\n",
+ "and if everything is alright you should see (in the case of the [first hands-on](../1-ProceduralProgramming/2b-hands-on.ipynb#EXERCICE-1:-Adding-a-loop)):\n",
"\n",
"````\n",
"0.65 ~ 1 / 2^1\n",
@@ -95,7 +95,7 @@
"\n",
"The steps to compile are the same as presented in the previous section.\n",
"\n",
- "For more informations about the Docker way please look the dedicated [README](README.md) (the one within the _HandsOn_ folder of the root directory)."
+ "For more information about the Docker way please look the dedicated [README](README.md) (the one within the _HandsOn_ folder of the root directory)."
]
},
{
diff --git a/bibliography.ipynb b/bibliography.ipynb
index 36556d3b0d2f1b37ea6bd28e3a820a2a58271536..1dace29e1088acaa5f6395bc444d3a05267ba029 100644
--- a/bibliography.ipynb
+++ b/bibliography.ipynb
@@ -25,7 +25,7 @@
"\n",
"### Modern C++ Design \\cite{Alexandrescu2001}\n",
"\n",
- "A very brillant book to understand the reasoning behind metaprogramming, by one of the father of this branch of software development. Clearly not for the faint of heart, but a really enlightening reading; I especially recommend the chapter about policies (the first one is also very interesting but some of the stuff there is now directly available in the standard library).\n",
+ "A very brilliant book to understand the reasoning behind metaprogramming, by one of the father of this branch of software development. Clearly not for the faint of heart, but a really enlightening reading; I especially recommend the chapter about policies (the first one is also very interesting but some of the stuff there is now directly available in the standard library).\n",
"\n",
"### Exceptional C++ / More Exceptional C++ \\cite{Sutter1999, Sutter2002}\n",
"\n",
@@ -79,7 +79,7 @@
"\n",
"### [isocpp](https://isocpp.org/faq)\n",
"\n",
- "A gigantic FAQ that covers many aspects of C++; this site is in fact a merge from two previously independant FAQ, one of which was maintained by Bjarne Stroustrup, creator of the language.\n",
+ "A gigantic FAQ that covers many aspects of C++; this site is in fact a merge from two previously independent FAQ, one of which was maintained by Bjarne Stroustrup, creator of the language.\n",
"\n",
"### [FluentCpp](https://www.fluentcpp.com)\n",
"\n",
@@ -87,7 +87,7 @@
"\n",
"### [SED Saclay technology watch](https://sed.saclay.inria.fr/kw_c++.html)\n",
"\n",
- "In the experimentation and developement departement ([SED](http://sed.saclay.inria.fr/)) at [Inria Saclay](https://www.inria.fr/centre/saclay), we publish about each week few links we found interesting. C++ is rather often mentioned; the link above provides all such links related to C++ since we started doing so.\n",
+ "In the experimentation and development departement ([SED](http://sed.saclay.inria.fr/)) at [Inria Saclay](https://www.inria.fr/centre/saclay), we publish about each week few links we found interesting. C++ is rather often mentioned; the link above provides all such links related to C++ since we started doing so.\n",
"\n"
]
},