diff --git a/6-InRealEnvironment/1-SetUpEnvironment.ipynb b/6-InRealEnvironment/1-SetUpEnvironment.ipynb
index c9bb5db72b0af415df58c21f12569a5dd5f6a197..00b1afa4fbef697de67a1877e4d1a8f7f4773020 100644
--- a/6-InRealEnvironment/1-SetUpEnvironment.ipynb
+++ b/6-InRealEnvironment/1-SetUpEnvironment.ipynb
@@ -198,13 +198,13 @@
"\n",
"Besides the compiler, you may also choose which implementation of the STL you want to use. There are two mainstream choices:\n",
"\n",
- "- `libstdc++`, which is the STL provided along gcc by GNU. This is the default choice for many Linux distro, and there is fat chance the binaries, libraries and share libraries in your package system were compiled with this one.\n",
+ "- `libstdc++`, which is the STL provided along gcc by GNU. This is the default choice for many Linux distro, and there is a good chance the binaries, libraries and share libraries in your package system were compiled with this one.\n",
"\n",
"- `libc++`, which is the STL provided along clang by LLVM. It is the default choice on macOS, and was until recently a pain to use with Ubuntu (according to Laurent it is much better now in Ubuntu 20.04 and more recent versions).\n",
"\n",
"Both are pretty solid choices:\n",
"\n",
- "- Going with `libstdc++` is not a bad idea if you're using with your code libraries from your package manager that uses up this STL implementation (likely in a Linux distro).\n",
+ "- Going with `libstdc++` is not a bad idea if you're using with your code libraries from your package manager that use this STL implementation (likely in a Linux distro).\n",
"- Going with `libc++` along with clang++ seems rather natural as well."
]
},
@@ -262,10 +262,10 @@
"\n",
"There are many tutorials about how to use Git; including some from Inria:\n",
"\n",
- "- [Support](https://gitlab.inria.fr/aabadie/formation-git) using in the training sessions by Alexandre Abadie (SED Paris).\n",
+ "- [Support](https://gitlab.inria.fr/aabadie/formation-git) used in the training sessions by Alexandre Abadie (SED Paris).\n",
"- A [nice tutorial](https://tutorial.gitlabpages.inria.fr/git/) from Mathias Malandain (SED Rennes) to learn to use Git and Gitlab at the same time.\n",
"\n",
- "There are also fairly often training sessions organized in the Inria centers; ask your local SED if you're interested by one!"
+ "There are also fairly frequent training sessions organized in the Inria centers; ask your local SED if you're interested by one!"
]
},
{
@@ -281,7 +281,7 @@
"* Build system provided by your IDE. Might be easier to use (definitely the case for XCode which I'm familiar with once you grasp how it is intended to work) but you bind your potential users to use the same IDE (even if now some relies upon CMake).\n",
"* [Makefile](https://en.wikipedia.org/wiki/Makefile) is the venerable ancestor, which is really too painful to write and not automated enough for my taste.\n",
"* [Ninja](https://ninja-build.org) is presented on this website as _a small build system with a focus on speed. It differs from other build systems in two major respects: it is designed to have its input files generated by a higher-level build system, and it is designed to run builds as fast as possible_. It is my favorite generator to use with CMake; meson also enables usage of Ninja under the hood.\n",
- "* [CMake](https://cmake.org) is the build system probably with the more traction now; it is a cross-platform build system which is rather powerful but not that easy to learn. Official documentation is terse; you may try [this](https://cliutils.gitlab.io/modern-cmake/) or [that](https://cgold.readthedocs.io/en/latest/) to understand it better. Please notice CMake was heavily changed when switching from version2 to version 3; take a recent documentation if you want to learn \"modern\" CMake. The principle of CMake is to provide a generic configuration that may be used for different build tools: by default you generate a Makefile, but you may choose another generator such as Ninja (see below) or a specific IDE.\n",
+ "* [CMake](https://cmake.org) is the build system probably with the more traction now; it is a cross-platform build system which is rather powerful but not that easy to learn. Official documentation is terse; you may try [this](https://cliutils.gitlab.io/modern-cmake/) or [that](https://cgold.readthedocs.io/en/latest/) to understand it better. Please notice CMake was heavily changed when switching from version2 to version 3; take a recent documentation if you want to learn \"modern\" CMake. The principle of CMake is to provide a generic configuration that may be used for different build tools: by default you generate a Makefile, but you may choose another generator such as Ninja (see above) or a specific IDE.\n",
"* [meson](https://mesonbuild.com/) is a more recent alternative which aims to be simpler to use than CMake. Never used it so can't say much about it.\n",
"* [SCons](https://www.scons.org/) is a build system built upon Python which lets you write your own Python functions in the build system. The concept is appealing, but the actual use is actually dreadful and the provided build is much slower than what other build system provides. Avoid it!\n",
"\n",
diff --git a/6-InRealEnvironment/2-FileStructure.ipynb b/6-InRealEnvironment/2-FileStructure.ipynb
index 43f55a6d5f2bb6806e9d19bdf5bd6f302e8b6d44..a66786a30faef4676fe73c5e53852401086da13f 100644
--- a/6-InRealEnvironment/2-FileStructure.ipynb
+++ b/6-InRealEnvironment/2-FileStructure.ipynb
@@ -161,9 +161,9 @@
"\n",
"This code is not very subtle: everything is in the same file, so we are in a very simplistic case in which only one file is compiled, and there are no need to find ways to specify how several files relate to each other.\n",
"\n",
- "You may imagine working in a single file is not an very common option: it hinders reusability, and it would be cumbersome to navigate in a file with thousands or more lines or code (if you're really curious to an extreme case have a look at the amalgamation ([2.28 Mo zip here](https://www.sqlite.org/2020/sqlite-amalgamation-3310100.zip)) of sqlite code, in which all the code is put in a same source file...)\n",
+ "You may imagine working with a single file is not a very common option: it hinders reusability, and it would be cumbersome to navigate in a file with thousands or more lines of code (if you're curious about an extreme case, have a look at the amalgamation ([2.28 Mo zip here](https://www.sqlite.org/2020/sqlite-amalgamation-3310100.zip)) of sqlite code, in which all the code is put in a same source file...)\n",
"\n",
- "We want know to separate the main() and the actual content of the code (also in `2c-Demo/02-InTwoFilesWithoutHeader`): "
+ "We now want to separate the main() and the actual content of the code (also in `2c-Demo/02-InTwoFilesWithoutHeader`): "
]
},
{
@@ -707,7 +707,7 @@
"source": [
"### Header files extensions\n",
"\n",
- "The most current header files extensions are **.hpp**, **.h**, **.hh** and more seldom **.hxx**. I definitely not recommend **.h**: this is also the extension used for C header files, and some compiler even issue a warning if you're using it in a C++ context.\n",
+ "The most current header files extensions are **.hpp**, **.h**, **.hh** and more seldom **.hxx**. I definitely do not recommend **.h**: this is also the extension used for C header files, and some compiler even issue a warning if you're using it in a C++ context.\n",
"\n",
"#### My personal convention (Sébastien)\n",
"\n",
diff --git a/6-InRealEnvironment/3-Compilers.ipynb b/6-InRealEnvironment/3-Compilers.ipynb
index 47d603652353fa2591d11fb6a101bf3b89dc0e05..940799c9625ac311f76b5fee65a169688a6c06d4 100644
--- a/6-InRealEnvironment/3-Compilers.ipynb
+++ b/6-InRealEnvironment/3-Compilers.ipynb
@@ -55,7 +55,7 @@
"* `-DNDEBUG` means the macro `NDEBUG` is defined; this deactivates all asserts in the code.\n",
"* `-O3` means as many optimizations as possible should be applied.\n",
"\n",
- "You may sometimes find on the Web advocates of `-O2` flag, which performs slightly less optimization than `-O3`, on the ground that `-O3` breaks some code. It was true many years ago... but now if your code breaks under `-O3` it probably means it's buggy, not that optimization is! You may read [this thread](https://stackoverflow.com/questions/11546075/is-optimisation-level-o3-dangerous-in-g) for more about the question; I raised this point because you might be surprised by the number of libraries which still use up `-O2` in their release mode.\n",
+ "You may sometimes find on the Web advocates of `-O2` flag, which performs slightly less optimization than `-O3`, on the ground that `-O3` breaks some code. It was true many years ago... but now if your code breaks under `-O3` it probably means it's buggy, not that optimization is! You may read [this thread](https://stackoverflow.com/questions/11546075/is-optimisation-level-o3-dangerous-in-g) for more about the question; I raised this point because you might be surprised by the number of libraries which still use `-O2` in their release mode.\n",
"\n",
"\n",
"### Warnings\n",
@@ -96,7 +96,7 @@
"\n",
"[clang](http://clang.llvm.org/) is a much more recent project (2007) that proposes an interface mostly similar to the one provided by gcc.\n",
"\n",
- "This is the compiler I recommend for your development: interface is much more user friendly - even if gcc took note and made progresses on that front. But clang gets for itself:\n",
+ "This is the compiler I recommend for your development: interface is much more user friendly - even if gcc took note and made progress on that front. But clang gets for itself:\n",
"\n",
"* Default syntax coloring of the output.\n",
"* More helpful compilation error: there is even an arrow to indicate where in a line the syntax is problematic.\n",
@@ -129,7 +129,7 @@
"-Wno-documentation // Some Doxygen were incorrectly indicated as inadequate\n",
"-Wno-documentation-unknown-command // A valid Doxygen command I used was not recognized\n",
"-Wno-undefined-func-template // Requires weird code in header file; didn't understand this one to be honest\n",
- "-Wno-c++1z-extensions // I assume my code uses up C++ 20\n",
+ "-Wno-c++1z-extensions // I assume my code uses C++ 20\n",
"```\n",
"\n",
"What's neat is that your build remains up-to-date with `-Weverything`: if a new warning is added you will possibly see it if your code is affected and then decide if you want to keep it or not.\n",
@@ -174,11 +174,11 @@
"source": [
"## c++filt\n",
"\n",
- "We won't delve at all into the details, but just know that to allow stuff such as function overload, namespaces (that we'll cover [shortly](../5-Namespace.ipynb)) and so on, C++ proceed to something called _mangling_ (see [here](http://web.mit.edu/tibbetts/Public/inside-c/www/mangling.html) for instance if you're curious about this process). That's the reason in linker error messages you may see stuff such as `_ZN9cdnalizer11rewriteHTMLINS_6apache8IteratorEcEET_RKSsRKNS_6ConfigES3_S3_St8functionIFS3_RKS3_SB_EES9_IFvSsEE`\n",
+ "We won't delve at all into the details, but just know that to allow stuff such as function overload, namespaces (that we'll cover [shortly](../5-Namespace.ipynb)) and so on, C++ does something called _mangling_ (see [here](http://web.mit.edu/tibbetts/Public/inside-c/www/mangling.html) for instance if you're curious about this process). That's the reason in linker error messages you may see stuff such as `_ZN9cdnalizer11rewriteHTMLINS_6apache8IteratorEcEET_RKSsRKNS_6ConfigES3_S3_St8functionIFS3_RKS3_SB_EES9_IFvSsEE`\n",
"\n",
- "The least we can say is that's it's not very user friendly; sometimes what is behind the symbol will be clear enough, sometimes not that so....\n",
+ "The least we can say is that's it's not very user friendly; sometimes what is behind the symbol will be clear enough, sometimes not that much....\n",
"\n",
- "Luckily, both clang and gcc are shipped with a nifty tool named `c++filt` to decipher it, with same name and interface:"
+ "Luckily, both clang and gcc ship with a nifty tool named `c++filt` to decipher it, with same name and interface:"
]
},
{
@@ -212,7 +212,7 @@
"source": [
"## Wandbox\n",
"\n",
- "If you need to know whether a small code is supported by a specific version of clang or gcc, you may use the online compiler facility [Wandbox](https://wandbox.org/) which provides many gcc and clang versions (and even Boost library for good measure)."
+ "If you need to know whether some small code is supported by a specific version of clang or gcc, you may use the online compiler facility [Wandbox](https://wandbox.org/) which provides many gcc and clang versions (and even Boost library for good measure)."
]
},
{
diff --git a/6-InRealEnvironment/4-ThirdParty.ipynb b/6-InRealEnvironment/4-ThirdParty.ipynb
index 5ce1937f76b8bd939975a7ec59dc2d6ddacfe8f8..a5b6316ae06df178979d468aab91d1dda854e560 100644
--- a/6-InRealEnvironment/4-ThirdParty.ipynb
+++ b/6-InRealEnvironment/4-ThirdParty.ipynb
@@ -13,15 +13,15 @@
"source": [
"## Introduction\n",
"\n",
- "Any sizable code doesn't exist in a void: it's likely it needs to be build upon pre-existing libraries at some point. \n",
+ "Any sizable code doesn't exist in a void: it's likely it needs to be built upon some pre-existing libraries. \n",
"\n",
- "We discussed a lot about the STL up-to-now in this tutorial, but it's likely you will need some other libraries more specific to your field (for instance if you're doing numerical computation you'll probably need a solver from a library).\n",
+ "We have mostly talked about the STL up to this point in this tutorial, but it's likely you will need some other libraries more specific to your field (for instance if you're doing numerical computation you'll probably need a solver from a library).\n",
"\n",
- "C++ may be interfaced rather easily with C and Fortran code; however a recurrent issue that is the reason of the current notebook is warnings: even highly recommended and used libraries such as [Boost](https://www.boost.org/) are cluttered with warnings and there are no easy solution:\n",
+ "C++ may be interfaced rather easily with C and Fortran code; however a recurrent issue that is the reason of the current notebook is warnings: even highly recommended and used libraries such as [Boost](https://www.boost.org/) are cluttered with warnings and there is no easy solution:\n",
"\n",
"* Fixing the warnings from the third-party library yourself is a dead-end: you would have to redo-it at each upgrade of the library... and doing it in the first place may not be that easy with a base code you do not know. \n",
- "* Of course, you may ask the library developers to fix it, or even better provide a **pull request** to do it for them... but they may not be keen to accept it, and argue they know what they're doing and that you should shut the damn compiler warning up. But you really shouldn't: the warnings you want to use or not should be dictated by your own needs, not by the third-party libraries.\n",
- "* Keeping the warnings is also bad: as already mentioned if you're letting even 10 warnings in your code you may not see the dangerous 11th a change in the code may produce.\n",
+ "* Of course, you may ask the library developers to fix it, or even better provide a **pull request** to do it for them... but they may not be keen to accept it, and argue they know what they're doing and that you should silence the damn compiler warnings. But you really shouldn't: the warnings you want to use or not should be dictated by your own needs, not by third-party libraries'.\n",
+ "* Keeping the warnings is also bad: as already mentioned if you're letting even 10 warnings in your code you may not see the dangerous 11th warning that a change in the code may produce.\n",
"\n",
"## Demo\n",
"\n",
@@ -143,19 +143,19 @@
"cell_type": "markdown",
"metadata": {},
"source": [
- "I must admit I don't usually go this way and uses up the second option, but I admit it seems much more straightforward than the second approach.\n",
+ "I must admit I don't usually go this way and instead use the second option, but I admit it seems quite straightforward.\n",
"\n",
"The few drawbacks I can see are: \n",
"\n",
"* You have to figure out how your build system takes this into account.\n",
- "* You have to make sure it is portable: another user may not place these third-party headers in the same location as you, and you have to figure out a proper way to indicate where they are. This is by no mean overwhelming, but still requires a bit of work. This is especially so if the third party library is directly embedded in your code (might happen, especially if the library is header only).\n"
+ "* You have to make sure it is portable: another user may not place these third-party headers in the same location as you, and you have to figure out a proper way to indicate where they are. This is by no means overwhelming, but still requires a bit of work. This is especially so if the third party library is directly embedded in your code (might happen, especially if the library is header only).\n"
]
},
{
"cell_type": "markdown",
"metadata": {},
"source": [
- "## Deactivating locally warning with pragmas in your code"
+ "## Deactivating the warnings locally with pragmas in your code"
]
},
{
@@ -208,7 +208,7 @@
"source": [
"Yes, even in a top-notch library like Boost there are plenty of warnings! (but don't use that as an excuse not to clean-up yours...)\n",
"\n",
- "Unfortunately, you will surely have seen _clang_ is mentioned explicitly; gcc needs same kind of work... with the exact same syntax, compiler name aside. For instance if `-Wsign_conversion` is activated in your gcc build, you will need GCC pragma:"
+ "Unfortunately, you will surely have seen _clang_ is mentioned explicitly; gcc needs the same kind of work... with the exact same syntax, compiler name aside. For instance if `-Wsign_conversion` is activated in your gcc build, you will need GCC pragma:"
]
},
{
@@ -259,9 +259,9 @@
"source": [
"### Extra level of indirection\n",
"\n",
- "There's common quote in C++ that almost every problem may be solved by adding an extra level of indirection. I recommend using it here if you go the pragma way: if several files in your project needs Boost filesystem to be included, it is better to define a header file of yours which will include the gory details with the pragmas. This way, you will repeat the Don't Repeat Yourself! principle and make your code more manageable (if one new warning appears after compiler update you need to change it at only one location) and also make your general code more readable, but substituting a big block by just one include line.\n",
+ "There's a common quote in the C++ community that almost every problem may be solved by adding an extra level of indirection. I recommend using it here if you go the pragma way: if several files in your project need the Boost filesystem to be included, it is better to define a header file of yours which will include the gory details with the pragmas. This way, you will repeat the Don't Repeat Yourself! principle and make your code more manageable (if one new warning appears after a compiler update you need to change it in only one location) and also make your code generally more readable, by substituting a big block by just one include line.\n",
"\n",
- "In my project, I include Boost filesystem with:\n",
+ "In my project, I include the Boost filesystem with:\n",
"\n",
"```c++\n",
"#include \"ThirdParty/IncludeWithoutWarning/Boost/Filesystem.hpp\"\n",
diff --git a/6-InRealEnvironment/6-Tools.ipynb b/6-InRealEnvironment/6-Tools.ipynb
index 5d40111791a126cb12ade08e6b04222977371a8a..0b07e534b8b534d8b598366d7541300f9e760971 100644
--- a/6-InRealEnvironment/6-Tools.ipynb
+++ b/6-InRealEnvironment/6-Tools.ipynb
@@ -14,9 +14,9 @@
"## Introduction\n",
"\n",
"The purpose of this notebook is just to namedrop briefly some facilities related to C++ that might be useful.\n",
- "It's far from exhaustive - I won't present debuggers as usually they are provided directly with your IDE (and if you're a Vim or Emacs user you probably already familiar with [gdb](https://www.gnu.org/software/gdb/)).\n",
+ "It's far from exhaustive - I won't present debuggers as usually they are provided directly with your IDE (and if you're a Vim or Emacs user you're probably already familiar with [gdb](https://www.gnu.org/software/gdb/)).\n",
"\n",
- "Some tools are redundant, but they are complementary: the more you may be able to use the better. The constraint is time: it is not straightforward to use some of those, and even for the user-friendly ones there is a non neglictible set-up time. But for projects that are gaining traction it becomes a no-brainer at some point to set-up those properly once and for all - usually part of [continuous integration](https://gitlab.inria.fr/FormationIntegrationContinue/gitlabciintroduction) process.\n",
+ "Some tools are redundant, but they are complementary: the more you use the better. The constraint is time: it is not straightforward to use some of those, and even for the user-friendly ones there is a non negligible set-up time. But for projects that have gained enough traction, at some point it becomes a no-brainer to set them up properly once and for all - usually part of the [continuous integration](https://gitlab.inria.fr/FormationIntegrationContinue/gitlabciintroduction) process.\n",
"\n",
"\n",
"## Online compilers\n",
@@ -102,11 +102,11 @@
"\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",
+ "We wouldn't however advice to use the options to automatically correct your documents; there might be some false positives.\n",
"\n",
"## Ccache\n",
"\n",
- "[Ccache](https://ccache.dev/) is a great tool that caches compilation results and does it very well even when you work with different git branches, for instance. If your compilation time, even if you compile in parallel mode, is getting annoyingly too long, this tool is recommended. Ccache is also quite well integrated with CMake.\n",
+ "[Ccache](https://ccache.dev/) is a great tool that caches compilation results and does it very well even when you work with different git branches, for instance. If your compilation time, even if you compile in parallel mode, is getting too annoyingly long, this tool is recommended. Ccache is also quite well integrated with CMake.\n",
"\n",
"## More...\n",
"\n",