Attention une mise à jour du service Gitlab va être effectuée le mardi 30 novembre entre 17h30 et 18h00. Cette mise à jour va générer une interruption du service dont nous ne maîtrisons pas complètement la durée mais qui ne devrait pas excéder quelques minutes. Cette mise à jour intermédiaire en version 14.0.12 nous permettra de rapidement pouvoir mettre à votre disposition une version plus récente.
"_This notebook is an adaptation of a lecture prepared by David Chamont (CNRS) 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/)_ \n",
"_The present version has been written by Sébastien Gilles and Vincent Rouvreau (Inria)_"
"_This notebook is an adaptation of a lecture prepared by David Chamont (CNRS) 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/)_ \n",
"_The present version has been written by Sébastien Gilles and Vincent Rouvreau (Inria)_"
"# [Getting started in C++](/) - [Operators](/notebooks/3-Operators/0-main.ipynb) - [Comparison operators](/notebooks/3-Operators/2-Comparison.ipynb)"
"# [Getting started in C++](/) - [Operators](./0-main.ipynb) - [Comparison operators](./2-Comparison.ipynb)"
]
},
{
...
...
@@ -90,7 +90,7 @@
"\n",
"* `operator>(lhs, rhs)` is `operator<(rhs, lhs)`\n",
"* `operator>=(lhs, rhs)` is `!operator<(lhs, rhs)`\n",
"* `operator<=(lhs, rhs)` is `!operator<(rhs, lhs)`\n",
"* `operator<=(lhs, rhs)` is `!operator>(rhs, lhs)`\n",
"\n",
"\n",
"As always with operators overloading, make sure your implementation is consistent: it's not because you might define an operator `<` which is not the negation of `>=` that you should do it!\n",
"_This notebook is an adaptation of a lecture prepared by David Chamont (CNRS) 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/)_ \n",
"_The present version has been written by Sébastien Gilles and Vincent Rouvreau (Inria)_"
" r.Print(out); // see how the buk of the work is done by the 'Print()' method!\n",
" r.Print(out); // see how the bulk of the work is done by the 'Print()' method!\n",
" return out;\n",
"}\n",
"\n",
...
...
@@ -120,7 +120,7 @@
"cell_type": "markdown",
"metadata": {},
"source": [
"## Operator>>\n",
"## Operator>>\n",
"\n",
"Operator>> might be overloaded in a similar way; it might be used for instance to create an object from data readin a file. As usual with `operator>>`, you should be cautious and handle well the case in which the flux becomes invalid:"
"_This notebook is an adaptation of a lecture prepared by David Chamont (CNRS) 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/)_ \n",
"_The present version has been written by Sébastien Gilles and Vincent Rouvreau (Inria)_"
"In fact when I said by default an affectation operator is made available for the class, I was overly simplifying the issue. Lets consider for instance a class with a reference data attribute:"
"In fact when I said by default an affectation operator is made available for the class, I was overly simplifying the issue. Let's consider for instance a class with a reference data attribute:"
]
},
{
...
...
@@ -436,10 +436,10 @@
"Copy construction may in fact be quite dangerous:\n",
"\n",
"* As we've just seen, affectation and construction may differ in implementation, which is not a good thing. There are ways to define one in function of the other (see for instance item 11 of \\cite{Meyers2005}) but they aren't that trivial.\n",
"* Depending on complicated rules, some might or might not be defined implicitly.\n",
"* Depending on somewhat complicated rules that have evolved with standard versions, some might or might not be defined implicitly.\n",
"* More importantly, affectation operators may be a nightmare to maintain. Imagine you have a class for which you overload manually the affectation operator and/or the copy constructor. If later you add a new data attribute, you have to make sure not to forget to add it in both implementations; if you forget once you will enter the real of undefined behaviour... and good luck for you to find the origin of the bug!\n",
"\n",
"To avoid that I took the extreme rule to never overload those myself:\n",
"To avoid that I took the extreme rule to (almost) never overload those myself:\n",
"\n",
"* As explained briefly above, using appropriate container may remove the need. `Vector3` could be written with a `std::array` instead of the dynamic array, and the STL object will be properly copied with default behaviour!\n",
"* I define explicitly in my classes the behaviour of these operators with `= default` or `= delete` syntaxes. More often than not, my objects have no business being copied and `= delete` is really my default choice (this keyword indicates to the compiler the operator should not be provided for the class).\n",
"_This notebook is an adaptation of a lecture prepared by David Chamont (CNRS) 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/)_ \n",
"_The present version has been written by Sébastien Gilles and Vincent Rouvreau (Inria)_"
"# [Getting started in C++](/) - [Operators](/notebooks/3-Operators/0-main.ipynb) - [Functors](/notebooks/3-Operators/5-Functors.ipynb)"
"# [Getting started in C++](/) - [Operators](./0-main.ipynb) - [Functors](./5-Functors.ipynb)"
]
},
{
...
...
@@ -94,7 +94,7 @@
"\n",
"## Functors in STL\n",
"\n",
"STL itself defines some functors: imagine you want to sort a `std::vector` decreasingly; you can't directly put `>` as the comparison operation in sort and use the STL-defined `greater`: "
"STL itself defines some functors: imagine you want to sort a `std::vector` decreasingly; you can't directly put `>` as the comparison operation in `sort` and therefore may use a specific STL-defined `greater`: "
]
},
{
...
...
@@ -121,7 +121,7 @@
"cell_type": "markdown",
"metadata": {},
"source": [
"C++ 11 and above limits the need for functors with lambda functions, but in older codes functors were one of the way to pass your own rules to some STL algorithms, along with pointer to functions."
"C++ 11 and above limits the need for functors with lambda functions (see [earlier](../1-ProceduralProgramming/4-Functions.ipynb#Lambda-functions)), but in older codes functors were one of the way to pass your own rules to some STL algorithms, along with pointer to functions."
"_This notebook is an adaptation of a lecture prepared by David Chamont (CNRS) 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/)_ \n",
"_The present version has been written by Sébastien Gilles and Vincent Rouvreau (Inria)_"
