mikrocontroller.net

Forum: Compiler & IDEs Informationen zu C vs C++ / aka Futter für die Diskussion


Autor: Wilhelm M. (wimalopaan)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
Hallo zusammen!

der Titel sagt es schon: es geht um das (alte) Thema: C vs C++ für 
eingebettete Systeme / MCUs.

Ich mache hier einfach mal den Versuch, in diesem Thread eine Sammlung 
von wertvollen Links zu dem Thema zusammen zu stellen. In unser allem 
Interesse sollten wir in diesem Thread hier nicht diskutieren, sondern 
nur Informationen sammeln. Wenn jemand zu einem Aspekt diskutieren 
möchte, sollte er dafür einen neuen Thread eröffnen.

Gut, dann fange ich mal an mit ein paar Links, die in meinen bookmarks 
enthalten sind (die Reihenfolge ist keine Wertung):

http://www.springer.com/us/book/9783642429156

http://aristeia.com/TalkNotes/C++_Embedded_Deutsch.pdf

http://www.cprogramming.com/c++11/c++11-compile-ti...

http://codedive.pl/pl/speaker/speaker/scott-meyers...

http://codedive.pl/pl/speaker/speaker/bartosz-szur...

Youtube-Video "Objects? No Thanks! - Wouter van Ooijen @ Meeting C++ 2014"

Youtube-Video "Meeting C++ Lightning Talks - Odin Holmes - Modern special function register abstraction"

Youtube-Video "Understanding Compiler Optimization - Chandler Carruth - Opening Keynote Meeting C++ 2015"

https://www.gitbook.com/book/arobenko/bare_metal_cpp/details

http://files.meetup.com/10475902/TypeSystemIsYourF...

http://www.embedded.com/design/programming-languag...

Zugegeben: ich von von der C++-Fraktion ;-)

Request for more!

Autor: Carl D. (jcw2)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
More:
http://sbrc2010.inf.ufrgs.br/anais/data/pdf/wtr/st...

Dan Saks, CppCon2016: "if you argue, you loose!"
-> keiner der's nicht schon weiß, wird es glauben wollen.

Autor: Johannes S. (jojos)
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
wer soll denn das alles lesen? C++: nicht lange diskutieren, just do it 
und fertig.

Autor: Verschwender (Gast)
Datum:

Bewertung
-4 lesenswert
nicht lesenswert
Johannes S. schrieb:
> C++: nicht lange diskutieren, just
> do it
> und fertig.

Nach zwei Jahren C++ Studium und mit dickem MC zur Hand :)

Autor: A. K. (prx)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Verschwender schrieb:
> Nach zwei Jahren C++ Studium und mit dickem MC zur Hand :)

Zählt ein ATmega32 als "dick"? Ein RTOS ist auch noch mit im Spiel.

Autor: Tom (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Apropos "dick" und C++:

Jason Turner "Rich Code For Tiny Machines: A Simple Commodore 64 Game In 
C++17"
Youtube-Video "CppCon 2016: Jason Turner “Rich Code for Tiny Computers: A Simple Commodore 64 Game in C++17”"

BG, Tom

Autor: Wilhelm M. (wimalopaan)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Christopher J. (christopher_j23)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Bin auf eine recht interessante Bibliothek bzw. Framework für die 
Bare-Metal-Programmierung mit C++ gestoßen:
http://kvasir.io

Auf der Seite gibt es den Link zum Github-Repo sowie noch ein paar 
Youtube-Videos in denen das Framework vorgestellt wird.

Der Ansatz ist ähnlich dem was Wilhelm für AVR hier schonmal vorgestellt 
hatte, nutzt also vor allem Sprachmittel aus C++11 wie z.B. constexpr. 
"Gefüttert" wird das Framework direkt mit Registerdefinitionen aus den 
SVD-Dateien der Hersteller.

Ich persönlich würde mich (derzeit jedenfalls) zwar definitiv in der 
C-Ecke verorten aber vielleicht findet ja der ein oder andere seinen 
Gefallen daran. Ich finde es jedenfalls einen sehr interessanten Ansatz 
und bin gerade dabei mal ein bisschen damit herumzuspielen.

Autor: Vincent H. (vinci)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Wilhelm M. (wimalopaan)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Empfehlen möchte ich auch noch:

Youtube-Video "CppCon 2017: Walter E. Brown “Programming with C++ Constraints: Background, Utility, and Gotchas""

Ich nutze constraints in g++ schon seit geraumer Zeit und möchte diese 
feature nicht mehr missen: wesentlich(!) einfacher, leichter zu lesen 
und zu schreiben als SFINAE. Und: wir werden es definitiv in C++20 
offiziell haben (ggf. mit minimalen Änderungen) ...

Autor: Wilhelm M. (wimalopaan)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Und noch einer:

Youtube-Video "CppCon 2017: Stephen Dewhurst “Modern C++ Interfaces...""

Wobei man beachten sollte, dass die SFINAE Technik, die er hier 
anwendet, eigentlich schon wieder veraltet ist -> s.a. concepts. 
Trotzdem ist der Vortrag grundsätzlich interessant.

Autor: Vincent H. (vinci)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
Hier mal was ganz Spezielles an den Teil der ASM/C Fraktion, der glaubt 
er sei schlauer als der Compiler:

Youtube-Video "CppCon 2017: Matt Godbolt “What Has My Compiler Done for Me Lately? Unbolting the Compiler's Lid”"

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Vincent H. schrieb:
> der ASM/C Fraktion

Es geht halt nichts über ein gut gepflegtes Vorurteil – oder was soll
diese Bezeichnung sonst sein?

Autor: Raoul D. (raoul_d219)
Datum:

Bewertung
4 lesenswert
nicht lesenswert
Jörg W. schrieb:
> Vincent H. schrieb:
>> der ASM/C Fraktion
>
> Es geht halt nichts über ein gut gepflegtes Vorurteil – oder was soll
> diese Bezeichnung sonst sein?

Bitte keine persönlichen Abwertungen in diesem Thread: weder in die eine 
noch in die andere Richtung. Dafür gibt es schon genug andere ...
Der Admin mag gerne den letzten Beitrag ohne einen Link löschen.

: Bearbeitet durch User
Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Raoul D. schrieb:
> Dafür gibt es schon genug andere

Sehe ich auch so, daher meine Kritik an Vincents unsinnigem Vorurteil.

Autor: Wilhelm M. (wimalopaan)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Jörg W. schrieb:
> Raoul D. schrieb:
>> Dafür gibt es schon genug andere
>
> Sehe ich auch so, daher meine Kritik an Vincents unsinnigem Vorurteil.

Wer diese etwas augenzwinkernde Bemerkung als negatives Vorurteil 
wertet, fühlt sich wohl selbst ertappt. Also bitte Herr Moderator: 
löschen (inkl. dieses Posts)

Beitrag #5179535 wurde von einem Moderator gelöscht.
Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Wilhelm M. schrieb:
> augenzwinkernde Bemerkung

Augenzwinkernd?  Sorry, ich sehe da kein Augenzwinkern, sondern
höchstens Evangelismus rausgucken aus so einer Bemerkung.  Das ist
doch wie ein Mercedes-Fahrer, der LKW- und Fahrradfahrer in gleichem
Atemzug nennt, weil sie nicht in sein Weltbild passen, zumal sie
suggeriert, dass jemand nicht sowohl Fahrrad, LKW als auch Mercedes
fahren könnte.

> fühlt sich wohl selbst ertappt

Inwiefern?

Ob ich C++ mag, nicht mag, benutze oder nicht benutze hat damit herzlich
wenig zu tun.  (Wenn du hin und wieder mehr Beiträge von mir lesen
würdest, wüsstest du außerdem die Antwort darauf. ;-)

: Bearbeitet durch Moderator
Autor: temp (Gast)
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
Christopher J. schrieb:
> Bin auf eine recht interessante Bibliothek bzw. Framework für die
> Bare-Metal-Programmierung mit C++ gestoßen:
> http://kvasir.io

Wenn man sich die Beispiele in dieser Lib ansieht kann man den Eindruck 
kriegen hier mischen die Monitorhersteller mit. Jedenfalls braucht man 
für diesen Programmiersteil wohl einen 2m 8K Minitor um ein wenig Code 
auf den  Schirm zusammenhängend darzustellen...
Mag sein, dass C++ mit den ganzen neuen Erwiterungen eine tolle Sprache 
ist, aber verständlicher ist der Code auch nicht als Spagettiecode in C 
von vor 20 Jahren. Ich programmiere auch in C++ vermisse aber nichts was 
in C++11 oder C++17 hinzu gekommen ist.

Autor: Nop (Gast)
Datum:

Bewertung
8 lesenswert
nicht lesenswert
Mal was Generelles, die YT-Dokus sind eine Unart. Wir haben 
Schriftlichkeit erfunden, und das zu lesen ginge weitaus schneller, als 
einem sprechenden Kopf zuhören zu müssen. Wenn es dem sprechenden Kopf 
aber zu unwichtig war, es hinzuschreiben, sondern es primär um seine 
Selbstvermarktung ging, ist das für den Zuschauer auch verzichtbar.

Davon ab sind noch mehr, noch viel mehr und NOCH VIEL MEHR supertolle 
C++-Features generell absolut kein Überzeugungsmittel (im Gegenteil) für 
diejenigen, der C++ vor allem wegen des außer Kontrolle geratenen 
Sprachumfanges und den sich daraus ergebenden Folgen ablehnt. Daran 
ändern auch überflüssige Videodokus nichts.

Autor: jz23 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
temp schrieb:
> Ich programmiere auch in C++ vermisse aber nichts was
> in C++11 oder C++17 hinzu gekommen ist.

Schau dir mal range-based-for, auto und constexpr an. Das sind sehr sehr 
praktische Änderungen.

Autor: Vincent H. (vinci)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
Nop schrieb:
> Mal was Generelles, die YT-Dokus sind eine Unart. Wir haben
> Schriftlichkeit erfunden, und das zu lesen ginge weitaus schneller, als
> einem sprechenden Kopf zuhören zu müssen. Wenn es dem sprechenden Kopf
> aber zu unwichtig war, es hinzuschreiben, sondern es primär um seine
> Selbstvermarktung ging, ist das für den Zuschauer auch verzichtbar.
>
> Davon ab sind noch mehr, noch viel mehr und NOCH VIEL MEHR supertolle
> C++-Features generell absolut kein Überzeugungsmittel (im Gegenteil) für
> diejenigen, der C++ vor allem wegen des außer Kontrolle geratenen
> Sprachumfanges und den sich daraus ergebenden Folgen ablehnt. Daran
> ändern auch überflüssige Videodokus nichts.


Bin nicht sicher ob jemand der "Dokus" nicht von einer Konferenz 
unterscheiden kann überhaupt der "Schriftlichkeit" mächtig ist?

Aber ich gebs eh schon auf. Statt auf irgendeinen der Talks einzugehn 
postet man halt lieber Schwachfug, damit man sich nur ja nicht mit der 
Materie beschäftigen muss.

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vincent H. schrieb:
> Bin nicht sicher ob jemand der "Dokus" nicht von einer Konferenz
> unterscheiden kann überhaupt der "Schriftlichkeit" mächtig ist?

Wenn allerdings das erste, was auf einer Webseite zu sehen ist, ein
paar Konferenzvideos sind, eine Doku weit und breit nicht zu erkennen
ist, dann macht das schon stutzig.

Ich würde eine Webseite zum Thema jedenfalls so aufbauen, dass die
Leute die Doku finden (bzw. ich würde nicht nur, sondern ich habe es
in den Projekten, die ich betreue, auch so getan).

Gerade nochmal in deren Git-Repo nachgesehen: Tutorial "coming soon",
doc/ Verzeichnis besteht derzeit aus einigen Zeilen "lorem ipsum".

Autor: Wilhelm M. (wimalopaan)
Datum:

Bewertung
7 lesenswert
nicht lesenswert
Leute, was soll das?

Ich hatte diesen Thread eröffnet, um Lesern, die offen für neue Ideen 
sind, eine Sammlung von Informationsquellen zu bieten, damit diese sich 
nicht alles lebst ergooglen müssen. Die Intention war doch klar, oder? 
Und wer einen Aspekt diskutieren möchte, soll bitte dafür einen neuen 
Thread eröffnen, damit die Ursprungsquellen hier in der Flut von 
Beiträgen nicht untergehen.

Leider passiert hier aber gerade das, was leider in diesem Forum zu oft 
passiert: ohne etwas zum Thema beizutragen verteidigen einige mit 
offenem Messer ihre eigene Scholle, wobei weder der gute Wille zu 
erkennen ist, ggf. über die Fehler anderer hinweg zu sehen noch sich 
tatsächlich fundiert mit neuen Aspekten auseinander zu setzen oder 
anderen einfach mal zuzuhören, ohne gleich mit schwerem Geschütz zu 
antworten.

Wer über die Komplexität der Sprache C++ diskutieren möchte, kann das 
gerne ja in einem anderen Thread machen. Aber nicht hier. Wer neue 
Features grundsätzlich nicht ansehen und das gerne für alle begründen 
möchte, kann das auch in einem anderen Thread machen. Aber nicht hier.

Dieser Thread soll "Futter für die Diskussion" liefern, soll aber nicht 
Ort der Diskussion selbst sein. Und wer gleich bei einer flapsigen 
Bemerkung hoch geht wie ein HB-Männchen, hat sich in meinen Augen selbst 
disqualifiziert.

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Wilhelm M. schrieb:
> Ich hatte diesen Thread eröffnet, um Lesern, die offen für neue Ideen
> sind, eine Sammlung von Informationsquellen zu bieten, damit diese sich
> nicht alles lebst ergooglen müssen.

Das ist ja auch völlig OK (und du hast selbst viele Links beigetragen).

Wenn aber jemand einen Link zu einem möglicherweise interessanten
Projekt (wie kvasir.io) postet, dieses Projekt aber bislang außer ein
paar Konferenz-Vorträgen offensichtlich keinerlei Dokumentation hat,
dann sollte man das hier ebenfalls erwähnen dürfen, denn es macht es
potenziellen Nutzern nicht gerade leichter, die Nutzung in Erwägung
zu ziehen.

Autor: Rolf M. (rmagnus)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
temp schrieb:
> Wenn man sich die Beispiele in dieser Lib ansieht kann man den Eindruck
> kriegen hier mischen die Monitorhersteller mit. Jedenfalls braucht man
> für diesen Programmiersteil wohl einen 2m 8K Minitor um ein wenig Code
> auf den  Schirm zusammenhängend darzustellen...
> Mag sein, dass C++ mit den ganzen neuen Erwiterungen eine tolle Sprache
> ist, aber verständlicher ist der Code auch nicht als Spagettiecode in C
> von vor 20 Jahren. Ich programmiere auch in C++ vermisse aber nichts was
> in C++11 oder C++17 hinzu gekommen ist.

Gerade die Übersichtlichkeit und Größe des Code wurde durch die neueren 
C++-Versionen erheblich verbessert:
for (std::list<std::string>::const_iterator it = mylist.begin(); it != mylist.end(); ++it)
{
    std::cout << *it << '\n';
}
vs
for (const auto& elem : mylist)
{
    std::cout << elem << '\n';
}

: Bearbeitet durch User
Autor: H. S. (Gast)
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
Wilhelm M. schrieb:
> Wer über die Komplexität der Sprache C++ diskutieren möchte, k

Die Diskussionen sind dort die gleichen - Auseinandersetzungen zwischen 
Ideologen. Hier ist ja schon gemütlicher. Die Platformen sind ja auch 
kleiner. Vielleicht sind Microcontrollerentwickler auch irgendwie 
praktischer, als die Unix-BSD-CPP-Franktion, mit der Ich sonst so zu tun 
habe :D

Autor: Wilhelm M. (wimalopaan)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Dumdi D. (dumdidum)
Datum:

Bewertung
-4 lesenswert
nicht lesenswert
Rolf M. schrieb:
> for (const auto& elem : mylist)
> {
>     std::cout << elem << '\n';
> }

Ja, das ist besser. Hier gleich noch die Frage, ich brauch neben den 
Element noch den 'Index'. In Python loest man das mit enumerate. Was ist 
da der moderne C++ Weg? (Man koennt natuerlich ausserhalb der Schleife 
eine Variable deklarieren, null setzen und in der Schleife hochzaehlen, 
waere das die präferierte Lösung?)

Autor: Wilhelm M. (wimalopaan)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Dumdi D. schrieb:
> Rolf M. schrieb:
>> for (const auto& elem : mylist)
>> {
>>     std::cout << elem << '\n';
>> }
>
> Ja, das ist besser. Hier gleich noch die Frage, ich brauch neben den
> Element noch den 'Index'. In Python loest man das mit enumerate. Was ist
> da der moderne C++ Weg? (Man koennt natuerlich ausserhalb der Schleife
> eine Variable deklarieren, null setzen und in der Schleife hochzaehlen,
> waere das die präferierte Lösung?)

Könntet Ihr bitte die Diskussion zu einem Detailthema in einen eigenen 
Thread packen (s.o. erster Beitrag). Damit man den eigentlichen Inhalt 
in diesem Thread nicht aus den Augen verliert.

Autor: dumdidum (nicht angemeldet) (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Scott Meyers: Youtube-Video "Things that Matter - Scott Meyers | DConf2017"
Wer nicht den ganzen Talk sehen möchte, ich finde 41:00 bis 43:00 
erklärt einige Diskussionen.

Autor: mh (Gast)
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
dumdidum (nicht angemeldet) schrieb:
> z

dumdidum (nicht angemeldet) schrieb:
> Scott Meyers: Youtube-Video "Things that Matter - Scott Meyers |
> DConf2017"
> Wer nicht den ganzen Talk sehen möchte, ich finde 41:00 bis 43:00
> erklärt einige Diskussionen.

Ohne nochmal reingeguckt zu haben (hab das Video vor einigen Wochen 
gesehen) worum es in dem Abschnitt genau geht: Es ist erwähnenswert, 
dass es sich um DConf und nicht um CppCon handelt.

Autor: Mikro 7. (mikro77)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Guideline Support Library

https://github.com/Microsoft/GSL

Ich mag gsl::not_null.

dumdidum (nicht angemeldet) schrieb:
> Youtube-Video "Things that Matter - Scott Meyers DConf2017"

"Why is the C++ community having so much trouble?"
...
"Frankly, the standardization committee doesn't really care".

Und das von Scott Meyers! :-)

Beitrag #5191855 wurde von einem Moderator gelöscht.
Beitrag #5192302 wurde vom Autor gelöscht.
Beitrag #5192455 wurde von einem Moderator gelöscht.
Beitrag #5192508 wurde von einem Moderator gelöscht.
Autor: Wilhelm M. (wimalopaan)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Wilhelm M. (wimalopaan)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Type Punning wird ja hier im Forum auch oft diskutiert, dabei werden nur 
allzu oft die Unterschiede zwischen C und C++ ausser Acht gelassen (s.a. 
unions):

Youtube-Video "CppCon 2017: Scott Schurr “Type Punning in C++17: Avoiding Pun-defined Behavior”"

Autor: Vincent H. (vinci)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
Folgender Talk von Vinnie Falco zeigt wunderbar wie mächtig gutes Design 
in modernem C++ sein kann. Das ist insofern erfrischend, weil sich ein 
Großteil der Talks halt doch meist auf spezifische und sehr theoretische 
Themen bezieht und weniger auf "Problem X -> Lösung Y".

Youtube-Video "CppCon 2017: Vinnie Falco “Make Classes Great Again! (Using Concepts for Customization Points)”"

Autor: Sheeva P. (sheevaplug)
Datum:

Bewertung
-5 lesenswert
nicht lesenswert
Carl D. schrieb:
> More:
> http://sbrc2010.inf.ufrgs.br/anais/data/pdf/wtr/st...
>
> Dan Saks, CppCon2016: "if you argue, you loose!"
> -> keiner der's nicht schon weiß, wird es glauben wollen.

...wobei das Englische "to argue" nicht im Sinne von "argumentieren" 
oder "diskutieren" gemeint ist, sondern vielmehr "streiten" meint. Das 
ist ein kleiner, aber feiner Unterschied, der häufig zu 
Mißverständnissen führt.

Autor: Carl D. (jcw2)
Datum:

Bewertung
-5 lesenswert
nicht lesenswert
Sheeva P. schrieb:
> Carl D. schrieb:
>> More:
>> http://sbrc2010.inf.ufrgs.br/anais/data/pdf/wtr/st...
>>
>> Dan Saks, CppCon2016: "if you argue, you loose!"
>> -> keiner der's nicht schon weiß, wird es glauben wollen.
>
> ...wobei das Englische "to argue" nicht im Sinne von "argumentieren"
> oder "diskutieren" gemeint ist, sondern vielmehr "streiten" meint. Das
> ist ein kleiner, aber feiner Unterschied, der häufig zu
> Mißverständnissen führt.

Naja, hier ist jeder Versuch einer sachlichen Diskussion in der ein 
großes C und zwei Plusszeichen vorkommen, spätesten nach Auftauchen der 
"x-beliebig"-Hasser, ein Streit.

Autor: Sheeva P. (sheevaplug)
Datum:

Bewertung
-6 lesenswert
nicht lesenswert
Carl D. schrieb:
>>> Dan Saks, CppCon2016: "if you argue, you loose!"
>>> -> keiner der's nicht schon weiß, wird es glauben wollen.
>>
>> ...wobei das Englische "to argue" nicht im Sinne von "argumentieren"
>> oder "diskutieren" gemeint ist, sondern vielmehr "streiten" meint. Das
>> ist ein kleiner, aber feiner Unterschied, der häufig zu
>> Mißverständnissen führt.
>
> Naja, hier ist jeder Versuch einer sachlichen Diskussion in der ein
> großes C und zwei Plusszeichen vorkommen, spätesten nach Auftauchen der
> "x-beliebig"-Hasser, ein Streit.

Darauf hat sich Dan bei seiner Aussage aber nicht bezogen, würde ich 
vermuten.

Autor: Vincent H. (vinci)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Alfred Bratterud
“Delegate this! Designing with delegates in modern C++

Youtube-Video "CppCon 2017: Alfred Bratterud “Delegate this! Designing with delegates in modern C++”"

Recht langweiliger Talk über eine sehr nette Klasse. Die im Talk 
angesprochene Implementierung findet man im IncludeOS Repo hier:
https://github.com/hioa-cs/IncludeOS/blob/master/a...

Im Grunde verhält sich delegate wie std::function ohne jedoch jemals 
Speicher anzufordern. Damit erspart man sich unschöne Überraschungen 
wenn man zum Beispiel größere Lambda Objekte in einem function Objekt 
ablegen will, die größer sind als der von vornherein reservierte 
Speicherplatz.
std::array<size_t, 3> a1 { 1, 2, 3};

auto big_lambda = [=] () -> int
{
  trace_printf("big_lambda: ");
  return a1[0] + a1[1] + a1[2];
};

// allocates memory (@GCC 7.2 for a cortex M4 platform)
std::function<int()> stdf_big_lambda { big_lambda };


Delegate besitzt war auch eine vorab definierte Größe, die ist aber ein 
Template Parameter und lässt sich somit justieren. Passt das gewünschte 
Objekt nicht hinein, gibts gleich einen Compilezeit Fehler.
// use just enough memory to store "big_lambda"
auto del_big_lambda { delegate<int(), spec::inplace_triv, sizeof(big_lambda)>(big_lambda) };


Ebenfalls erwähnenswert ist, dass delegate 3x verschiedene 
Konfigurationen besitzt. Dies ist am 2. Template Parameter ersichtlich. 
Je nach benötigtem Verhalten lässt sich delegate als
- spec::pure (reiner function pointer)
- spec::inplace_triv (function object mit definierter Größe)
- spec::inplace (function object mit definierter Größe, kopierbar, 
Destruktor Unterstützung)
anlegen.


Nach meinen Benchmarks (GCC 7.2, -O2, Cortex M4) ist delegate für freie 
Funktionen etwa 3.5x, für Lambdas 1.75x schneller.


/edit
Die Default Größe von Delegate ist mit "sizeof(size_t) * 4" für die in 
diesem Forum am häufigsten verwendeten Platformen natürlich etwas groß 
gewählt... also aufpassen hier.

: Bearbeitet durch User
Autor: Wilhelm M. (wimalopaan)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Der Vortrag "constexpr all things" wurd zwar schon oben erwähnt, doch 
beim obigen Link ist leider der Vortrag verkürzt. Hier die lange 
Variante:

Youtube-Video "C++Now 2017: Ben Deane & Jason Turner "constexpr ALL the things!""

Dabei find ich die Stelle 1:34:45 mit der Bemerkung aus dem Auditorium 
sehr interessant. Das war die Motivation zu:

Beitrag "constexpr Argument-Wrapper"

(Der Beitrag aus dem Auditorium war wohl von

https://mpark.github.io/programming/2017/05/26/con...

)

: Bearbeitet durch User
Autor: Hans-Georg L. (h-g-l)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg W. schrieb:
> Wilhelm M. schrieb:
>> Ich hatte diesen Thread eröffnet, um Lesern, die offen für neue Ideen
>> sind, eine Sammlung von Informationsquellen zu bieten, damit diese sich
>> nicht alles lebst ergooglen müssen.
>
> Das ist ja auch völlig OK (und du hast selbst viele Links beigetragen).
>
> Wenn aber jemand einen Link zu einem möglicherweise interessanten
> Projekt (wie kvasir.io) postet, dieses Projekt aber bislang außer ein
> paar Konferenz-Vorträgen offensichtlich keinerlei Dokumentation hat,
> dann sollte man das hier ebenfalls erwähnen dürfen, denn es macht es
> potenziellen Nutzern nicht gerade leichter, die Nutzung in Erwägung
> zu ziehen.

Die "Dokumentation" zu Kvasir und mehr findet man auf Odin Holmes blog : 
http://odinthenerd.blogspot.de/

Der name KVasir ist etwas unglücklich gewählt weil der schon mehrfach, 
auch für C++, in Gebrauch ist.

Und nun noch ein paar Beiträge zur Sache:
Tutorials und Info zu C++ User-Treffen
http://www.wilkening-online.de/index.html

Und wer gerne ausführliche Dokumentation hätte:

Buch "Real-Time C++" ISBN 978-3-642-34687-3
von Christopher Kormanyos ist lesenswert.

Den Code gibt es hier : https://github.com/ckormanyos/real-time-cpp

: Bearbeitet durch User
Autor: Hans-Georg L. (h-g-l)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Kostenloses Buch über C++ Meta-Templates

http://www.oreilly.com/programming/free/practical-...

Autor: Arc N. (arc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Etwas OT und nicht mehr ganz neu (ein paar Tage alt)
ISO C++17 gibt's offiziell https://www.iso.org/standard/68564.html
Wem die Working Drafts als Diskussionsgrundlage reichen ;)
C++17 http://www.open-std.org/jtc1/sc22/wg21/docs/papers...
oder den aktuellen Stand von C++2x ansehen möchte:
https://github.com/cplusplus/draft

Autor: Jan K. (jan_k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen. War schonmal jmd auf der emBO in Bochum 
(https://www.embo.io/#about)? Findet im März wieder statt.
Wird unter anderem von Odin Holmes gehostet. Voll interessant, dass der 
in Bochum ansässig ist, ist ganz in der Nähe.
Ich bin eigentlich klassischer C embedded Entwickler,  habe aber bei 
meiner Firma etwas Raum zum evaluieren von "zukünftigen" (bzw sinnvoll 
nutzbaren) Technologien, aber noch nicht besonders bewandert was C++ 
angeht. Lohnt die Konferenz?

Autor: Thomas W. (thomas_v2)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
Vincent H. schrieb:
> std::array<size_t, 3> a1 { 1, 2, 3};
>
> auto big_lambda = [=] () -> int

Und da sage noch einer Perl wäre die unleserlichste 
Programmiersprache...

Das gute an C++ ist, man kann auch programmieren ohne dass der Code so 
aussieht.

Das negative an C++ ist, dass sowas erlaubt ist.

Das gute an C ist, dass sowas nicht möglich ist.

Autor: Lernunfauler (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Thomas W. schrieb:
> Vincent H. schrieb:
>> std::array<size_t, 3> a1 { 1, 2, 3};
>>
>> auto big_lambda = [=] () -> int
>
> Und da sage noch einer Perl wäre die unleserlichste
> Programmiersprache...
>
> Das gute an C++ ist, man kann auch programmieren ohne dass der Code so
> aussieht.
>
> Das negative an C++ ist, dass sowas erlaubt ist.
>
> Das gute an C ist, dass sowas nicht möglich ist.

Das schöne an C++ ist, man muß es nicht nutzen, wenn man es nicht lernen 
will. Immer wieder schön anzusehen, wie man dann versucht umständlich 
mit C zu bauen, was in C++ ganz einfach geht.

Autor: S. R. (svenska)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Lernunfauler schrieb:
> Das schöne an C++ ist, man muß es nicht nutzen,
> wenn man es nicht lernen will.

Und das allerschönste ist, dass man dann den Code nicht lesen kann, den 
man maintainen muss, weil einer der früheren Autoren es lernen und üben 
wollte.

Autor: Nop (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
S. R. schrieb:

> Und das allerschönste ist, dass man dann den Code nicht lesen kann, den
> man maintainen muss, weil einer der früheren Autoren es lernen und üben
> wollte.

Das ist ein Feature, nennt sich WOM auf Quelltextebene. Dient vorrangig 
der Arbeitsplatzsicherung.

Autor: Rolf M. (rmagnus)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Nop schrieb:
> S. R. schrieb:
>
>> Und das allerschönste ist, dass man dann den Code nicht lesen kann, den
>> man maintainen muss, weil einer der früheren Autoren es lernen und üben
>> wollte.
>
> Das ist ein Feature, nennt sich WOM auf Quelltextebene. Dient vorrangig
> der Arbeitsplatzsicherung.

Da braucht man kein C++ für. Das kann man in jeder Sprache tun.

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
4 lesenswert
nicht lesenswert
Real Programmers can write FORTRAN in any language.

:-)

Autor: Mikro 7. (mikro77)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg W. schrieb:
> Real Programmers can write FORTRAN in any language.
>
> :-)

Wer's noch nicht kennt:

http://www.pbm.com/~lindahl/real.programmers.html

...passt sogar ein bisschen zu der C vs. C++ Diskussion ;-)

Autor: kleines Licht (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich bin zugegebenermaßen ein relativ kleines Licht in der Diskussion.

Ich benutze c (auf Mikrocontrollern) mit, selbst geschätzt, leicht 
gehobener Erfahrung. C++ war nur akademischer Natur und das vor einer 
guten Dekade. Da habe ich also recht wenig Ahnung und quasi null 
Erfahrung.

PC programmiere ich eigentlich nur sporadisch und wenn in c und ersten 
Python-Versuchen.

Ich bin allerdings lernwillig mit unangenehm wenig freier Zeit und 
möchte mich gerne von den c++ Anhängern anfixen lassen!

Welches Buch würdet ihr mir dafür empfehlen?
Stroustrup habe ich. Allerdings 2. Auflage und so wirklich gut 
strukturiert finde ich das auch nicht.

Autor: Wilhelm M. (wimalopaan)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
kleines Licht schrieb:

> Ich bin allerdings lernwillig mit unangenehm wenig freier Zeit und
> möchte mich gerne von den c++ Anhängern anfixen lassen!
>
> Welches Buch würdet ihr mir dafür empfehlen?
> Stroustrup habe ich. Allerdings 2. Auflage und so wirklich gut
> strukturiert finde ich das auch nicht.

https://stackoverflow.com/questions/388242/the-def...

Dies sind m.E. alles gute Bücher, wenngleich ich persönlich den 
Stroustrup auch nicht besonders gut finde, der Lippmann gefällt mir 
schon besser ...

Autor: S. R. (svenska)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
kleines Licht schrieb:
> Welches Buch würdet ihr mir dafür empfehlen?

Irgendeins, was mindestens C++11 behandelt, moderner ist besser. 
Insbesondere für Embedded ist da einiges schönes dabei.

Beitrag #5273215 wurde von einem Moderator gelöscht.
Autor: Vincent H. (vinci)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Odin Holmes über "Agent based class design"
Youtube-Video "CppCon 2017: Odin Holmes “Agent based class design”"

Den Talk hatte ich bisher noch nicht im Auge weil der Titel sehr nach 
0815 Design-Pattern klingt. Was ich da aber nicht wusste ist, dass Odin 
Holmes aus der Embedded Szene kommt weshalb ich mir das ganze mal 
angesehn hab... Viel kann ich dazu aktuell nocht nicht sagen, außer dass 
es nach einer potenziell sinnvollen Methode aussieht um die immer größer 
werdende Komplexität moderner µC Peripherie sinnvoll in den Griff zu 
bekommen.

Was aber generell recht interessant ist, ist dass Odin selbst im Talk 
Kvasir mittlerweile beinhart als "fail" bezeichnet. Auch der letzte 
Commit zum Projekt liegt mittlerweile 1 Jahr zurück.

Auch emBO++ hab ich kurz angesurft, was extrem ernüchternd war. Da gibts 
ja NULL Info... außer ein paar Slides. Die können sie sich behalten. 
Bitte künftig eine Scheibe bei der CppCon abschneiden.

Autor: Nop (Gast)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
Vincent H. schrieb:
> um die immer größer werdende Komplexität moderner µC Peripherie
> sinnvoll in den Griff zu bekommen.

Linux ist Dimensionen komplexer, und für das bißchen µC-Peripherie 
braucht es neue Ansätze, weil das nicht mehr beherrschbar sei. Ja nee, 
ist klar.

Autor: jojo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vincent H. schrieb:
> Odin Holmes über "Agent based class design"
> Youtube-Video "CppCon 2017: Odin Holmes “Agent based class design”"
>
Kannte ich auch noch nicht!
>
> Was aber generell recht interessant ist, ist dass Odin selbst im Talk
> Kvasir mittlerweile beinhart als "fail" bezeichnet. Auch der letzte
> Commit zum Projekt liegt mittlerweile 1 Jahr zurück.
>
Habe mit ihm mal kurz gesprochen. Er bezeichnet Kvasir als 
proof-of-concept, das allerdings teilweise durchaus in Produktionscode 
landete. Die MPL Lib war aber langsam. Das wurde aber wohl jetzt in 
einem weiteren Repo gelöst und soll (hoffentlich) zurück portiert 
werden. Angeblich gibts da eine Roadmap Diskussion auf der emBO++.
> Auch emBO++ hab ich kurz angesurft, was extrem ernüchternd war. Da gibts
> ja NULL Info... außer ein paar Slides. Die können sie sich behalten.
> Bitte künftig eine Scheibe bei der CppCon abschneiden.
Ja, da könnte es etwas mehr geben :/ Ist nicht mehr lange..

Autor: Vincent H. (vinci)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Ich habe mich die Woche mal ein wenig mehr mit Concepts beschäftigt und 
versteh nun so langsam die Euphorie vom Wilhelm. ;) Interessanterweise 
gibts im Netz trotz des mittlerweile stolzen Alters der Concept TS 
(2015?) nicht wirklich viel Info dazu, vor allem nicht im direkten 
Vergleich mit so Dingen wie constexpr, variadic templates, etc.

Allein schon die exakte (bzw. aktuelle) Syntax zu finden war etwas 
mühsam. So steht quasi nirgends im Netz, dass man grundsätzlich zwischen 
(ich nenns mal) "Template" und "Function" Concepts unterscheiden muss. 
Und auch deren Anwendung nach einer, wenn auch minimalst, 
unterschiedlichen Syntax verlangt...


Und was ich mich nach meinen Spielerein auch langsam frage ist: Was wird 
wohl in Zukunft als "gutes" Concept Design angesehn?
Von Stroustrup gibts diesbezüglich von letztem Jänner etwa folgenden 
Artikel:
http://www.stroustrup.com/good_concepts.pdf

Den hab ich zwar bisher nur sehr grob überflogen, womit ich (nach 5 
Minuten grübeln) aber etwa nicht übereinstimme ist folgende Passage 
hier:

> First, let me make a common design mistake. It will make it easier to illustrate 
good design.
> I recently saw a concept version of an old OO problem:
>
> template<typename T>
> concept bool Drawable = requires(T t) { t.draw(); } ;

Was er damit wohl meint ist, dass Drawable schlichtweg ein Interface 
sein sollte und kein Concept. Generell erwähnt der Artikel öfters, dass 
Concepts wohl eher für fundamentale Eigenschaften gedacht sind.


Dabei würde das Concept "Drawable" aber meiner Ansicht nach fantastisch 
in den embedded Bereich passen, weil man damit quasi statische 
Polymorphie als beinahe Drop-In Replacement zu klassischer Polymorphie 
erhält.
Ein schnelles Beispiel hier:
https://godbolt.org/g/j7G1q3

Links die Variante via Vererbung, rechts die Concept Variante...

Ist das in euren Augen eine legitime Nutzung?

Beitrag #5290656 wurde von einem Moderator gelöscht.
Beitrag #5290660 wurde von einem Moderator gelöscht.
Autor: Wilhelm M. (wimalopaan)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
Vincent H. schrieb:
> Ich habe mich die Woche mal ein wenig mehr mit Concepts beschäftigt und
> versteh nun so langsam die Euphorie vom Wilhelm. ;)

Das freut mich!

> Interessanterweise
> gibts im Netz trotz des mittlerweile stolzen Alters der Concept TS
> (2015?) nicht wirklich viel Info dazu, vor allem nicht im direkten
> Vergleich mit so Dingen wie constexpr, variadic templates, etc.
>
> Allein schon die exakte (bzw. aktuelle) Syntax zu finden war etwas
> mühsam. So steht quasi nirgends im Netz, dass man grundsätzlich zwischen
> (ich nenns mal) "Template" und "Function" Concepts unterscheiden muss.

Im Concepts-TS gibt es die beiden Formen: function-concept und 
variable-concept. Es ist wohl anzunehmen, dass die genaue Syntax in 
C++20 etwas davon abweichen wird.

> Und was ich mich nach meinen Spielerein auch langsam frage ist: Was wird
> wohl in Zukunft als "gutes" Concept Design angesehn?
> Von Stroustrup gibts diesbezüglich von letztem Jänner etwa folgenden
> Artikel:
> http://www.stroustrup.com/good_concepts.pdf

Da würde ich im Moment nicht viel drauf geben ... (s.u.)

> Dabei würde das Concept "Drawable" aber meiner Ansicht nach fantastisch
> in den embedded Bereich passen, weil man damit quasi statische
> Polymorphie als beinahe Drop-In Replacement zu klassischer Polymorphie
> erhält.

Jein. Was aber sehr interessant ist, dass man nun Klassentemplates mit 
Hilfe von Constraints "überladen" kann.

> Ist das in euren Augen eine legitime Nutzung?

Absolut: Dein Anwendungsfall geht in die Kategorie wie Stroustrup das 
(ursprünglich) sieht, nämlich, die Fehlermeldungen, die durch ggf. nicht 
erfüllte implizite Template-Typanforderungen entstehen, zu 
klarifizieren. Aber das ist ja nur die halbe Miete ... (oder weniger als 
das).

Beitrag #5290672 wurde von einem Moderator gelöscht.
Beitrag #5290675 wurde von einem Moderator gelöscht.
Beitrag #5290683 wurde von einem Moderator gelöscht.
Autor: Vincent H. (vinci)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wilhelm M. schrieb:
>> Dabei würde das Concept "Drawable" aber meiner Ansicht nach fantastisch
>> in den embedded Bereich passen, weil man damit quasi statische
>> Polymorphie als beinahe Drop-In Replacement zu klassischer Polymorphie
>> erhält.
>
> Jein. Was aber sehr interessant ist, dass man nun Klassentemplates mit
> Hilfe von Constraints "überladen" kann.

Jein? Findest du nicht dass man mit Hilfe eines Concepts ein komplettes 
Interface beschreiben sollte? Wie gesagt gibts leider wirklich wenig 
Infos und komplexere Beispiele... ein "EqualityCompareable" is zwar 
nett, aber wie du andeutest sicher nicht das Ende der Fahnenstange. :)


Wilhelm M. schrieb:
>> Ist das in euren Augen eine legitime Nutzung?
>
> Absolut: Dein Anwendungsfall geht in die Kategorie wie Stroustrup das
> (ursprünglich) sieht, nämlich, die Fehlermeldungen, die durch ggf. nicht
> erfüllte implizite Template-Typanforderungen entstehen, zu
> klarifizieren. Aber das ist ja nur die halbe Miete ... (oder weniger als
> das).

Wie oben bereits erwähnt, ich sehe gerne Beispiele, Anwendungsfälle oder 
ähnliches falls du mal Zeit hast!

Autor: Wilhelm M. (wimalopaan)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
Vincent H. schrieb:
> Wilhelm M. schrieb:
>>> Dabei würde das Concept "Drawable" aber meiner Ansicht nach fantastisch
>>> in den embedded Bereich passen, weil man damit quasi statische
>>> Polymorphie als beinahe Drop-In Replacement zu klassischer Polymorphie
>>> erhält.
>>
>> Jein. Was aber sehr interessant ist, dass man nun Klassentemplates mit
>> Hilfe von Constraints "überladen" kann.
>
> Jein? Findest du nicht dass man mit Hilfe eines Concepts ein komplettes
> Interface beschreiben sollte?

Im allgemeinen assoziieren die meisten Leute mit dem Begriff "Interface" 
im Kontext der OOP eine "is-a" Vererbungsbeziehung, in C++ also eine 
public-inheritance mit kontra/kovariantem Überschreiben der 
Elementfunktionen. Analog dazu definiert ein Constraint bestimmte 
Requirements (Anforderungen) an einen Template-Typ-Parameter (oder 
Template-Template-Parameter). Insofern ein "ja" zu Deiner Aussage oben.

Allerdings sind Constraints wesentlich allgemeiner als ein Interface und 
auch wesentlich weniger (eigentlich gar nicht) gekoppelt.

Auch wenn man DIP konsequent einhält liegt dennoch eine vergleichsweise 
enge Koppelung zwischen den Subtypen und den Interface-Typen vor bei der 
Schnittstellenvererbung (Laufzeitpolymorphie). Zudem bezieht sich die 
Schnittstellenvererbung nur auf die Verhaltenseigenschaft (wobei der 
Aspekt der Konformanz regelmäßig ungeprüft bleibt, woran natürlich 
concepts auch nichts ändern ...).

Requirements in Constraints können zwar auch eine bestimmte 
Schnittstelle des Typs sicherstellen. Allerdings sind die mit dem 
fraglichen Typ in keiner Weise gekoppelt (man könnte das mit Duck-Typing 
vergleichen). Zudem kann nicht nur die Funktionsschnittstelle (oder auch 
nur ein Teilaspekt daraus) geprüft werden, sondern jeder Aspekt des 
fraglichen Typs: etwa ob der Typ andere Schnittstellen erfüllt, ob der 
Typ bestimmte andere Eigenschaften wie geschachtelte Typen oder 
Konstanten enthält, oder ob bspw. wiederum andere generische Typen 
parametriert mit diesem Typ bestimmte Eigenschaften erfüllen.

Ich denke, dass sind genügend andersartige Aspekte, die ein "nein" bzw. 
dann eben zusammen genommen ein "jein" oben rechtfertigen.

> Wie gesagt gibts leider wirklich wenig
> Infos und komplexere Beispiele... ein "EqualityCompareable" is zwar
> nett, aber wie du andeutest sicher nicht das Ende der Fahnenstange. :)

Ich finde das Beispiel eigentlich gar nicht so schlecht, weil es einfach 
ist, die völlige Kopplungslosigkeit deutlich macht, und sinnvoll nicht 
anders bisher in der Sprache dargestellt werden konnte.

>
> Wilhelm M. schrieb:
>>> Ist das in euren Augen eine legitime Nutzung?
>>
>> Absolut: Dein Anwendungsfall geht in die Kategorie wie Stroustrup das
>> (ursprünglich) sieht, nämlich, die Fehlermeldungen, die durch ggf. nicht
>> erfüllte implizite Template-Typanforderungen entstehen, zu
>> klarifizieren. Aber das ist ja nur die halbe Miete ... (oder weniger als
>> das).
>
> Wie oben bereits erwähnt, ich sehe gerne Beispiele, Anwendungsfälle oder
> ähnliches falls du mal Zeit hast!

Vielleicht sollte man da einen eigenen Thread aufmachen?

Wenn ich mal schnell meine Anwendungsfälle so durchgehe, dann fallen mir 
etwa die folgenden ein:
   template<typename T>
    concept bool NamedFlag() {
        return requires(T f) {
            T::value;
            {T::value} -> bool;
        };
    }
    template<typename T>
    concept bool NamedConstant() {
        return requires(T c) {
            T::value;
            {T::value} -> typename T::value_type;
        };
    }

Ich bin dazu übergegangen, alle Konstanten in Typen zu packen: also 
statt:
Timer<true> t;
EventQueue<32> eq;

besser:
Timer<UseEventQueue<true>> t;
EventQueue<QueueLength<32>> eq;

und
template<NamedFlag UseEventQueue>
class Timer {...};

template<NameConstant Lenght>
class EventQueue {...}: 

oder auch:
    template<typename D>
    concept bool Device() {
        return requires(D d) {
            D::put(std::byte{0});
           {D::get()} -> typename D::value_type;
        };
    }

und dann:
template<Device D>
class ProtocolAdapter {...};

oder auch:
   template<uint8_t N, typename MCU>
    requires AVR::ATMega_X8<MCU>() || ((N == 0) && (AVR::ATTiny_X4<MCU>()))
    class Timer8Bit<N, MCU> : public TimerBase<MCU, N> {...};
womit sich Spezialisierungs-Orgien vermeiden lassen.

Autor: Vincent H. (vinci)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
Es wird mal wieder Zeit für kräftige Argumente, heute Boost SML:
http://boost-experimental.github.io/sml/index.html

Boost SML ist der geistige Nachfolger von Boost MSM. Während MSM aber 
auf Grund seines Overheads quasi nie embedded-tauglich war erzeugt SML 
winzigen Code (vor allem im Vergleich zu std::variant). Was aber 
wahrlich beeindruckent ist, ist die schlichte Eleganz mit der sich via 
Transition Table die komplette State Machine beschreiben lässt ->
// from boost::sml examples

namespace {
struct e1 {};
struct e2 {};
struct e3 {};

struct states {
  auto operator()() const noexcept {
    using namespace sml;
    const auto idle = state<class idle>;
    return make_transition_table(
       *idle + event<e1> = "s1"_s
      , "s1"_s + sml::on_entry<_> / [] { std::cout << "s1 on entry" << std::endl; }
      , "s1"_s + sml::on_exit<_> / [] { std::cout << "s1 on exit" << std::endl; }
      , "s1"_s + event<e2> = state<class s2>
      , state<class s2> + event<e3> = X
    );
  }
};
}

int main() {
  sml::sm<states> sm;
  sm.process_event(e1{});
  sm.process_event(e2{});
  sm.process_event(e3{});
  assert(sm.is(sml::X));
}


Eine Liste mit den unterstützten UML-features findet sich hier:
http://boost-experimental.github.io/sml/benchmarks...

Als besonders praktisch empfand ich die orthogonal regions, die sich 
ausgezeichnet nutzen lassen um immer wieder kehrende Operationen 
abzudecken. Klassisch etwa "ADC einlesen" vor jedem eigentlichen State 
Machine dispatch.
// operator()()
return make_transition_table(
*"read_adc"_s + "irq"_e / read_adc = "read_adc"_s,
*"s0"_s + "e0"_e / action0 = "s1"_s,
 "s1"_s + "e1"_e / action1 = "s2"_s
 // etc.
);

Autor: 900ss D. (900ss)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Vincent H. schrieb:
> ist die schlichte Eleganz

Super elegant.... und vor allem so leserlich.  ;)

Ich finde , dass ist ein Beispiel, kein C++ zu nehmen. Auch wenn es den 
Code rein textuell kürzer macht.

Autor: TriHexagon (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
900ss D. schrieb:
> Vincent H. schrieb:
>> ist die schlichte Eleganz
>
> Super elegant.... und vor allem so leserlich.  ;)
>
> Ich finde , dass ist ein Beispiel, kein C++ zu nehmen. Auch wenn es den
> Code rein textuell kürzer macht.

Und was hindert dich daran einen anderen Ansatz zu wählen, der dir mehr 
zusagt? In C könntest du es so jedenfalls nicht formulieren...

Autor: 900ss D. (900ss)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
TriHexagon schrieb:
> Und was hindert dich daran einen anderen Ansatz zu wählen, der dir mehr
> zusagt?

Nichts, steht irgendwo,  dass mich etwas daran hindert?  Ist nur meine 
bescheidene Meinung zu diesem Beispiel.

> In C könntest du es so jedenfalls nicht formulieren...

Wohl nicht, aber so find ich es halt bescheiden.

Autor: Vincent H. (vinci)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
900ss D. schrieb:
> Wohl nicht, aber so find ich es halt bescheiden.

Zum Toggeln einer LED würd ich das auch nicht einsetzen, aber du 
übersiehst die Vorteile bei komplexeren State Machines.

1.) Statt 23 verschiedener Klassen oder einem 500 Zeilen langen 
switch-case steht der gesamte Logik-Teil der State Machine in einer 
einzigen Tabelle. Ja natürlich könnte man "transition tables" als 
Kommentar in den Code schmeißen... das macht halt nur kein Mensch. ;)

2.) Guards und Actions sind durch das Design Prinzip bereits entkoppelt 
und da Single-Responsibility-Principle wird strikt eingehalten. Dadurch 
sind Guards und Actions ausgezeichnet testbar. Der Nutzer kann gar 
keinen eng-gekoppelten Code schreiben.

3.) Boilerplate bei entry/exit/history/orthogonal regions und sonstigen 
"advanced" State Machine features entfällt. Denk mal drüber nach wie du 
diese features in C einbauen würdest und wie mühsam das teils wär!

Autor: TriHexagon (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
900ss D. schrieb:
> TriHexagon schrieb:
>> Und was hindert dich daran einen anderen Ansatz zu wählen, der dir mehr
>> zusagt?
>
> Nichts, steht irgendwo,  dass mich etwas daran hindert?

900ss D. schrieb:
> Ich finde , dass ist ein Beispiel, kein _C++_ zu nehmen.

Hier kommst du aber zum Schluss, dass C++ nichts für dich ist, wobei der 
Ansatz das eigentliche Problem ist, aber nicht C++. Das meinte ich. Da 
ist es ganz egal wie der Ansatz selbst zu bewerten ist.

Zum Ansatz selber, ja optisch jetzt nicht so optimal, aber wenn man eine 
komplexere Statemachine aufbaut, dann find ichs schon praktisch. Ich hab 
erst kürzlich einen Parser mit einer Statemachine in Plain C aufgebaut. 
Ganz einfach mit switch cases und je einer Funktion pro Zustand. Problem 
an der ganzen Sache ist, dass sich das total aufbläht und noch schlimmer 
ziemlich fehleranfällig ist. Aber das hat Vincent schon ziemlich gut 
erläutert.

Autor: 900ss D. (900ss)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vincent H. schrieb:
> aber du übersiehst die Vorteile bei komplexeren State Machines.

Gedehntes "vielleicht". :)
Aber lesbar ist es nicht sonderlich und das stört mich daran. Ok,  auch 
in C muss man das erstmal lesbar formulieren.

Autor: S. R. (svenska)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vincent H. schrieb:
> Zum Toggeln einer LED würd ich das auch nicht einsetzen, aber du
> übersiehst die Vorteile bei komplexeren State Machines.

Ich finde dieses Beispiel ebenfalls abschreckend und unlesbar. 
Allerdings unter einer Einschränkung: Wenn man generierten Code (aus 
einer eingeschränkten Spezialsprache) betrachtet, spielt Lesbarkeit 
keine Rolle. Sollte dieses Beispiel wirklich effizienten Maschinencode 
erzeugen, dann meinetwegen.

Aber von Hand und für Menschen geschrieber Code sollte als oberstes 
Kriterium lesbar (und wartbar) sein, und er sollte zumindest 
verständlich sein, bevor man viele Abstraktionen und Transformationen 
einführt (sonst ist die wahre Komplexität nicht abschätzbar).

Autor: Heiko L. (zer0)
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
High-Level-mäßig würde ich sagen: Das Programm ist bereits eine 
State-Machine. Kein Grund eine in einer anderen auszudrücken. 
"State-Transitionen" sind in C(++) etwa ein Semikolon oder ein 
Funktionsaufruf. Definiert C++ für solches Zeug nicht extra Koroutinen?
Auf größeren Geräten macht man halt 'nen Thread auf!

: Bearbeitet durch User
Autor: Wilhelm M. (wimalopaan)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
Vincent H. schrieb:
> Es wird mal wieder Zeit für kräftige Argumente, heute Boost SML:
> http://boost-experimental.github.io/sml/index.html

...

> Als besonders praktisch empfand ich die orthogonal regions, die sich
> ausgezeichnet nutzen lassen um immer wieder kehrende Operationen
> abzudecken. Klassisch etwa "ADC einlesen" vor jedem eigentlichen State
> Machine dispatch.
>
>
> // operator()()
> return make_transition_table(
> *"read_adc"_s + "irq"_e / read_adc = "read_adc"_s,
> *"s0"_s + "e0"_e / action0 = "s1"_s,
>  "s1"_s + "e1"_e / action1 = "s2"_s
>  // etc.
> );
> 

Bei der Modellierung von Zustandsautomaten bin ich immer etwas hin- und 
her gerissen. Auf der einen Seite sind sie ein wunderschönes Werkzeug 
zur Modellierung (z.B. Protokollanalyse) und ein schönes theoretisches 
Spielfeld. Auf der anderen Seite ist die eigentliche Logik eines 
Zustandsautomaten so simpel, dass sich eine irgendwie geartete 
Abstraktion schon durch große Vorteile auszeichnen muss, um sie 
einzusetzen. Schließlich ist jedes Objekt eines Typs mit mindestens 
einem Datenelement ein Zustandsautomat. Die Praxis zeigt aber auch oft, 
dass hier eine weitere Abstraktion oft nicht eingesetzt wird / wenig 
sinnvoll ist.

Ich finde die o.g. DSEL von Boost für die SM nicht schlecht. Allerdings 
finde ich die Wahl der Zustands-/Event-Identifier als String-UDLs nicht 
glücklich. Aber das ist natürlich Geschmacksfrage. Zusätzlich habe ich 
mir angewöhnt, statische Dinge im Code auch statisch auszudrücken.

Bei mir kommen SM im wesentlichen in den folgenden Kategorien daher:

1) allg. Typen mit Mutatoren (aka setter): hier ist der Typ die SM 
selbst.

2) kleine SM in einem Typ: eine Handvoll Zustände als enum und etwas 
if/switch ist ausreichend verständlich, wenn man die Zustände/Events und 
Funktionen sinnvoll benennt.

3) mittlere SM: die sequentielle Formulierung mit if/switch-Monster 
(etwa > 10 Zustände) ist unschön. Ein andere, deklarative Formulierung 
wäre schöner.

Meine Lösung dazu ist etwa folgendes:
using fsm = FSM<Tr<StateA, StateB, E1>, Tr<StateB, StateC, E2>, Tr<StateC, StateA, E3>>;
using mapper = EventMapper<fsm, RangeEvent<unsigned char, 'A', 'z', E1>, ValueEvent<unsigned char, ',', E2>>;
...
mapper::process(c);

Die Zustandshandler sind dabei als freie Funktionen geschrieben und 
werden über ADL gefunden:
void enter(StateA) {...}
...
void exit(StateB) {...}

Das ist sehr simpel, kein Overhead gegenüber if/switch und ermöglicht 
eine deklarative Formulierung.

Autor: Christopher J. (christopher_j23)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
In dieser Präsentation wird kurz erklärt was es mit der Boost SML Syntax 
auf sich hat. Danach finde ich sie eigentlich gar nicht so übel:
Youtube-Video "C++Now 2018: Michael Caisse “Modern C++ in Embedded Systems”"


Wilhelm M. schrieb:
> Meine Lösung dazu ist etwa folgendes:using fsm = FSM<Tr<StateA, StateB,
> E1>, Tr<StateB, StateC, E2>, Tr<StateC, StateA, E3>>;
> using mapper = EventMapper<fsm, RangeEvent<unsigned char, 'A', 'z', E1>,
> ValueEvent<unsigned char, ',', E2>>;
> ...
> mapper::process(c);

Das sieht auch sehr elegant aus. Hättest du dazu vielleicht ein 
lauffähiges Beispiel?

Autor: mh (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zur allgemeinen Info: Seit Sonntag ist die CppCon 2018 
(https://cppcon2018.sched.com/) vorbei und es gibt die ersten Videos auf 
youtube (https://www.youtube.com/user/CppCon/videos).

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.