Commit 42a7dd32 authored by me's avatar me
Browse files

clarified some statements and improved styling

parent 39eb854b
......@@ -52,7 +52,7 @@ void Y <T1, T2>::print(TT);
\hspace*{-1cm}\begin{minipage}{1.1\linewidth}
\begin{lstlisting}[caption={typename als Hilfe zur Konfliktauflösung}, label=lst:typename_solves_conflicts]
\begin{lstlisting}[caption={\il{typename} als Hilfe zur Konfliktauflösung}, label=lst:typename_solves_conflicts]
template<typename T1> class X{
public:
// hier wüsste der Compiler nicht ob mem eine Member-Variable oder ein typedef ist. Dh. er weiß nicht ob das eine Multiplikation oder eine Referenz auf T::mem sein soll
......
......@@ -11,7 +11,7 @@ words.erase(endunique, words.end());
\begin{figure}[h!]
\begin{lstlisting}[caption={Parameter an eine Funktion mappen, Parameter sind call by value, sofern nicht using ref(arg) oder cref(arg) (für const ref) verwendet wird}, label=lst:bind]
\begin{lstlisting}[caption={Parameter an eine Funktion mappen, Parameter sind call by value, sofern nicht \il{using ref(arg)} oder \il{cref(arg)} (für const ref) verwendet wird}, label=lst:bind]
// syntax: auto newCallable = bind(callable, arg_list)
#include <functional> // std::ref
using namespace std::placeholders; // _1
......@@ -93,7 +93,7 @@ transform(vi.begin(), vi.end(), vi.begin(),
\begin{figure}[h!]
\begin{lstlisting}[caption={Vector-Dinge: fill, fill\_n, accumulate, copy}, label=lst:vector_stuff]
\begin{lstlisting}[caption={Vector-Dinge: \il{fill, fill_n, accumulate, copy}}, label=lst:vector_stuff]
vector<int> vec(10); // initialises to 0 per default
fill(vec.begin(), vec.end(), 1); // set all values to 1
......
......@@ -3,8 +3,8 @@
\begin{itemize}
\item Vorteil von Exception gegenüber Fehlercodes ist im Grunde die Trennung von Fehler-Auftreten und -Behandlung.
\item Im Destruktor sollten keine Exceptions geworfen werden, da sonst die Destruktoren, die diesen verwenden ihre exception-safety verlieren.
\item catch anything mit ``$\ldots$'': try{}catch(...){}
\item function-try-block: f(int i): g(i){}catch{}; Fängt auch den Aufruf der $g$-Funktion der Constructor-initialiser list ab.
\item catch anything mit \il{$\ldots$: try\{$\ldots$\}\ catch($\ldots$)\{\}}
\item function-try-block: \il{f(int i): g(i)\{\}\ catch\{\};} Fängt auch den Aufruf der \il{g}-Funktion der Constructor-initialiser list ab.
\end{itemize}
\inde{Exception Safe}{Programm verhält sich auch bei geworfenen Exceptions korrekt.}
......@@ -14,7 +14,7 @@
\begin{itemize}
\item Diese Garantien können mittels Objekten gegeben werden. Im Constructor werden Ressourcen angefordert und im Destructor wieder freigegeben.
\item f(new T1, new T2); kann zu einem Memory-Leak führen: Speicher für beide Objekte wird angefordert und beim erzeugen von T1 fällt eine Exception.\\
\item \il{f(new T1, new T2);} kann zu einem Memory-Leak führen: Speicher für beide Objekte wird angefordert und beim erzeugen von \il{T1} fällt eine Exception.\\
Also stattdessen: \cref{lst:shared_pointer_exception}
\end{itemize}
......@@ -38,18 +38,18 @@ template<typename T> T Stack<T>::pop(){
else{
// man verliert bei einem Fehler Elemente
T result = v[vused-1];
// ich weiß nicht genau wo hier eine Exception auftreten können sollte, aber ein underflow ist möglich, wodurch Objekte verloren werden können. Dies ist auch der allgemeine Gedanke hier: Fail nach dem decrease => Objekt nicht returnt, aber decreased.
// ich weiß nicht genau wo hier eine Exception auftreten können sollte, aber falls eine Exception nach dem decrease auftritt, so wird das Objekt nicht zurückgegeben, aber vused dennoch dekrementiert. => Objekt effektiv verloren
--vused;
return result;
}
}
// Also in einzelne Operationen spalten
template<typename T> T&Stack<T>::top(){
// Also in einzelne Operationen zerteilen
template<typename T> T& Stack<T>::top(){
if(!vused)
throw std::runtime_error("empty stack");
return v[vused -1];
return v[vused-1];
}
template<typename T> void Stack<T>::pop(){
......@@ -63,7 +63,7 @@ template<typename T> void Stack<T>::pop(){
\begin{figure}[h!]
\begin{lstlisting}[caption={[noexcept]noexcept\\Das Versprechen keine Exception zu werfen wird gebrochen. Das gibt trotzdem höchstens eine Compile-Warnung. Zur Laufzeit terminiert dies das Programm}, label=lst:noexcept]
\begin{lstlisting}[caption={[\il{noexcept}]\il{noexcept}\\Das Versprechen keine Exception zu werfen wird gebrochen. Zur Übersetzungszeit resultiert dies höchstens in einer Compile-Warnung. Zur Laufzeit terminiert dies das Programm}, label=lst:noexcept]
void f()noexcept{
throw exception();
}
......
\section{Lecture 12}
\begin{figure}[h!]
\begin{lstlisting}[caption={[tuple, tie, make\_tuple, ignore]tuple, tie, make\_tuple, ignore\\first bis fourth enthalten die einzelnen Tupel-Komponenten, a und b das zweite bzw. vierte. Ganz zum Schluss enthält first die 2. Das erste tie ist nicht Notwendig verdeutlicht aber dessen Funktionalität.},label=lst:tuple_and_tie]
\begin{lstlisting}[caption={[\il{tuple, tie, make_tuple, ignore}]\il{tuple, tie, make_tuple, ignore}\\\il{first} bis \il{fourth} enthalten die einzelnen Tupel-Komponenten, \il{a} und \il{b} das zweite bzw. vierte. Ganz zum Schluss enthält \il{first} den Wert 2. Das erste \il{tie} ist nicht Notwendig verdeutlicht aber dessen Funktionalität.},label=lst:tuple_and_tie]
int a, b;
int first, second, third, fourth;
auto tup3 = tie(first, second, third, fourth) = std::make_tuple(1001, 1002, 1003, 1004);
......@@ -39,29 +39,29 @@ while(itBegin != itEnd)
Eine nette Möglichkeit im 14er Standard zur Compile-Zeit die korrekte Funktion zu bestimmen sind restrictions und type traits.
Für Templates sollten nach Möglichkeit stets static\_assert s verwendet werden
Für Templates sollten nach Möglichkeit stets \il{static_assert}s verwendet werden
\begin{figure}[h!]
\begin{lstlisting}[caption={[lambda foo mit back\_inserter, partition\_copy, all\_of, none\_of, copy\_if]lambda foo mit back\_inserter, partition\_copy, all\_of, none\_of, copy\_if\\Kopiert alle ungeraden Elemente von myVec in allOdd und alle geraden in allEven.}, label=lst:lambda_foo_mit_back_inserter]
\begin{lstlisting}[caption={[lambda foo mit \il{back_inserter, partition_copy, all_of, none_of, copy_if}]lambda und \il{back_inserter, partition_copy, all_of, none_of, copy_if}\\Kopiert alle ungeraden Elemente von \il{myVec} in \il{allOdd} und alle geraden in \il{allEven}.}, label=lst:lambda_foo_mit_back_inserter]
list<int> allOdd;
deque<int> allEven;
vector<int> myVec = ...;
// odd ints to list allOdd and even ints to deque allEven
partition_copy(myVec.begin(), myVec.end(),
back_inserter(allOdd), back_inserter(allEven),
[](int i){return i % 2;});
back_inserter(allOdd), back_inserter(allEven),
[](int i){return i<@\%@>2;});
// weitere funktionen
// true falls alle Elemente ungerade
bool b = all_of(myVec.begin(), myVec.end(),
[](int i){return i%2;});
[](int i){return i<@\%@>2;});
// true falls alle Elemente gerade
bool c = none_of(myVec.begin(),myVec.end(),
[](int i){return i%2;});
[](int i){return i<@\%@>2;});
// kopiert alle ungeraden Elemente nach cout
copy_if(myVec.begin(), myVec.end(),
ostream_iterator<int>(cout, " "), [](int i) {return i%2;});
// })})})}) <- fix vim-hightlighting
ostream_iterator<int>(cout, " "),
[](int i) {return i<@\%@>2;});
\end{lstlisting}
\end{figure}
......@@ -14,7 +14,7 @@ struct Expression{
};
// functor for Constant_1 expression
struct Constant_1 : Expression{
Constant_1 (const double& d): d_(d){}
Constant_1 (const double &d): d_(d){}
double operator()(double){ return d_; }
const double d_;
......@@ -33,7 +33,7 @@ struct ComplexExpression : Expression{
Expression *l_;
Expression *r_;
ComplexExpression(Expression& l, Expression& r) : l_(l.clone()), r_(r.clone()){}
ComplexExpression(Expression &l, Expression &r) : l_(l.clone()), r_(r.clone()){}
~ComplexExpression(){ delete l_; delete r_; }
double operator()(double d){
......@@ -52,7 +52,7 @@ struct ExpressionRef{
~ExpressionRef(){
if(--ref_cnt_ == 0){
delete sp_;
sp_ = 0;
sp_ = nullptr;
}
}
......@@ -64,7 +64,7 @@ struct ExpressionRef{
if(this != &rhs){
if(--ref_cnt_ <= 0){
delete sp_;
sp_ = 0;
sp_ = nullptr;
}
sp_ = rhs.sp_;
++ref_cnt_;
......@@ -103,7 +103,7 @@ private:
\begin{lstlisting}[caption={[Erweiterung2 zu \cref{lst:expression_functor,lst:extension_expression_functor}, run-time]Erweiterung2 zu \cref{lst:expression_functor,lst:extension_expression_functor}, run-time},label=lst:extension2_expression_functor]
// integration function (average of upper bound and lower bound sums)
template<class Func>
double integrate(Func f, double low, double high, double epsilon = 0.001){
double integrate(Func f, double low, double high, double epsilon=0.001){
assert(low <= high);
double auc1 = 0, auc2 = 0;
double running_x = low;
......@@ -222,18 +222,18 @@ integrate(y*y, 0, 7);
\begin{itemize}
\item push\_back konstante Zeit-Komplexität, wohingegen vector::insert lineare hat
\item \il{push_back} konstante Zeit-Komplexität, wohingegen \il{vector::insert} lineare hat
\item niemals mehrere Dinge in einem Statement allozieren (Exceptions)
\item ValueClass - sollte vorweisen: Copy-controll, keine Baseklasse sein und keine virtual functions, Verwendung auf dem Stack oder in anderen Klassen
\item BaseClass - virtual destructor, nonpublic copy-controll, virtual functions, Verwaltung dynamisch auf dem Heap. Verwendet mittels smart-Pointer in Form eines Objekts der abgeleiteten Klasse.
\item TraitsClass - Templates, die Type-Informationen mit sich führen, ausschließlich typedefs und static functions, keine veränderbaren Status oder virtuals, keine Instantiierung
\item PolicyClass - Fragmente in Form von Templates, keine Instantiierung
\item ExceptionClass - ungewöhnlicher Mix von Value und reference-Semantiken, thrown by value sollte von caught by reference aufgefangen werden, no-fail constructors, virtuelle Funktionen, erbt häufig virtuell von std::exception
\item \textit{ValueClass} - sollte vorweisen: Copy-controll, keine Baseklasse sein und keine virtual functions, Verwendung auf dem Stack oder in anderen Klassen
\item \textit{BaseClass} - virtual destructor, nonpublic copy-controll, virtual functions, Verwaltung dynamisch auf dem Heap. Verwendet mittels smart-Pointer in Form eines Objekts der abgeleiteten Klasse.
\item \textit{TraitsClass} - Templates, die Type-Informationen mit sich führen, ausschließlich typedefs und static functions, keine veränderbaren Status oder virtuals, keine Instantiierung
\item \textit{PolicyClass} - Fragmente in Form von Templates, keine Instantiierung
\item \textit{ExceptionClass} - ungewöhnlicher Mix von Value und reference-Semantiken, thrown by value sollte von caught by reference aufgefangen werden, no-fail constructors, virtuelle Funktionen, erbt häufig virtuell von std::exception
\item Composition sollte tight coupling (friend function, ...) vorgezogen werden, da dies bei Vererbungen besser ist
\item private Members sind ``nicht zugreifbar'', nicht jedoch ``unsichtbar'', dies kann mittels Pimpl idiom erreicht werden, was für Information-Hiding und Compiler-Grenzen sorgt. Versteckt hinter opaque pointer (optimalerweise smart pointer)\\
Kann buildtime verringern, vermeidet ambiguity, Beispiel \cref{lst:pimpl}
\item dynamic polymorphism - static type checking, dynamic binding, separate compilation
\item static polymorphism - static type checking, static binding, verschiedene Typen, compile-time evaluation $\rightarrow$ Optimierungen
\item \textit{dynamic polymorphism} - static type checking, dynamic binding, separate compilation
\item \textit{static polymorphism} - static type checking, static binding, verschiedene Typen, compile-time evaluation $\rightarrow$ Optimierungen
\end{itemize}
\begin{figure}[h!]
......
......@@ -2,14 +2,14 @@
\begin{itemize}
\item condition variable erlaubt Kommunikation mehrerer Prozesse mithilfe von Mutexen.
\item std::shared\_future ist wie std::future, aber zusätzlich können mehrere Threads auf den selben Zustand warten
\item Threads können sogar geswaped werden, warum auch immer man das tun wollte
\item aktueller Thread: std::this\_thread
\item \il{std::shared_future} ist wie \il{std::future}, aber zusätzlich können mehrere Threads auf den selben Zustand warten
\item Threads können sogar ausgetauscht(swap) werden, warum auch immer man das tun wollte
\item aktueller Thread: \il{std::this_thread}
\end{itemize}
\begin{figure}[h!]
\begin{lstlisting}[caption={[async n stuff]async - erlaubt keine Kommunikation über mehrere Prozesse}, label=lst:async]
\begin{lstlisting}[caption={[\il{async} n stuff]\il{async} - erlaubt keine Kommunikation über mehrere Prozesse}, label=lst:async]
int calculate(){ return 42; }
// startet Ausführung sofort
auto future = async(launch::async, calculate, <parameter>);
......@@ -28,12 +28,12 @@ atomic<int> counter(0);
\begin{itemize}
\item lock\_guard: Verwendet mutex, lock im constructor, free im destructor. Ist schneller als unique\_lock
\item unique\_lock: genauso, aber kann auch später gelockt, unlocked und verschoben werden. Das ist notwendig wenn es sie condition variablen verwendet werden. Ist flexibler als lock\_guard
\item \il{lock_guard}: Verwendet \il{mutex, lock} im Konstruktor, \il{free} im Destruktor. Ist schneller als \il{unique_lock}
\item \il{unique_lock}: genauso, aber kann auch später gelockt, unlocked und verschoben werden. Das ist notwendig wenn condition variablen verwendet werden. Ist flexibler als \il{lock_guard}
\end{itemize}
\begin{figure}[h!]
\begin{lstlisting}[caption={[unique\_lock]unique\_lock}, label=lst:unique_lock]
\begin{lstlisting}[caption={[\il{unique_lock}]\il{unique_lock}}, label=lst:unique_lock]
std::unique_lock<std::mutex>guard1(<someMutex1>, std::defer_lock);
std::unique_lock<std::mutex>guard2(<someMutex2>, std::defer_lock);
// lockt beide gleichzeitig
......
......@@ -39,7 +39,7 @@ double dval = 3.14; int const &ri = dval;
\end{itemize}
\begin{figure}[h!]
\begin{lstlisting}[caption={decltype},label=lst:decltype]
\begin{lstlisting}[caption={\il{decltype}},label=lst:decltype]
// x und y vom selben Typ
type x; decltype(x) y;
......
......@@ -12,7 +12,7 @@ C++: \il{void f(initializer\_list<string> il)}
\end{itemize}
\begin{figure}[h!]
\begin{lstlisting}[caption={arrPtr und arrRef},label=lst:arrPtr_and_arrRef]
\begin{lstlisting}[caption={\il{arrPtr} und \il{arrRef}},label=lst:arrPtr_and_arrRef]
// pointer to an array of 5 ints
int (*arrP)[5] = arrPtr();
// reference to an array of 5 ints
......
......@@ -167,6 +167,7 @@
showspaces=false,
showstringspaces=false,
language=C++,
escapeinside={<@}{@>},
literate=%
{Ö}{{\"O}}1
{Ä}{{\"A}}1
......@@ -274,8 +275,8 @@
\pagebreak
\section{\listfigurename}
\listoffigures
\section{\listtablename}
\listoftables
%\section{\listtablename}
%\listoftables
\pagebreak
\section{Listingverzeichnis}
\listoflistings
......
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment