"Functions cannot be nested in C++, contrary to some other langages such as Python:"
"Functions cannot be nested in C++, contrary to some other languages such as Python:"
]
},
{
...
...
%% Cell type:markdown id: tags:
# [Getting started in C++](./) - [Procedural programming](./0-main.ipynb) - [Functions](./4-Functions.ipynb)
%% Cell type:markdown id: tags:
## Function declaration and definition
### Function declaration
The aim of a **function declaration** is just to describe its prototype:
- The return type of the function (or `void` if the function returns nothing).
- The number, type and ordering of the parameters (if any). Naming them specifically is entirely optional (but is useful if you choose to put your [Doxygen](../6-InRealEnvironment/6-Tools.ipynb#Doxygen) documentation along your functions declarations - see below).
Declaration ends by a semicolon `;`; the point of the declaration is to announce to the rest of the code that a function with this exact prototype exists and may be used elsewhere.
Few examples of function declarations:
%% Cell type:code id: tags:
``` c++
intComputeMinimum(inta,intb);
```
%% Cell type:code id: tags:
``` c++
voidDoStuff(double);// naming the parameter is optional
```
%% Cell type:code id: tags:
``` c++
intReturnFive();// providing a parameter is also optional...
// Don't bother the notebook kernel warning: it IS here a function declaration!
```
%% Cell type:markdown id: tags:
Due to the use of notebooks we will not need to separate clearly function declaration from its definition, but we will revisit this [much later](../6-InRealEnvironment/2-FileStructure.ipynb) when we will see how a real project is written with different files involved.
%% Cell type:markdown id: tags:
### Function definition
%% Cell type:markdown id: tags:
On the other hand, the **function definition** aims at providing the implementation of the function that may (and should!) have been declared beforehand.
In a function definition:
- No semicolon after the prototype
- A block follows the prototype instead; inside this block the implementation is written.
- Parameter may not be named, but if they are used (which should be the case most of the time hopefully...) you will need such a name in the implementation.
- No semicolon after the closing brace.
For instance:
%% Cell type:code id: tags:
``` c++
#include<iostream>
voidPrintDivision(intnumerator,intdenominator)// no semicolon here!
{
if(denominator==0)
std::cout<<"Failure: division by zero!"<<std::endl;
and when the function is invoked at some point, the implementation above is directly put in motion:
%% Cell type:code id: tags:
``` c++
intnum=3;
intdenom=2;
PrintDivision(num,denom);
```
%% Cell type:markdown id: tags:
#### A terminology note: _parameter_ and _argument_
In the function above, I called `numerator` and `denominator`**parameters**, and you may also have heard the term **argument**.
For the purists:
-**parameter** is the name used when speaking about what is between the parenthesis during the function definition (`numerator` and `denominator` in the function definition)
-**argument** is what is passed when the function is effectively called within your code (`num` and `denom` in the above cell)
I do not guarantee that I am using the right term everywhere in the code: I'm not a purist and often use one for another (if you want to remember properly a helpful mnemotechnic is that **a**rguments are **a**ctual).
%% Cell type:markdown id: tags:
#### Functions cannot be nested, or declared within blocks
%% Cell type:markdown id: tags:
Functions cannot be nested in C++, contrary to some other langages such as Python:
Functions cannot be nested in C++, contrary to some other languages such as Python:
%% Cell type:code id: tags:
``` c++
voidFunction1()// a function might have no arguments
{
voidSubfunction()// COMPILATION ERROR!
{
}
}
```
%% Cell type:markdown id: tags:
To reintroduce hierarchy, __namespaces__ can be used (they will be introduced [a bit later](../6-InRealEnvironment/5-Namespace.ipynb)); __lambda functions__ introduced later in this notebook are not limited by the same rule.
%% Cell type:markdown id: tags:
## How to pass arguments
### Passing arguments by value
In the simple example above, we passed the arguments by value, which is to say the values passed by the arguments were copied when given to the function:
%% Cell type:code id: tags:
``` c++
#include<iostream>
voidIncrementAndPrint(intvalue)
{
++value;
std::cout<<"Inside the function: value = "<<value<<std::endl;
}
{
inti{5};
IncrementAndPrint(i);
std::cout<<"Outside the function: i = "<<i<<std::endl;
}
```
%% Cell type:markdown id: tags:
#### Naming and scope
%% Cell type:markdown id: tags:
In the above example, the value of the function `IncrementAndPrint` was named `value`, whereas at call site the variable was simply named `i`.
We could as well have used the same name in both places - there are no ambiguity whatsoever in doing so.
%% Cell type:code id: tags:
``` c++
voidIncrementAndPrintUseI(inti)
{
++i;
std::cout<<"Inside the function: i = "<<i<<std::endl;
}
{
inti{5};
IncrementAndPrintUseI(i);
std::cout<<"Outside the function: i = "<<i<<std::endl;
}
```
%% Cell type:markdown id: tags:
This might seem idiotic (and sure enough giving a name as simple as a one letter character is misguided in most cases!), but on
the other hand when you're considering a mathematical or physical quantity (`jacobian`, `displacement`, etc... ) you do not want
to force yourself to find another name (naming is already hard enough as it is).
The reason there are no ambiguity at all is that in each scope (remember [first notebook](../1-ProceduralProgramming/1-Variables.ipynb#Scope-and-blocks))
there is at most one `i` defined.
%% Cell type:markdown id: tags:
### Passing arguments by reference
If we intended to modify the value of `i` outside the function (and given the name of the function this is strongly hinted...), we should have passed it by reference:
%% Cell type:code id: tags:
``` c++
#include<iostream>
voidIncrementAndPrintByReference(int&i)
{
++i;
std::cout<<"Inside the function: i = "<<i<<std::endl;
}
{
inti=5;// I could have named it differently - it doesn't matter as the scope is different!
IncrementAndPrintByReference(i);
std::cout<<"Outside the function: i = "<<i<<std::endl;
}
```
%% Cell type:markdown id: tags:
As in C++ you cannot return several values in the return type, passing by reference is a way to get in output several values (C++ 11 introduced in the standard library a workaround to get several values in return type with a so-called `std::tuple`, but the passing by reference remains the better way to do so in most cases).
std::cout<<"5 / 3 = "<<quotient<<" with a remainder of "<<remainder<<'.'<<std::endl;
if(ComputeDivision(5,0,quotient,remainder)==0)
std::cout<<"5 / 0 = "<<quotient<<" with a remainder of "<<remainder<<'.'<<std::endl;
else
std::cerr<<"Can't divide by 0!"<<std::endl;
}
```
%% Cell type:markdown id: tags:
### A bit of wandering: using C-like error codes
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.
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 `ComputeDivision()` 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).
Below is an example where things go awry due to the lack of check:
%% Cell type:code id: tags:
``` c++
#include<iostream>
voidPrintDivision(intarg1,intarg2)
{
intquotient,remainder;
ComputeDivision(arg1,arg2,quotient,remainder);// the dev 'forgot' to check the error code.
std::cout<<"Euclidean division of "<<arg1<<" by "<<arg2<<" yields a quotient of "
<<quotient<<" and a remainder of "<<remainder<<std::endl;
}
PrintDivision(8,5);
PrintDivision(8,0);// bug!
```
%% Cell type:markdown id: tags:
The developer made two important mistakes:
* The return value of `ComputeDivision` is not checked, so something is printed on screen.
* This is something completely out of control: quotient and remainder do not get a default value that would help to see if something is askew. The behaviour is undefined: you have no guarantee on the values the program will print (currently I see the same values as in the previous function call, but another compiler/architecture/etc... might yield another wrong value.
%% Cell type:markdown id: tags:
#### [[nodiscard]]
C++ 17 introduced a keyword named `[[nodiscard]]` that mitigates the issue mentioned above; this keyword tells the return value must be checked and not doing so is a **compilation warning**.
It doesn't prevent a developer to use improperly the `ComputeDivision` function, but at least they are warned that they're doing something wrong.
ComputeDivision(arg1,arg2,quotient,remainder);// the dev 'forgot' to check the error code.
std::cout<<"Euclidean division of "<<arg1<<" by "<<arg2<<" yields a quotient of "
<<quotient<<" and a remainder of "<<remainder<<std::endl;
}
intmain([[maybe_unused]]intargc,char**argv)
{
PrintDivision(8,0);// bug!
returnEXIT_SUCCESS;
}
```
%% Cell type:markdown id: tags:
### Passing arguments by pointers
When the argument of a function is a pointer, each function call
results in the creation of a temporary pointer which is given the address provided as argument. Then using the `*` operator, you can access the
original variable, not a copy.
Except in the case of interaction with a C library or some _very_ specific cases, I wouldn't advise using passing arguments by pointers: by reference does the job as neatly and in fact more efficiently (dereferencing a pointer `i` with `*i` syntax is not completely costless performance-wise).
%% Cell type:code id: tags:
``` c++
#include<iostream>
voidIncrementAndPrintByPointer(int*i)
{
*i+=1;
std::cout<<"Inside the function: i = "<<*i<<std::endl;
}
{
inti=5;// I could have named it differently - it doesn't matter as the scope is different!
IncrementAndPrintByPointer(&i);
std::cout<<"Outside the function: i = "<<i<<std::endl;
}
```
%% Cell type:markdown id: tags:
## Function with return value
The value to return should come after the keyword `return`.
A C++ function may include several return values in its implementation:
%% Cell type:code id: tags:
``` c++
#include<iostream>
//! \brief Returns 1 if the value is positive, 0 if it is 0 and -1 if it's negative.
intSign(inta)
{
if(a>0)
return1;
if(a==0)
return0;
return-1;
}
{
for(inta=-3;a<4;++a)
std::cout<<"Sign of "<<a<<" = "<<Sign(a)<<std::endl;
}
```
%% Cell type:markdown id: tags:
## Alternate function syntax
There is now since C++ 11 another way to declare a function using so called `trailing return types`; it is not widespread but is advised by some developers (see for instance [this blog post](https://blog.petrzemek.net/2017/01/17/pros-and-cons-of-alternative-function-syntax-in-cpp/) which lists pros and cons of both syntaxes).
%% Cell type:code id: tags:
``` c++
%%cppmagicscppyy/cppdef
// < Notebook-related line - without it the perfectly valid C++ syntax below wouldn't be accepted. Don't bother!
It is possible to define several different functions with the exact same name, provided the type of the argument differ:
%% Cell type:code id: tags:
``` c++
#include<string>
voidF();
voidF(int);// Ok
doubleF(int,double);// Ok
autoF(char)->int;// Ok (alternate function syntax)
std::stringF(double,int,char*);// Ok
```
%% Cell type:markdown id: tags:
### **[WARNING]** Return type does not count!
It is not the entire signature of the function that is taken into account when possible ambiguity is sought by the compiler: the return type is not taken into account. So the following cases will not be valid:
%% Cell type:code id: tags:
``` c++
voidG(int);
intG(int);// COMPILATION ERROR
```
%% Cell type:markdown id: tags:
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 id: tags:
### **[WARNING]** This is a C++ only feature and will not work in C!
%% Cell type:markdown id: tags:
In C you cannot do the following: if you run a simple program with overload:
```c
#include<stdio.h>
voidf()
{
printf("No argument version");
}
voidf(inta)
{
printf("Int argument version");
}
intmain()
{
return0;
}
```
you will get error messages such as:
```shell
prog.c:8:6: error: redefinition of 'f'
8 | void f(int a)
| ^
prog.c:3:6: note: previous definition of 'f' with type'void()'
3 | void f()
```
(you may check this with [Wandbox](https://wandbox.org/) and select C instead of C++ as language).
%% Cell type:markdown id: tags:
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 id: tags:
### Good practice: do not make signature vary only by a reference or a pointer
%% Cell type:markdown id: tags:
On the other hand, compiler is completely able to accept signatures that differs only by a reference or a pointer on one of the argument:
%% Cell type:code id: tags:
``` c++
#include<iostream>
voidH(doublea)
{
std::cout<<"h(double) is called with a = "<<a<<'.'<<std::endl;
}
```
%% Cell type:code id: tags:
``` c++
#include<iostream>
voidH(double*a)// Ok
{
std::cout<<"h(double*) is called with a = "<<*a<<"; a is doubled by the function."<<std::endl;
*a*=2.;
}
```
%% Cell type:code id: tags:
``` c++
#include<iostream>
voidH(double&a)// Ok... but not advised! (see below)
{
std::cout<<"h(double&) is called with a = "<<a<<"; a is doubled by the function."<<std::endl;
a*=2.;
}
```
%% Cell type:code id: tags:
``` c++
{
H(5);// Ok
doublex=1.;
H(&x);// Ok
}
```
%% Cell type:markdown id: tags:
However, there is a possible ambiguity between the pass-by-copy and pass-by-reference:
%% Cell type:code id: tags:
``` c++
{
doublex=1.;
H(x);// COMPILATION ERROR: should it call h(double) or h(double& )?
}
```
%% Cell type:markdown id: tags:
You can lift the ambiguity for the pass-by-value:
%% Cell type:code id: tags:
``` c++
{
doublex=1.;
H(static_cast<double>(x));// Ok
}
```
%% Cell type:markdown id: tags:
But not to my knowledge for the pass-by-reference... So you should really avoid doing so: if you really need both functions, name them differently to avoid the ambiguity.
I would even avoid the pointer case: granted, there is no ambiguity for a computer standpoint, but if you get a developer who is not 100% clear about the pointer syntax he might end-up calling the wrong function:
%% Cell type:code id: tags:
``` c++
#include<iostream>
voidH2(doublea)
{
std::cout<<"h2(double) is called with a = "<<a<<'.'<<std::endl;
}
```
%% Cell type:code id: tags:
``` c++
#include<iostream>
voidH2(double*a)
{
std::cout<<"h2(double*) is called with a = "<<*a<<"; a is doubled by the function."<<std::endl;
*a*=2.;
}
```
%% Cell type:code id: tags:
``` c++
{
doublex=5.;
double*ptr=&x;
H2(x);// call h2(double)
H2(ptr);// call h2(double*)
H2(*ptr);// call h2(double)
H2(&x);// call h2(double*)
}
```
%% Cell type:markdown id: tags:
### Best viable function
In fact, overloading may work even if the match is not perfect: the **best viable function** is chosen if possible... and some ambiguity may appear if none matches!
The complete rules are very extensive and may be found [here](https://en.cppreference.com/w/cpp/language/overload_resolution); as a rule of thumb you should really strive to write overloaded functions with no easy ambiguity... or not using it at all: sometimes naming the function differently avoids loads of issues!
%% Cell type:code id: tags:
``` c++
#include<iostream>
intMin(inta,intb)
{
std::cout<<"int version called!"<<std::endl;
returna<b?a:b;
}
```
%% Cell type:code id: tags:
``` c++
#include<iostream>
doubleMin(doublea,doubleb)
{
std::cout<<"double version called!"<<std::endl;
returna<b?a:b;
}
```
%% Cell type:code id: tags:
``` c++
{
inti1{5},i2{-7};
doubled1{3.14},d2{-1.e24};
floatf1{3.14f},f2{-4.2f};
shorts1{5},s2{7};
Min(5,7);// no ambiguity
Min(i1,i2);// no ambiguity
Min(f1,f2);// conversion to closest one
Min(f1,d2);// conversion to closest one
Min(s1,s2);// conversion to closest one
}
```
%% Cell type:markdown id: tags:
However, with some other types it doesn't work as well if implicit conversion is dangerous and may loose data:
%% Cell type:code id: tags:
``` c++
{
unsignedinti1{5},i2{7};
Min(i1,i2);// COMPILATION ERROR: no 'obvious' best candidate!
}
```
%% Cell type:code id: tags:
``` c++
{
longi1{5},i2{7};
Min(i1,i2);// COMPILATION ERROR: no 'obvious' best candidate!
}
```
%% Cell type:markdown id: tags:
Likewise, if best candidate is not the same for each argument:
%% Cell type:code id: tags:
``` c++
{
floatf1{5.f};
inti1{5};
Min(f1,i1);// for i1 the 'int'version is better, but for f1 the 'double' is more appropriate...
}
```
%% Cell type:markdown id: tags:
### Advice: use overload only when there is no ambiguity whatsoever
That is when:
- The number of arguments is different between overloads.
- Or their types do not convert implicitly from one to another. For instance the following overloads are completely safe to use and the interface remains obvious for the end-user:
The reason not to repeat them is rather obvious: if both were accepted you may modify one of them and forget to modify the others, which would be a bad design...
There is a way to put it in the same place, that I do not recommend it (and your compiler should warn you most of the time): if you do not declare the function beforehand, default arguments may be specified at definition:
In C and C++, arguments are only **positional**: you do not have a way to explicitly set an argument with a name for instance.
Therefore:
* Optional arguments must be put together at the end of the function.
* You must think carefully if there are several of them and put the less likely to be set manually by the function user at then end. In our example above, if you want do call the function with a `x` and a `z` you must mandatorily also provide explicitly `y`.
%% Cell type:markdown id: tags:
## Lambda functions
C++ 11 introduced a shorthand to define functions called __lambda functions__.
An example is the best way to introduce them:
%% Cell type:code id: tags:
``` c++
#include<iostream>
{
// Locally defined function.
autoSquare=[](doublex)->double
{
returnx*x;
};
std::cout<<Square(5.)<<std::endl;
}
```
%% Cell type:markdown id: tags:
Several notes:
* Use `auto` as its return type; said type is not reproducible (see the _square_ and _cube_ example below).
* The symbol `->` that specifies the type of the returned value is optional.
* Parameters come after the `[]` in parenthesis with the same syntax as ordinary functions.
* This is not the same as the [alternate syntax](../1-ProceduralProgramming/4-Functions.ipynb#Alternate-function-syntax) explained earlier, even if they look similar: a lambda may be defined locally (here within a block) whereas a standard function (with usual or alternate syntax) can't.
%% Cell type:code id: tags:
``` c++
#include<iostream>
{
// Locally defined function.
autoSquare=[](doublex)
{
returnx*x;
};
autoCube=[](doublex)
{
returnx*x*x;
};
std::cout<<"Are the lambda prototypes the same type? "
Inside the `[]` you might specify values that are transmitted to the body of the function; by default nothing is transmitted:
%% Cell type:code id: tags:
``` c++
#include<iostream>
{
inta=5;
autoAPlusB=[](intb)
{
returna+b;
};
std::cout<<APlusB(3)<<std::endl;// COMPILATION ERROR: a is not known inside the lambda body.
}
```
%% Cell type:code id: tags:
``` c++
#include<iostream>
{
inta=5;
autoAPlusB=[a](intb)// Notice the `[a]` here!
{
returna+b;
};
std::cout<<APlusB(3)<<std::endl;
}
```
%% Cell type:markdown id: tags:
The values captured in the lambda might be transmitted by reference:
%% Cell type:code id: tags:
``` c++
#include<iostream>
{
inta=5;
autoAddToA=[&a](intb)// Notice the `[&a]` here!
{
a+=b;
};
AddToA(3);
std::cout<<a<<std::endl;
}
```
%% Cell type:markdown id: tags:
It is possible to capture everything (in the scope where the lambda is defined) by reference by using `[&]` but it is really ill-advised; don't do this!
Lambda functions really shines when you want to use them in a very special context; see below an example using the [`std::sort`](https://en.cppreference.com/w/cpp/algorithm/sort) function provided by the standard library (don't worry about `std::sort` - we will address it later in the notebook dedicated to [algorithms](../5-UsefulConceptsAndSTL/7-Algorithms.ipynb). If you want to know more you may also consult [cppreference](https://en.cppreference.com/w/cpp/algorithm/sort)).
Let's imagine that for some reasons we want to sort integers in a weird fashion: first the odd numbers properly ordered and then the even numbers. We can give this admittedly pointless choice through a lambda:
// Don't worry about the syntax of `copy_if` or `back_inserter` here; we will see that later!
std::copy_if(list.cbegin(),
list.cend(),
std::back_inserter(even_only),
[](intvalue)
{
returnvalue%2==0;
});
for(intvalue:even_only)
std::cout<<value<<' ';
}
```
%% Cell type:markdown id: tags:
## Passing a function as a an argument
In some cases, you might want to pass a function as an argument (and honestly most of the time you should refrain to do so: it may underline your design is not top notch).
The syntax to do so is a bit ugly and stems directly from C; it relies upon using a pointer to a function.
The syntax looks like:
```c++
unsignedint(*f)(int,double)
```
where:
*`unsigned int` is the return type.
*`int, double` are the type of the parameters of the function given as argument.
* Using a template parameter. Templates will be reached [later in this tutorial](../4-Templates/0-main.ipynb), but for me it's usually the way to go.
* Using [functors](../3-Operators/5-Functors.ipynb)
* Using `std::function`, introduced in C++ 11. However <ahref="https://vittorioromeo.info/index/blog/passing_functions_to_functions.html">this blog</a> explains why it's not a good idea; on top of the arguments given there it doesn't seem to respect the prototype closely (a function with double instead of int is for instance accepted).
%% Cell type:markdown id: tags:
## A very special function: __main__
Any C++ program must include one and only one `main` function. Its prototype is `int main(int argc, char** argv)` where:
* __argc__ is the number of arguments given on the command line. This is at least 1: the name of the program is one argument. For instance, if your program creates a _isPrime_ executable that takes an integer as argument, `argc` will return 2.
* __argv__ is the list of arguments read on the command line, given as an array of C-strings. In our _isPrime_ example, __argv[0]__ is _isPrime_ and __argv[1]__ is the integer given.
Please notice the internal mechanics of C/C++ compiler returns these values; if a user type `isPrime qwerty 20`, the main functions will return argc = 3. It is up to the writer of the main to ensure the arguments are correct.
If some of these values should be interpreted as numbers, it is also up to the developer to foresee the conversion from the C-string to a numerical value.
In the very specific of our Jupyter notebook, a unique main might be defined or not in the file: _cling_ performs some magic to generate one under the hood.
The __main__ function may also be defined as __int main()__ without arguments if the program doesn't actually need any.
Sometimes, in old programs you may see __void main()__; this is not correct and is now refused by most modern compilers.
The return value of the main function is an integer, __EXIT_SUCCESS__ should be returned when the program succeeds and __EXIT_FAILURE__ if it fails. You will often see a numerical value instead of these: __EXIT_SUCCESS__ is just a macro which value is 0. I recommend its use as you should strive to avoid any magic number in your codes. These two macros are defined inside `cstdlib` header.
We will deal with main functions later when we will work in a true C++ environment.
%% Cell type:markdown id: tags:
## `inline` functions
You may also in a function declaration and definition function prepend the prototype by an `inline`. This indicates the compiler this function might be **inlined**: this means the content of the function may be copied directly, thus avoiding a function call and potentially making your code a tiny bit faster. So for instance if you have a function:
%% Cell type:code id: tags:
``` c++
inlinedoubleSquare(doublex)
{
returnx*x;
}
```
%% Cell type:markdown id: tags:
when this function is called somewhere, the compiler may replace directly the function by the code inside the definition:
%% Cell type:code id: tags:
``` c++
{
Square(5.);// The compiler might substitute 5. * 5. to the actual function call here
}
```
%% Cell type:markdown id: tags:
This behaviour is pretty similar to the often frowned-upon **macros** from C, but the use of `inline` is absolutely not considered a bad practice... provided you have in mind the way it works:
* You have probably notice the conditional in my statements regarding `inline`: the keyword is an _hint_ given to the compiler... that might be followed or not.
* On the syntactic side, `inline` must be provided both in the declaration `and` the definition.
*`inline` definitions must be provided in header file (see the [upcoming notebook](../6-InRealEnvironment/2-FileStructure.ipynb) that will deal extensively with the file structure to follow in a C++ program). You therefore pay the price in compilation time whenever you change its implementation (as we'll see more in detail in aforementioned notebook, modifying a header file yields more re-compilation).
* Don't bother inlining functions with any complexity whatsoever, so if your function includes a loop or is more than few lines long, write a normal function instead.
The `Square` example was sound: this is typically the kind of functions that might be inlined.
Just to finish, my comparison with a macro was not fair; one of the known drawback of macros is perfectly handled:
# [Getting started in C++](./) - [Procedural programming](./0-main.ipynb) - [Dynamic allocations](./5-DynamicAllocation.ipynb)
%% Cell type:markdown id: tags:
## Introduction
In C++, we can finely control the life cycle of objects and manage the memory allocated to them. This is what makes it possible to create more powerful applications than with many other languages, but it is also the main source of errors in the language. Pointers and dynamic memory management: watch out for danger!
## Stack
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.
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.
If you want to learn more about memory layout, have a look [here](https://www.geeksforgeeks.org/memory-layout-of-c-program/).
%% Cell type:code id: tags:
``` c++
{
{
inta{5};
doubleb{7.4};
}// at the end of this block, b is released first and then a - but 99.99 % of the time you shouldn't care
// about that order!
// a and b are not available here
}
```
%% Cell type:markdown id: tags:
There are few limitations with the stack:
* The number of memory you can allocate on the stack is rather limited. On a current POSIX OS the order of magnitude is ~ 8 MB (on Unix type `ulimit -s` in a terminal to get this information). If you allocate more you will get a **stack overflow** (and now you know why the [most popular developers forum](https://stackoverflow.com/) is named this way!)
* The information is very local; you can't use it elsewhere. If you pass the variable as argument in a function for instance a copy is made (or if you're using a reference or a pointer you have to be sure all is done when the block is exited!)
* Stack information must be known at compile time: if you're allocating an array on the stack you must know its size beforehand.
%% Cell type:markdown id: tags:
## Heap and free store
You can in fact also explicitly place a variable in another memory area called **heap** or **free store**; doing so overcomes the stack limitations mentioned above.
This is done by calling the `new` operator, which reserves the memory and returns its address, so that the user can store it _with a pointer_.
The **heap** is independent of the **stack** and the variable thus created exists as long as the `delete` operator is not explicitly called. The creation and destruction of this type of variable is the responsibility of the programmer.
%% Cell type:code id: tags:
``` c++
#include<iostream>
{
int*n=newint(5);// variable created on the heap and initialized with value 5.
std::cout<<*n<<std::endl;
deleten;// deletion must be explicitly called; if not there is a memory leak!
}
```
%% Cell type:markdown id: tags:
What is especially tricky is that:
* Creating and destroying can be done in places very disconnected in your program.
* You must ensure that whatever the runtime path used in your program each variable allocated on the heap:
- is destroyed (otherwise you get a **memory leak**)
- is only destroyed once (or your program will likely crash with a message about **double deletion**).
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.
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.
%% Cell type:markdown id: tags:
### Free store?
**Free store** is very similar in functionality to the **heap** (to the point I had to [check the difference](https://stackoverflow.com/questions/1350819/c-free-store-vs-heap) before writing this...) , and more often than not one word might be used as the other. If you want to be pedantic:
* When memory is handled by `new`/`delete`, you should talk about **free store**.
* When memory is handled by `malloc`/`free` (the C functions), you should talk about **heap**.
Pedantry aside, the important thing to know is to never mix both syntax: if you allocate memory by `new` don't use `free` to relieve it.
%% Cell type:markdown id: tags:
## Arrays on heap
If you want to init an array which size you do not know at compile time or that might overflow the stack, you may to do with `new` syntax mixed with `[]`:
%% Cell type:code id: tags:
``` c++
#include<random>
int*throw_dice(std::size_tndigit){
// Don't bother much here - this is lifted from https://en.cppreference.com/w/cpp/numeric/random/uniform_int_distribution
std::random_devicerd;// a seed source for the random number engine
std::mt19937gen(rd());// mersenne_twister_engine seeded with rd()
std::uniform_int_distribution<>distrib(1,6);
int*dice_result=newint[ndigit];
for(std::size_ti=0;i<ndigit;++i)
dice_result[i]=distrib(gen);
returndice_result;
}
```
%% Cell type:code id: tags:
``` c++
#include<iostream>
autoNdice=5ul;
int*throw_5_dices=throw_dice(Ndice);
int*throw_5_dice=throw_dice(Ndice);
for(std::size_ti=0;i<Ndice;++i)
std::cout<<throw_5_dices[i]<<std::endl;
std::cout<<throw_5_dice[i]<<std::endl;
delete[]throw_5_dices;
delete[]throw_5_dice;
```
%% Cell type:code id: tags:
``` c++
#include<iostream>
Ndice=3;
int*throw_7_dices=throw_dice(Ndice);
int*throw_7_dice=throw_dice(Ndice);
for(std::size_ti=0;i<Ndice;++i)
std::cout<<throw_7_dices[i]<<std::endl;
std::cout<<throw_7_dice[i]<<std::endl;
delete[]throw_7_dices;
delete[]throw_7_dice;
```
%% Cell type:markdown id: tags:
Please notice that:
* No value can be assigned in construction: you must first allocate the memory for the array and only in a second time fill it.
* A `[]`**must** be added to the **delete** instruction to indicate to the compiler this is actually an array that is destroyed.
In fact, my advice would be to avoid entirely to deal directly with such arrays and use containers from the standard library such as `std::vector`:
%% Cell type:code id: tags:
``` c++
#include<vector>
{
std::vector<int>pi_first_five_digits{3,1,4,1,5};
}
```
%% Cell type:markdown id: tags:
that does the exact same job in a shorter way and is much more secure to use (spoiler: `std::vector` is built upon the RAII idiom mentioned briefly in this notebook).
We shall see `std::vector` more deeply [later](../5-UsefulConceptsAndSTL/3-Containers.ipynb) but will nonetheless use it before this as it is a rather elementary brick in most C++ codes.
