From d1377c38383d7f4baf355a0e13908db640737e91 Mon Sep 17 00:00:00 2001
From: Houtan Bastani <houtan@dynare.org>
Date: Mon, 30 Jan 2017 15:40:39 +0100
Subject: [PATCH] preprocessor: remove introduction to C++ programming
---
preprocessor.tex | 448 -----------------------------------------------
1 file changed, 448 deletions(-)
diff --git a/preprocessor.tex b/preprocessor.tex
index 3eed8568..fbe62c0b 100644
--- a/preprocessor.tex
+++ b/preprocessor.tex
@@ -56,454 +56,6 @@
\tableofcontents
\end{frame}
-\section{Introduction to object-oriented programming in C++}
-
-\begin{frame}
- \frametitle{Object-oriented programming (OOP)}
- \begin{itemize}
- \item Traditional way of programming: a program is a list of instructions (organized in functions) which manipulate data
- \item OOP is an alternative programming paradigm that uses \alert{objects} and their interactions to design programs
- \pause
- \item With OOP, programming becomes a kind of modelization: each object of the program should modelize a real world object, or a mathematical object (\textit{e.g.} a matrix, an equation, a model...)
- \item Each object can be viewed as an independent little machine with a distinct role or responsibility
- \item Each object is capable of receiving messages, processing data, and sending messages to other objects
- \pause
- \item Main advantage of OOP is \alert{modularity}, which leads to greater reusability, flexibility and maintainability
- \end{itemize}
-\end{frame}
-
-\begin{frame}
- \frametitle{Object}
- \framesubtitle{Definition and example}
- \begin{itemize}
- \item An \alert{object} is the bundle of:
- \begin{itemize}
- \item several variables (called its \alert{attributes}), which modelize the characteristics (or the state) of the object
- \item several functions (called its \alert{methods}) which operate on the attributes, and which modelize the behaviour of the object (the actions it can perform)
- \end{itemize}
- \pause
- \item Example: suppose we want to modelize a coffee machine
- \begin{itemize}
- \item The coffee machine (in real life) is a box, with an internal counter for the credit balance, a slot to put coins in, and a button to get a coffee
- \item The corresponding object will have one attribute (the current credit balance) and two methods (one which modelizes the introduction of money, and the other the making of a coffee)
- \end{itemize}
- \end{itemize}
-\end{frame}
-
-\begin{frame}[fragile]
- \frametitle{A coffee machine}
- \framesubtitle{Class definition}
- \begin{block}{C++ header file (\texttt{CoffeeMachine.hh})}
- \begin{scriptsize}
-\begin{verbatim}
-class CoffeeMachine {
-public:
- int credit;
- CoffeeMachine();
- void put_coin(int coin_value);
- void get_coffee();
-};
-\end{verbatim}
- \end{scriptsize}
- \end{block}
- \begin{itemize}
- \item A \alert{class} is a template (or a blueprint) of an object
- \item Collectively, the attributes and methods defined by a class are called \alert{members}
- \item A class definition creates a new \alert{type} (\texttt{CoffeeMachine}) that can be used like other C++ types (\textit{e.g.} \texttt{int}, \texttt{string}, ...)
- \item In C++, class definitions are put in header files (\texttt{.hh} extension)
- \end{itemize}
-\end{frame}
-
-\begin{frame}[fragile]
- \frametitle{A coffee machine}
- \framesubtitle{Method bodies}
- \begin{block}{C++ source file (\texttt{CoffeeMachine.cc})}
- \begin{scriptsize}
-\begin{verbatim}
-void CoffeeMachine::put_coin(int coin_value)
-{
- credit += coin_value;
- cout << "Credit is now " << credit << endl;
-}
-
-void CoffeeMachine::get_coffee()
-{
- if (credit == 0)
- cout << "No credit!" << endl;
- else {
- credit--;
- cout << "Your coffee is ready, credit is now " << credit << endl;
- }
-}
-\end{verbatim}
- \end{scriptsize}
- \end{block}
- \begin{itemize}
- \item Methods can refer to other members (here the two methods modify the \texttt{credit} attribute)
- \item Method bodies are put in source files (\texttt{.cc} extension)
- \end{itemize}
-\end{frame}
-
-\begin{frame}[fragile]
- \frametitle{Constructors and destructors}
- \begin{itemize}
- \item In our class header, there is a special method called \texttt{CoffeeMachine()} (same name than the class)
- \item It is a \alert{constructor}: called when the object is created, used to initalize the attributes of the class
- \end{itemize}
- \begin{block}{C++ source file (\texttt{CoffeeMachine.cc}, continued)}
- \begin{scriptsize}
-\begin{verbatim}
-CoffeeMachine::CoffeeMachine()
-{
- credit = 0;
-}
-\end{verbatim}
- \end{scriptsize}
- \end{block}
- \begin{itemize}
- \item It is possible to create constructors with arguments
- \item It is also possible to define a \alert{destructor} (method name is the class name prepended by a tilde, like \texttt{$\sim$CoffeeMachine}): called when the object is destroyed, used to do cleaning tasks (\textit{e.g.} freeing memory)
- \end{itemize}
-\end{frame}
-
-
-\begin{frame}[fragile]
- \frametitle{Instantiation and method invocation}
- \begin{block}{Program main function}
- \begin{scriptsize}
-\begin{verbatim}
-#include "CoffeeMachine.hh"
-
-int main()
-{
- CoffeeMachine A, B;
-
- A.put_coin(2);
- A.get_coffee();
-
- B.put_coin(1);
- B.get_coffee();
- B.get_coffee();
-}
-\end{verbatim}
- \end{scriptsize}
- \end{block}
- \begin{itemize}
- \item Creates two machines: at the end, \texttt{A} has 1 credit, \texttt{B} has no credit and refused last coffee
- \item \texttt{A} and \texttt{B} are called \alert{instances} of class \texttt{CoffeeMachine}
- \item Methods are invoked by appending a dot and the method name to the instance variable name
- \end{itemize}
-\end{frame}
-
-\begin{frame}[fragile]
- \frametitle{Dynamic instantiation with \texttt{new}}
- \begin{block}{Program main function}
- \begin{scriptsize}
-\begin{verbatim}
-#include "CoffeeMachine.hh"
-
-void main()
-{
- CoffeeMachine *A;
-
- A = new CoffeeMachine();
-
- A->put_coin(2);
- A->get_coffee();
-
- delete A;
-}
-\end{verbatim}
- \end{scriptsize}
- \end{block}
- \begin{itemize}
- \item Here \texttt{A} is a pointer to an instance of class \texttt{CoffeeMachine}
- \item Dynamic creation of instances is done with \texttt{new}, dynamic deletion with \texttt{delete} (analogous to \texttt{malloc} and \texttt{free})
- \item Since \texttt{A} is a pointer, methods are called with \texttt{->} instead of a dot
- \end{itemize}
-\end{frame}
-
-\begin{frame}[fragile]
- \frametitle{Access modifiers}
- \begin{itemize}
- \item In our coffee machine example, all attributes and methods were marked as \texttt{public}
- \item Means that those attributes and methods can be accessed from anywhere in the program
- \item Here, one can gain credit without putting money in the machine, with something like \texttt{A.credit = 1000;}
- \item The solution is to declare it \alert{private}: such members can only be accessed from methods within the class
- \end{itemize}
- \begin{block}{C++ header file (\texttt{CoffeeMachine.hh})}
- \begin{scriptsize}
-\begin{verbatim}
-class CoffeeMachine {
-private:
- int credit;
-public:
- CoffeeMachine();
- void put_coin(int coin_value);
- void get_coffee();
-};
-\end{verbatim}
- \end{scriptsize}
- \end{block}
-\end{frame}
-
-\begin{frame}
- \frametitle{Interface}
- \begin{itemize}
- \item The public members of a class form its \alert{interface}: they describe how the class interacts with its environment
- \item Seen from outside, an object is a ``black box'', receiving and sending messages through its interface
- \item Particular attention should be given to the interface design: an external programmer should be able to work with an class by only studying its interface, but not its internals
- \item A good design pratice is to limit the set of public members to the strict minimum:
- \begin{itemize}
- \item enhances code understandability by making clear the interface
- \item limits the risk that an internal change in the object requires a change in the rest of the program: \alert{loose coupling}
- \item prevents the disruption of the coherence of the object by an external action: principle of \alert{isolation}
- \end{itemize}
- \end{itemize}
-\end{frame}
-
-\begin{frame}
- \frametitle{Why isolation is important}
- \begin{itemize}
- \item Consider a class \texttt{Circle} with the following attributes:
- \begin{itemize}
- \item coordinates of the center
- \item radius
- \item surface
- \end{itemize}
- \item If all members are public, it is possible to modify the radius but not the surface, therefore disrupting internal coherence
- \item The solution is to make radius and surface private, and to create a public method \texttt{changeRadius} which modifies both simultaneously
- \item \textit{Conclusion:} Creating a clear interface and isolating the rest diminishes the risk of introducing bugs
- \end{itemize}
-\end{frame}
-
-\begin{frame}[fragile]
- \frametitle{Inheritance (1/2)}
-
- \begin{block}{Matrices and positive definite matrices}
- \begin{scriptsize}
- \begin{columns}[t]
- \begin{column}{4.8cm}
-\begin{verbatim}
-class Matrix
-{
-protected:
- int height, width;
- double[] elements;
-public:
- Matrix(int n, int p,
- double[] e);
- virtual ~Matrix();
- double det();
-};
-\end{verbatim}
- \end{column}
- \begin{column}{6cm}
-\begin{verbatim}
-class PositDefMatrix : public Matrix
-{
-public:
- PositDefMatrix(int n, int p,
- double[] e);
- Matrix cholesky();
-};
-\end{verbatim}
- \end{column}
- \end{columns}
- \end{scriptsize}
-
- \end{block}
- \begin{itemize}
- \item \texttt{PositDefMatrix} is a \alert{subclass} (or \alert{derived class}) of \texttt{Matrix}
- \item Conversely \texttt{Matrix} is the \alert{superclass} of \texttt{PositDefMatrix}
- \end{itemize}
-\end{frame}
-
-\begin{frame}
- \frametitle{Inheritance (2/2)}
- \begin{itemize}
- \item \texttt{PositDefMatrix} inherits \texttt{width}, \texttt{height}, \texttt{elements} and \texttt{det} from \texttt{Matrix}
- \item Method \texttt{cholesky} can be called on an instance of \texttt{PositDefMatrix}, but not of \texttt{Matrix}
- \item The keyword \texttt{protected} means: public for subclasses, but private for other classes
- \item \alert{Type casts} are legal when going upward in the derivation tree:
- \begin{itemize}
- \item a pointer to \texttt{PositDefMatrix} can be safely cast to a \texttt{Matrix*}
- \item the converse is faulty and leads to unpredictable results
- \end{itemize}
- \end{itemize}
-\end{frame}
-
-\begin{frame}[fragile]
- \frametitle{Constructors and destructors (bis)}
- \begin{block}{C++ code snippet}
- \begin{scriptsize}
-\begin{verbatim}
-Matrix::Matrix(int n, int p, double[] e) : height(n), width(p)
-{
- elements = new double[n*p];
- memcpy(elements, e, n*p*sizeof(double));
-}
-
-Matrix::~Matrix()
-{
- delete[] elements;
-}
-
-PositDefMatrix::PositDefMatrix(int n, int p, double[] e) :
- Matrix(n, p, e)
-{
- // Check that matrix is really positive definite
-}
-\end{verbatim}
- \end{scriptsize}
- \end{block}
- \begin{itemize}
- \item Constructor of \texttt{PositDefMatrix} calls constructor of \texttt{Matrix}
- \item Note the abbreviated syntax with colon
- \end{itemize}
-\end{frame}
-
-\begin{frame}
- \frametitle{Possible derivation tree for real matrices}
- \framesubtitle{Arrow means \textit{...is a subclass of...}}
- \begin{center}
- \includegraphics[width=10cm]{matrices.png}
- \end{center}
-\end{frame}
-
-\begin{frame}
- \frametitle{Polymorphism (1/3)}
- \begin{itemize}
- \item In previous example, determinant computation method uses the same algorithm for both classes
- \item But for positive definite matrices, a faster algorithm exists (using the cholesky)
- \item \alert{Polymorphism} offers an elegant solution:
- \begin{itemize}
- \item declare \texttt{det} as a \alert{virtual method} in class \texttt{Matrix}
- \item \alert{override} it in \texttt{PositDefMatrix}, and provide the corresponding implementation
- \end{itemize}
- \item When method \texttt{det} will be invoked, the correct implementation will be selected, depending on the type of the instance (this is done through a runtime type test)
- \end{itemize}
-\end{frame}
-
-\begin{frame}[fragile]
- \frametitle{Polymorphism (2/3)}
-
- \begin{block}{Class headers}
- \begin{scriptsize}
- \begin{columns}[t]
- \begin{column}{4.8cm}
-\begin{verbatim}
-class Matrix
-{
-protected:
- int height, width;
- double[] elements;
-public:
- Matrix(int n, int p,
- double[] e);
- virtual ~Matrix();
- virtual double det();
- bool is_invertible();
-};
-\end{verbatim}
- \end{column}
- \begin{column}{6cm}
-\begin{verbatim}
-class PositDefMatrix : public Matrix
-{
-public:
- PositDefMatrix(int n, int p,
- double[] e);
- Matrix cholesky();
- virtual double det();
-};
-\end{verbatim}
- \end{column}
- \end{columns}
- \end{scriptsize}
-
- \end{block}
- \begin{itemize}
- \item Note the \texttt{virtual} keyword
- \item A method has been added to determine if matrix is invertible
- \end{itemize}
-\end{frame}
-
-\begin{frame}[fragile]
- \frametitle{Polymorphism (3/3)}
- \begin{block}{C++ code snippet}
- \begin{scriptsize}
-\begin{verbatim}
-bool Matrix::is_invertible()
-{
- return(det() != 0);
-}
-
-double PositDefMatrix::det()
-{
- // Square product of diagonal terms of cholesky decomposition
-}
-\end{verbatim}
- \end{scriptsize}
- \end{block}
- \begin{itemize}
- \item A call to \texttt{is\_invertible} on a instance of \texttt{Matrix} will use the generic determinant computation
- \item The same call on an instance of \texttt{PositDefMatrix} will call the specialized determinant computation
- \end{itemize}
-\end{frame}
-
-\begin{frame}
- \frametitle{Abstract classes}
- \begin{itemize}
- \item It is possible to create classes which don't provide an implementation for some virtual methods
- \item Syntax in the header: \\
- \texttt{virtual int method\_name() = 0;}
- \item As a consequence, such classes can never be instantiated
- \item Generally used as the root of a derivation tree, when classes of the tree share behaviours but not implementations
- \item Such classes are called \alert{abstract classes}
- \end{itemize}
-\end{frame}
-
-
-\begin{frame}
- \frametitle{Some programming rules (1/2)}
- \begin{itemize}
- \item Don't repeat yourself (DRY): if several functions contain similar portions of code, \alert{factorize} that code into a new function
- \begin{itemize}
- \item makes code shorter
- \item reduces the risk of introducing inconsistencies
- \item makes easier the propagation of enhancements and bug corrections
- \end{itemize}
- \item Make short functions
- \begin{itemize}
- \item often difficult to grasp what a long function does
- \item structuring the code by dividing it into short functions makes the logical structure more apparent
- \item enhances code readability and maintainability
- \end{itemize}
- \item Use explicit variable names (except for loop indexes)
- \end{itemize}
-\end{frame}
-
-\begin{frame}
- \frametitle{Some programming rules (2/2)}
- \begin{itemize}
- \item Global variables are evil
- \begin{itemize}
- \item a global variable can be modified from anywhere in the code (nonlocality problem)
- \item creates a potentially unlimited number of dependencies between all portions of the code
- \item makes bugs difficult to localize (any part of the code could have created the trouble)
- \item to summarize, goes against the principle of modularity
- \item in addition, global variables are not thread safe (unless used with locks/mutexes)
- \end{itemize}
- \item Document your code when it doesn't speak by itself
- \begin{itemize}
- \item Dynare preprocessor code is documented using Doxygen
- \item done through special comments beginning with an exclamation mark
- \item run \texttt{doxygen} from the source directory to create a bunch of HTML files documenting the code
- \end{itemize}
- \end{itemize}
-\end{frame}
-
\section{Parsing}
\begin{frame}
--
GitLab