C++Guns – RoboBlog blogging the bot

31.05.2019

Protected: Besuch von zwei Gänse

Filed under: Allgemein — Thomas @ 20:05

This content is password protected. To view it please enter your password below:

29.05.2019

Graph - Basic graph definitions

Filed under: Allgemein — Thomas @ 14:05

Shortcut links:
Basic graph definitions (this page)
Basics of shortest paths

Gerichtete und ungerichtete Graphen

  1. Ein gerichteter Graph 𝐺 = (𝑉, 𝐴) besteht aus einer endlichen Menge 𝑉 von Knoten und einem multiset 𝐴 von geordneten Paaren von Knoten. Die Elemente von 𝐴 sind die gerichteten Kanten von 𝐺.
  2. Ein ungerichteter Graph 𝐺 = (𝑉, 𝐸) besteht aus einer endlichen Menge 𝑉 von Knoten und ein multiset 𝐸 von ungeordneten Paaren von Knoten. Die Elemente von 𝐸 sind die ungerichteten Kanten von 𝐺.
  3. Ein gerichteter oder ungerichteter Graph ist simple (einfach), wenn:
    • Kein Knoten, in 𝐴 oder 𝐸, mit sich selbst verbunden ist
    • Die multisets 𝐴 oder 𝐸 sind nur sets
  4. Ein gerichteter Graph 𝐺 = (𝑉, 𝐴) ist
    • symmetrisch, wenn (𝑣,𝑤) ∈ 𝐴 impliziert (𝑤,𝑣) ∈ 𝐴
    • anti-symmetrisch, wenn (𝑣,𝑤) ∈ 𝐴 impliziert (𝑤,𝑣) ∉ 𝐴

Adjacency, incidence, degree (benachbart, verbunden, Grad)

  1. Zwei Knoten eines gerichteten oder ungerichteten Graphen heißen adjacent (benachbart), wenn sie mindestens eine gemeinsame Kante haben.
  2. Ein Knoten und eine Kante heißen incident (verbunden), wenn der Knoten zu der Kante gehört.
  3. Zwei Kanten heißen incident (verbunden), wenn sie mindestens einen gemeinsamen Knoten haben.
  4. Für einen Knoten, die Anzahl der incident (verbundenen) Kanten ist der Grad von diesem Knoten. Ein Knoten mit Grad 0 heißt isoloert.
  5. Betrachte einen gerichteten Graph 𝐺 = (𝑉, 𝐴):
    1. Für eine Kante 𝑎 = (𝑣,𝑤) ∈ 𝐴, 𝑣 ist der tail (Fuß,Startknoten) von 𝑎 und 𝑤 ist der head (Kopf/Endknoten) von 𝑎.
    2. Eine Kante 𝑎 = (𝑣,𝑤) ∈ 𝐴 ist eine outgoing (abgehende) Kante von 𝑣 und eine incoming (eingehende) Kante von 𝑤.
    3. outdegree von einem Knoten 𝑣 ∈ 𝑉 ist die Anzahl der abgehenden Kanten.
    4. indegree von einem Knoten 𝑣 ∈ 𝑉 ist die Anzahl der eingehenden Kanten.

Transpose of a graph

Für einen gerichteten Graph 𝐺 = (𝑉, 𝐴), die transpose (Vertauschung) von 𝐺 ist das Ergebnis vom Drehen aller Kanten von 𝐺. (Start- und Zielknoten tauschen)

Subgraph

  1. Gegeben sind zwei einfache, ungerichtete Graphen 𝐺1 = (𝑉1, 𝐸1) und 𝐺2 = (𝑉2, 𝐸2).
    Dann ist 𝐺1 ein subgraph von 𝐺2, wenn es eine Knotenteilmenge 𝑉' ⊆ 𝑉2 gibt und eine bijektive (umkehrbare) Funktion φ: 𝑉1 -> 𝑉' gibt, welche alle Knoten aus 𝑉1 auf die Teilmenge 𝑉' von 𝑉2 abbildet, und zwar genau so, dass eine Kante {𝑣,𝑤} aus 𝐸1 impliziert, dass es eine andere Kante {φ(𝑣),φ(𝑤)} ∈ 𝐸2 gibt.
    Denn es müssen nicht nur alle Knoten von 𝑉1 in 𝑉2 zu finden sein, sondern natürlich auch alle Kanten.
  2. Gegeben sind zwei einfache, gerichtete Graphen 𝐺1 = (𝑉1, 𝐴1) und 𝐺2 = (𝑉2, 𝐴2).
    Dann ist 𝐺1 ein subgraph von 𝐺2, wenn es eine Knotenteilmenge 𝑉' ⊆ 𝑉2 gibt und eine bijektive (umkehrbare) Funktion φ: 𝑉1 -> 𝑉' gibt, welche alle Knoten aus 𝑉1 auf die Teilmenge 𝑉' von 𝑉2 abbildet, und zwar genau so, dass eine Kante (𝑣,𝑤) aus 𝐴1 impliziert, dass es eine andere Kante (φ(𝑣),φ(𝑤)) ∈ 𝐴2 gibt.
    Quasi das selbst wie für ungerichtete Grapen.
  3. Ein spanning subgraph von einem ungerichteten oder gerichteten Graphen 𝐺 ist ein subgraph welcher alle Knoten von 𝐺 enthält.
    Aber nicht alle Kanten (es bildet sich ein Baum).

Paths

  1. Ein ordinary (gewönlicher) Path in einem ungerichteten Graphen ist eine endliche, geordnete Sequenz ({v1,v2}, {v2,v3}, ..., {vk-2, vk-1}, {vk-1,vk}) von Kanten.
  2. Ein ordinary (gewöhnlicher) Path in einem gerichteten Graphen ist eine endliche, geordnete Sequenz ((v1,v2), (v2,v3), ..., (vk-2, vk-1), (vk-1,vk)) von Kanten.
  3. Ein generalized a.k.a. weak (genereller, schwacher) Path in einem gerichteten Graphen ist eine endliche Sequenz ((v1,w1), (v2,w2), ..., (vk-1, wk-1), (vk,wk)), so dass drehen von einigen Kanten einen ordinary Path ergibt (Ein ordinary Path ist schon ein generalized Path bei dem keine Kanten gedreht werden müssen).
  4. Ein Path ist simple (einfach) wenn er keine Knoten doppelt enthält.
  5. Ein Knoten 𝑡 ∈ 𝑉 ist reachable (erreichbar) von 𝑠 ∈ 𝑉, wenn es einen Path von 𝑠 nach 𝑡 in dem Graph gibt.
    Abhängig vom Kontext, der Path muss ein ungerichteter, ein gewöhnlicher gerichteter, oder ein generalized Path sein.
    Jeder Knoten ist von sich selbst aus erreichbar, via den trivialen Path welcher nur diesen Knoten enthält und sonst keine Kanten.
  6. Die internal (internen) Knoten von einem Path jeglicher Art sind alle Knoten von diesem Path außer dem Start und Endknoten.
    (Wenn der Start oder Endknoten mehr als einmal im Path vorkommt, zählt es zu den internen Knoten)
  7. Zwei Pathe sind edge-disjoint (disjunkt) wenn sie keine gemeinsame Kante haben. Sie sind (internally) node-disjoint wenn sie keine gemeinsamen Knoten haben.

Cycles

  1. Ein (ordinaty/gewöhnlicher) cycle in einem ungerichteten Graphen ist eine endliche, geordnete Sequenz ({v1,v2}, {v2,v3}, ..., {vk-2, vk-1}, {vk-1, v1} ) von Kanten. In anderen Worten: Ein cycle ist ein Path, so dass der Startknoten gleich dem Endknoten ist.
  2. Ein (ordinaty/gewöhnlicher) cycle in einem gerichteten Graphen ist eine endliche, geordnete Sequenz ((v1,v2), (v2,v3), ..., (vk-2, vk-1), (vk-1, v1) ) von Kanten. In anderen Worten: Ein cycle ist ein Path, so dass der Startknoten gleich dem Endknoten ist.
  3. Ein generalized a.k.a. weak (genereller, schwacher) cycle in einem gerichteten Graphen ist eine endliche Sequenz ((v1,w1), (v2,w2), ..., (vk-1, wk-1), (vk,wk)), so dass drehen von einigen Kanten einen ordinary cycle ergibt (Ein ordinary cycle ist schon ein generalized cycle bei dem keine Kanten gedreht werden müssen).
  4. A cycle is simple if no proper part is a cycle of its own.
  5. Ein gerichteter oder ungerichteter Graph ist acyclic (cycle-free), wenn er kein ordinary cycle enthält. Ein gerichteten Graphen nennt man in diesem Fall DAG (directed acyclic graph).
  6. Für zwei Knoten 𝑠,𝑡 ∈ 𝑉, ein (s,t)-graph 𝐺 = (𝑉, 𝐴) ist ein DAG, so dass 𝑠 ist der einzige Knoten mit indegree 0, und 𝑡 ist der einzige Knoten mit outdegree 0.
    Ein DAG ist ein (s,t)-Graph , genau dann, wenn der Graph G die Vereinigung von (nicht notwenigerweise internally Knoten oder Kanten disjunkt) allen (s,t)-pathen ist.

Forests, trees, branchings, arborescences

  1. Ein forst ist ein cycle-free undirected Graph. Disconnected nicht vergessen sonst macht es kein Sinn.
    forest
  2. Ein tree ist ein conected forst. Also connected, cycle-free undirected Graph.
    tree
    Das ist nicht unbedingt das, was man von der Schule her noch kennt. In der Schule war ein tree immer ein directer Graph mit einem Wurzelknoten. Aber gut. Muss ja nicht.
  3. Ein branching ist ein cycle-free, directed Graph, so dass indregree für jeden Knoten 0 oder 1 ist. Das sieht gedanklich schon ehr wie ein Baum aus. Aber noch nicht ganz. Directed muss sein, klar. Sonst könnte man seine "Entscheidungen" beim "branchen" ja zurück nehmen.
  4. Eine arborescene ist ein branching, so dass genau ein Knoten indegree 0 hat. Das nennt man auch rooted trees und der einzigartige Knoten mit indegree 0 ist root. DAS ist ein Baum.
  5. Ein forest/tree/branching/arborescence in einem Graphen G ist ein Subgraph von G welcher wiederrum ein forest/tree/branching/arborescence ist.
    Naja, auf dem zweiten Blick stimmt das. Jeden Subgraph den man aus einem Tree rausholt ist wieder ein Tree.

Connectedness

Types of connectedness:

    Types of connectedness:

  1. Ein ungerichteter Graph ist connected, wenn jedes mögliche Knotenpaar durch einen Path verbunden ist.
  2. Ein ungerichteter Graph ist k-connected, wenn jedes mögliche Knotenpaar mindestens durch k internally node-disjoint Pathe verbunden ist. Einfach nur connected ist 1-connected. k=2 ist biconnected.
  3. Ein directed Graph ist weakly connected, wenn für jeden Knotenpaar ein generalized path existiert welcher diese Knoten verbindet.
  4. Ein directed Graph ist strongly connected, wenn für jedes geordnerte Knotenpaar ein ordinary path den ersten mit den zweiten Knoten verbindet.
  5. Links:

  6. Ein articulation Knoten in einem connected undirected Graph ist so ein Knoten, dass wenn der Knoten (und die angeschlossenen Kanten) entfernt wird, der Graph disconnected wird.
  7. Eine bridge in einem connected undirected Graph ist eine Kante, so dass der Graph disconnected wird wenn diese Kante entfernt wird.
  8. Connected components:

  9. Die k-connected componenten von einem ungerichteten Graphen 𝐺 = (𝑉, 𝐸) ist die inclusion-maximal Knotenmengen 𝑉' ⊆ 𝑉, so dass der Subgraph von 𝐺, hergestellt von 𝑉', k-connected ist (d.h. wenn jedes mögliche Knotenpaar in V' mindestens durch k internally node-disjoint paths miteinander verbunden sind).
    For k=1 wir sagen connected und für k=2 wir sachen biconnected compoenten von G.
  10. Die weakly und strongly connecten componenten von einem directed Graph 𝐺 = (𝑉, 𝐴) sind die inclusion-maximal Knotenmengen 𝑉' ⊆ 𝑉, so dass der Subgraph von 𝐺 induced von 𝑉' ist weak und strong connected.

Bipartite and k-partite graphs

Sei 𝐺 = (𝑉, 𝐸) ein ungerichteter Graph.

  1. Der Graph 𝐺 ist 𝑘-partite, wenn es eine 𝑘-partition {𝑉1, ..., 𝑉k} von 𝑉 gibt, so dass {𝑣,𝑤} ∉ 𝐸 ist für jedes Paar 𝑣,𝑤 ∈ 𝑉i für jedes i ∈ {1,...,𝑘}.
  2. Für 𝑘=2 wir sagen 𝐺 ist bipartite.

Statement: Ein verbundener, ungerichteter Graph ist bipartite, genau dann wenn es kein Cycle von ungerade Länge gibt.
Das lässt sich leicht erkennen, wenn man die Knoten auf dem Path abwechseln V1 und dann V2 zuordnet. Bei ungeraden Längen sind die Knoten der letzten Kante bei immer aus V1 oder V2.

Complete graphs

  1. Für eine positive ganzzahlige Nummer 𝑛, der complet graph 𝐾𝑛 = (𝑉,𝐸) ist der einzigartige undirecte Graph, so dass |𝑉| = 𝑛 und alle (ungeordneten) Paaren of Knoten in 𝐸 sind. Das heisst jeder mit jedem. Dense.
  2. Für positive ganzzahlige Nummern 𝑚 und 𝑛, der complete bipartite graph 𝐾𝑚,𝑛 = (𝑉1 UNITED 𝑉2, 𝐸) ist der einzigartige undirecte graph, so dass |𝑉1| = 𝑚 und |𝑉2| = 𝑛 und jeder (ungeordnete) Pair {𝑣,𝑤} mit 𝑣 ∈ 𝑉1 und 𝑤 ∈ 𝑉2 in 𝐸 ist.
    Also jeder von dem einem mit jeder von dem anderen.

10.05.2019

C++ Guns: play with threads and future

Filed under: Allgemein — Tags: — Thomas @ 13:05

Um schnell zu testen ob ein Rechner erreichbar ist, kann man ihn pingen. Der ping timeout dauert aber gern mal eine Sekunde. Wenn 10 Rechner nicht erreichbar sind, wartet man auch 10 Sekunden auf das Programm. Statt potentiell nur eine Sekunde. Die ping Anweisung kann man gut parallel ausführen. Zeit für std::async und std::future

Hier mein Beispiel, mit etwas Spielwiese:

#include <cstdlib>
#include <iostream>
#include <future>
#include <thread>
#include <string_view>

auto status(std::string_view host) {
  auto command = "ping -W 1 -c 1 " + std::string(host) + " >/dev/null 2>&1";
  return std::pair{std::system(command.c_str()), host};
}

auto red() {
  return "\033[32m";
}

auto green() {
  return "\033[31m";
}

auto reset() {
  return "\033[0m";
}

std::ostream& operator <<(std::ostream& s, const std::pair<int, std::string_view> p) {
  s << p.second << " ";
  if(p.first == 0) {
      s << red() << "UP " << reset();
    } else {
      s << green() << "down " << reset();
    }
  return s;
}

int main() {
    std::future f01 = std::async(std::launch::async, status, "rechner01");
    std::future f02 = std::async(std::launch::async, status, "rechner02");
    std::future f03 = std::async(std::launch::async, status, "rechner03");
    // ... 
    f01.wait();
    f02.wait();
    f03.wait();
    // ...
    std::cout << f01.get() << f02.get() << f03.get() << "\n";

}

C++ Guns: C++20 class types in non-type template parameters

Filed under: Allgemein — Tags: — Thomas @ 12:05

Mit C++20 und GCC9 wir können als Template Parameter nun auch einfach eigenen Typen angeben. Ohne uns mit Workarounds herumschlagen zu müssen.

Ein einfaches Beispiel sollte es verdeutlichen

struct MyType {
    int value;
};

template<MyType x>
auto func2() {
  return x.value;
} 

auto func3() {
    func2<MyType{1}>();
    constexpr MyType x{2};
    return func2<x>();
}

01.05.2019

ACCU 2019 Videos

Filed under: Allgemein — Tags: — Thomas @ 19:05

very nice! So Zeug hab ich bei meiner BA gebracht
Optimising a small real-world C++ application - Hubert Matthews [ACCU 2019]

This is a hands-on demonstration of optimising a small real-world application written in C++. It shows how measurement tools such as strace, perf tools, valgrind and cachegrind on Linux can be used to find the hotspots in an application. It also demonstrates some common pitfalls and how to avoid them by using different algorithms or libraries.

Contracts sind die Zukunft. Anschauen!
Programming with Contracts in C++20 - Björn Fahller [ACCU 2019]

Design by Contract is a technique to clearly express which parts of a program has which responsibilities. In the case of bugs, contracts can mercilessly point a finger at the part that violated the contract. Contracts are coming as a language feature in C++20. I will show how they can make your interfaces clearer with regards to use, but also point out pitfalls and oddities in how contracts are handled in C++. Writing good contracts can be difficult. I intend to give you guidance in how to think when formulating contracts, and how to design your interfaces such that good contracts can be written, because contracts have effects on interface design.

Genau meine Rede!
Better embedded library interfaces with modern C++ - Wouter Van Ooijen [ACCU 2019]

Traditionally, embedded applications are written in C. Using C++ is often frowned upon, because it is assumed to be less efficient. This talk shows how the interface of a typical embedded library can be made safer and more user-friendly, without being less efficient. Starting from a C-style interface modern C++ features are applied, like namespace, enum class, overloading, default argument values, std::byte, std::array, and templates.

Interessant
Audio in standard C++ - Timur Doumler [ACCU 2019]

Today, almost every computer, tablet and phone comes with audio input and output. Computer games and many other kinds of applications would be unthinkable without sound. Yet, the C++ language has no notion of it. Literature on audio in C++ is sparse. For even the simplest possible audio functionality, programmers need to deal with a confusing landscape of complex platform-specific APIs and proprietary 3rd party libraries. But audio in C++ doesn’t have to be hard!

Wow! Details von einem Profi
How C++20 Can Simplify std::tuple - Alisdair Meredith [ACCU 2019]

std::tuple has been the source of many presentations over the years, as the library specification glosses over a variety of implementation pitfalls, while successive standards increase the complexity. C++20 finally provides a number of features that, when combined, can yield a much simpler solution, saving developers of generic wrapper types from layers of expert-only code. This talk will show how applying the new Concepts language feature, in conjunction with new attributes and some extended syntax, enable the delivery of an optimized high performance implementation that is almost as simple as just declaring a class with a few data members. No metaclasses required!

Wichtig.
Implementing Physical Units Library for C++ - Mateusz Pusz [ACCU 2019]
Das ist nicht der erste Versuch eine unit library zu erstellen. Aber der erste den ich kenne der C++20 integiert. Aber keiner schafft es so richtig zu einem zufriedenstellenden Ergebnis.

This talk will present the current state of my work on designing and implementing Physical Units Library for C++. I will present all the challenges, design tradeoffs, and potential solutions to those problems. During the lecture, we will also see how new C++20 features help to make the library interface easier to use, maintain, and extend. Among others, we will see how we can benefit from class types provided as non-type template parameters, how new class template argument deduction rules simplify the interfaces, and a full power of using concepts to constrain template types.

Sehr interessanter Vortrag - auch wenn ich kein Wort verstanden habe
Allocator-Aware (AA) Software - John Lakos [ACCU 2019]
Man sollte sich vorher das hier ansehen: Local (Arena) Memory Allocators Part 1 - John Lakos - Meeting C++ 2017
und dann diesen Vortrag Local (Arena) Allocators Part II - John Lakos - Meeting C++ 2017

The performance benefits of supplying local allocators are well-known and substantial [Lakos, ACCU’17]. Still, the real-world costs associated with orchestrating the integration of allocators throughout a code base, including training, supporting tools, enlarged interfaces (and contracts), and a heightened potential for inadvertent misuse cannot be ignored. Despite substantial upfront costs, when one considers collateral benefits for clients – such as rapid prototyping of alternative allocation strategies – the case for investing in a fully allocator-aware (AA) software infrastructure (SI) becomes even more compelling. Yet there remain many “concerns” based on hearsay or specious conjecture that is either overstated or incorrect.

Etwas trocken, aber es lohnt sich das mal zu lernen
Regular Types and Why Do I Care ? - Victor Ciura [ACCU 2019]

“Regular” is not exactly a new concept (pun intended). If we reflect back on STL and its design principles, as best described by Alexander Stepanov in his 1998 “Fundamentals of Generic Programming” paper or his lecture on this topic, from 2002, we see that regular types naturally appear as necessary foundational concepts in programming. Why do we need to bother with such taxonomies ? Well, the STL now informally assumes such properties about the types it deals with and imposes such conceptual requirements for its data structures and algorithms to work properly. The new Concepts Lite proposal (hopefully part of C++20) is based on precisely defined foundational concepts such as Semiregular, Regular, EqualityComparable, DefaultConstructible, LessThanComparable (strict weak ordering), etc. Formal specification of concepts is an ongoing effort in the ISO C++ Committee and these STL library concepts requirements are being refined as part of Ranges TS proposal (experimental/ranges/concepts). Recent STL additions such as string_view, tuple, reference_wrapper, as well as new incoming types for C++20 like std::span raise new questions regarding values types, reference types and non-owning “borrow” types. Designing and implementing regular types is crucial in everyday programing, not just library design. Properly constraining types and function prototypes will result in intuitive usage; conversely, breaking subtle contracts for functions and algorithms will result in unexpected behavior for the caller. This talk will explore the relation between Regular types (and other concepts) and STL containers & algorithms with examples, common pitfalls and guidance.

Ganz nett wenn man Zeit hat
How to Teach C++ and Influence a Generation - Christopher Di Bella [ACCU 2019]

Learning to correctly use C++ is not difficult: teaching proper C++ usage is where the challenge lies, and at some point in your career, you’ll need to teach someone something about C++. You may not be a university lecturer or on-site trainer, but you could find yourself helping a colleague with their problem, presenting at a lunch-time session, or even at a conference! Perhaps you are someone who contributes to the company style guide or 'Intro to Our Repo' manual.

Powered by WordPress