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


von Wilhelm M. (wimalopaan)


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-time-processing-with-constexpr.html

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

http://codedive.pl/pl/speaker/speaker/bartosz-szurgot/year/2015/

https://www.youtube.com/watch?v=k8sRQMx2qUw

https://www.youtube.com/watch?v=AKAYc9ZFBhk

https://www.youtube.com/watch?v=FnGCDLhaxKU

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

http://files.meetup.com/10475902/TypeSystemIsYourFriend_Oxford.pdf

http://www.embedded.com/design/programming-languages-and-tools/4438660/3/Modern-C--in-embedded-systems---Part-1--Myth-and-Reality

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

Request for more!

:
von Carl D. (jcw2)


Lesenswert?

More:
http://sbrc2010.inf.ufrgs.br/anais/data/pdf/wtr/st03_01_wtr.pdf

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

von Johannes S. (Gast)


Lesenswert?

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

von Verschwender (Gast)


Lesenswert?

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

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

von (prx) A. K. (prx)


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.

von Tom (Gast)


Lesenswert?

Apropos "dick" und C++:

Jason Turner "Rich Code For Tiny Machines: A Simple Commodore 64 Game In 
C++17"
https://www.youtube.com/watch?v=zBkNBP00wJE

BG, Tom

von Wilhelm M. (wimalopaan)


Lesenswert?


von Christopher J. (christopher_j23)


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.

von Vincent H. (vinci)


Lesenswert?


von Wilhelm M. (wimalopaan)


Lesenswert?

Empfehlen möchte ich auch noch:

https://www.youtube.com/watch?v=n4ie7tPMXOQ

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) ...

von Wilhelm M. (wimalopaan)


Lesenswert?

Und noch einer:

https://www.youtube.com/watch?v=PFdWqa68LmA

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.

von Vincent H. (vinci)


Lesenswert?

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

https://www.youtube.com/watch?v=bSkpMdDe4g4

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Vincent H. schrieb:
> der ASM/C Fraktion

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

von Raoul D. (raoul_d219)


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
von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Raoul D. schrieb:
> Dafür gibt es schon genug andere

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

von Wilhelm M. (wimalopaan)


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.
von Jörg W. (dl8dtl) (Moderator) Benutzerseite


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
von temp (Gast)


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.

von Nop (Gast)


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.

von jz23 (Gast)


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.

von Vincent H. (vinci)


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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


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".

von Wilhelm M. (wimalopaan)


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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


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.

von Rolf M. (rmagnus)


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:
1
for (std::list<std::string>::const_iterator it = mylist.begin(); it != mylist.end(); ++it)
2
{
3
    std::cout << *it << '\n';
4
}
vs
1
for (const auto& elem : mylist)
2
{
3
    std::cout << elem << '\n';
4
}

: Bearbeitet durch User
von H. S. (Gast)


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

von Wilhelm M. (wimalopaan)


Lesenswert?


von Dumdi D. (dumdidum)


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?)

von Wilhelm M. (wimalopaan)


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.

von dumdidum (nicht angemeldet) (Gast)


Lesenswert?

Scott Meyers: https://www.youtube.com/watch?v=RT46MpK39rQ
Wer nicht den ganzen Talk sehen möchte, ich finde 41:00 bis 43:00 
erklärt einige Diskussionen.

von mh (Gast)


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.

von Mikro 7. (mikro77)


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.
von Wilhelm M. (wimalopaan)


Lesenswert?

AutoSAR C++14

Interessantes Thema, leider ein sehr schlechter Vortrag:

https://www.youtube.com/watch?v=YzyGgZ_RClw

von Wilhelm M. (wimalopaan)


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):

https://www.youtube.com/watch?v=sCjZuvtJd-k

von Vincent H. (vinci)


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".

https://www.youtube.com/watch?v=WsUnnYEKPnI

von Sheeva P. (sheevaplug)


Lesenswert?

Carl D. schrieb:
> More:
> http://sbrc2010.inf.ufrgs.br/anais/data/pdf/wtr/st03_01_wtr.pdf
>
> 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.

von Carl D. (jcw2)


Lesenswert?

Sheeva P. schrieb:
> Carl D. schrieb:
>> More:
>> http://sbrc2010.inf.ufrgs.br/anais/data/pdf/wtr/st03_01_wtr.pdf
>>
>> 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.

von Sheeva P. (sheevaplug)


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.

von Vincent H. (vinci)


Lesenswert?

Alfred Bratterud
“Delegate this! Designing with delegates in modern C++

https://www.youtube.com/watch?v=QMb4RRFrY-o&index=62&list=PLHTh1InhhwT6bwIpRk0ZbCA0N2p1taxd6

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/api/util/delegate.hpp

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.
1
std::array<size_t, 3> a1 { 1, 2, 3};
2
3
auto big_lambda = [=] () -> int
4
{
5
  trace_printf("big_lambda: ");
6
  return a1[0] + a1[1] + a1[2];
7
};
8
9
// allocates memory (@GCC 7.2 for a cortex M4 platform)
10
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.
1
// use just enough memory to store "big_lambda"
2
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
von Wilhelm M. (wimalopaan)


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:

https://www.youtube.com/watch?v=HMB9oXFobJc

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/constexpr-function-parameters/

)

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


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
von Hans-Georg L. (h-g-l)


Lesenswert?


von Arc N. (arc)


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/2017/n4659.pdf
oder den aktuellen Stand von C++2x ansehen möchte:
https://github.com/cplusplus/draft

von Jan K. (jan_k)


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?

von Thomas W. (thomas_v2)


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.

von Lernunfauler (Gast)


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.

von S. R. (svenska)


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.

von Nop (Gast)


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.

von Rolf M. (rmagnus)


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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Real Programmers can write FORTRAN in any language.

:-)

von Mikro 7. (mikro77)


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 ;-)

von kleines Licht (Gast)


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.

von Wilhelm M. (wimalopaan)


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-definitive-c-book-guide-and-list

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 ...

von S. R. (svenska)


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.
von Vincent H. (vinci)


Lesenswert?

Odin Holmes über "Agent based class design"
https://www.youtube.com/watch?v=tNXyNa6kf4k

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.

von Nop (Gast)


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.

von jojo (Gast)


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..

von Vincent H. (vinci)


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.
von Wilhelm M. (wimalopaan)


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.
von Vincent H. (vinci)


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!

von Wilhelm M. (wimalopaan)


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:
1
   template<typename T>
2
    concept bool NamedFlag() {
3
        return requires(T f) {
4
            T::value;
5
            {T::value} -> bool;
6
        };
7
    }
8
    template<typename T>
9
    concept bool NamedConstant() {
10
        return requires(T c) {
11
            T::value;
12
            {T::value} -> typename T::value_type;
13
        };
14
    }

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

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

und
1
template<NamedFlag UseEventQueue>
2
class Timer {...};
3
4
template<NameConstant Lenght>
5
class EventQueue {...}:

oder auch:
1
    template<typename D>
2
    concept bool Device() {
3
        return requires(D d) {
4
            D::put(std::byte{0});
5
           {D::get()} -> typename D::value_type;
6
        };
7
    }

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

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

von Vincent H. (vinci)


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 ->
1
// from boost::sml examples
2
3
namespace {
4
struct e1 {};
5
struct e2 {};
6
struct e3 {};
7
8
struct states {
9
  auto operator()() const noexcept {
10
    using namespace sml;
11
    const auto idle = state<class idle>;
12
    return make_transition_table(
13
       *idle + event<e1> = "s1"_s
14
      , "s1"_s + sml::on_entry<_> / [] { std::cout << "s1 on entry" << std::endl; }
15
      , "s1"_s + sml::on_exit<_> / [] { std::cout << "s1 on exit" << std::endl; }
16
      , "s1"_s + event<e2> = state<class s2>
17
      , state<class s2> + event<e3> = X
18
    );
19
  }
20
};
21
}
22
23
int main() {
24
  sml::sm<states> sm;
25
  sm.process_event(e1{});
26
  sm.process_event(e2{});
27
  sm.process_event(e3{});
28
  assert(sm.is(sml::X));
29
}


Eine Liste mit den unterstützten UML-features findet sich hier:
http://boost-experimental.github.io/sml/benchmarks/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.
1
// operator()()
2
return make_transition_table(
3
*"read_adc"_s + "irq"_e / read_adc = "read_adc"_s,
4
*"s0"_s + "e0"_e / action0 = "s1"_s,
5
 "s1"_s + "e1"_e / action1 = "s2"_s
6
 // etc.
7
);

von 900ss (900ss)


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.

von TriHexagon (Gast)


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...

von 900ss (900ss)


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.

von Vincent H. (vinci)


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!

von TriHexagon (Gast)


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.

von 900ss (900ss)


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.

von S. R. (svenska)


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).

von Heiko L. (zer0)


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
von Wilhelm M. (wimalopaan)


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.
>
>
1
> // operator()()
2
> return make_transition_table(
3
> *"read_adc"_s + "irq"_e / read_adc = "read_adc"_s,
4
> *"s0"_s + "e0"_e / action0 = "s1"_s,
5
>  "s1"_s + "e1"_e / action1 = "s2"_s
6
>  // etc.
7
> );
8
>

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:
1
using fsm = FSM<Tr<StateA, StateB, E1>, Tr<StateB, StateC, E2>, Tr<StateC, StateA, E3>>;
2
using mapper = EventMapper<fsm, RangeEvent<unsigned char, 'A', 'z', E1>, ValueEvent<unsigned char, ',', E2>>;
3
...
4
mapper::process(c);

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

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

von Christopher J. (christopher_j23)


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:
https://www.youtube.com/watch?v=c9Xt6Me3mJ4&feature=youtu.be&list=PL_AKIMJc4roVSbTTfHReQTl1dc9ms0lWH&t=4195


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?

von mh (Gast)


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).

von Vincent H. (vinci)


Lesenswert?


von Wilhelm M. (wimalopaan)


Lesenswert?

Hier eine schöne Zusammenstellung vieler sehr interessanter Vorträge

https://www.cjdb.com.au/sg20-and-videos

Viel Spaß!

von Vincent H. (vinci)


Lesenswert?

Making C Less Dangerous in the Linux kernel

https://www.youtube.com/watch?v=FY9SbqTO5GQ


In den Kommentaren zeigt sich leider der ähnliche Widerstand wie hier im 
Forum ala "type safety is retarted." :/

von Murkser (Gast)


Lesenswert?


von Heiko L. (zer0)


Lesenswert?

My daily rant

Ich schreibe FSM in Hochsprachen, so mit if/then/while und so. Ist imho 
weit besser lesbar. Mir würde sich ja sofort die Frage stellen, was denn 
bei dem Beispiel passieren würde, wenn sich Transitionen überlappen. 
Jaja, die Bedingungen werden selbstverständlich in der Reihenfolge 
geprüft, in der die Transitionen deklariert sind. Exception safety? Klar 
- ist völlig transparent. Transaktional in dem Fall? Ähhh... Um solches 
Zeug zu verifizieren muss man entweder die Hochsprache beherrschen 
oder die Implementierung von DSL Nummer 287361 checken, bevor man sich 
überhaupt dem eigentlichen Problem zuwenden kann. Das ist echt Fancy, 
oder nicht?

Natürlich, wenn eine Art von Problemstellung einen hinreichend großen 
Teil der gesamten Arbeit ausmacht lohnt sich so etwas... - vielleicht. 
Es gäbe dann nämlich auch noch zB SCXML! Das ist standartisiert und 
notwendig Data-Driven. Heißt grafische Tools und Klicki-Bunti. Also 
unsere P.O. fänden das sicher echt toll - alles so schön anschaulich! 
"Kann man nicht von hier besser nach da hinten?"

: Bearbeitet durch User
von Daniel -. (root)


Lesenswert?

das beispiel ist abschreckend. genauso wie regex eine dsl ist,
könnte man statemachine in eigene dsl packen.
das wäre sprachübergreifend, mächtig und würde das erfinden des rades
erübrigen.

von Daniel -. (root)


Lesenswert?

c++ ist leider viel zu vermurkst geworden.
ich hoffe rust community wird mit features zurückhaltender sein.
die aktuellen ansätze (expression statt statement basiert,
deconstruction mit pattern matching) sind der richtige weg.
c++ ahmt mit std::variant genau das nach ...

von mh (Gast)


Lesenswert?

Daniel -. schrieb:
> ich hoffe rust community wird mit features zurückhaltender sein.
> die aktuellen ansätze (expression statt statement basiert,
> deconstruction mit pattern matching) sind der richtige weg.
> c++ ahmt mit std::variant genau das nach ...

Wie soll C++ mit std::variant rust nachahmen, wenn es boost::variant 
offiziell seit Jan 2004 gibt und rust erst seit Jul 2010?

von Vincent H. (vinci)


Lesenswert?

Daniel -. schrieb:
> c++ ist leider viel zu vermurkst geworden.

Viele Entscheidungen des Standard Committee kann ich auch nicht 
nachvollziehen.

In welcher abgedrehten Welt ist "consteval" 
(https://en.cppreference.com/w/cpp/language/consteval) sofort einem 
Keyword würdig, ein variant darf aber kein Language Feature werden? Das 
is einfach absurd. Pattern Matching auf Sprachebene ist in meinen Augen 
DAS fehlende C++ Feature.

von Daniel -. (root)


Lesenswert?

Daniel -. schrieb:
>> ich hoffe rust community wird mit features zurückhaltender sein.
>> die aktuellen ansätze (expression statt statement basiert,
>> deconstruction mit pattern matching) sind der richtige weg.
>> c++ ahmt mit std::variant genau das nach ...

>Wie soll C++ mit std::variant rust nachahmen, wenn es boost::variant
>offiziell seit Jan 2004 gibt und rust erst seit Jul 2010?

Das war mir nicht bekannt. Ich bin seit 2004 fast komplett aus C++ raus.
Für meine typischen Skripte spielt es keine Rolle, ob die 
Ausführungszeit
50ms oder 1ms beträgt. Ich bin auf Python umgeswitcht. Mit einwenig C#, 
F# und Go. An sich leben die Sprachen vom Ausborgen von Features 
untereinander. Das Pendant zu std::variant wäre discriminated union aus 
F#.
Womit das Thema bei algebraic data types und type modeling landet.

Bezogen auf C++, hier ein Einblick
https://www.youtube.com/watch?v=ojZbFIQSdl8


Vincent H. schrieb:
> In welcher abgedrehten Welt ist "consteval"
> (https://en.cppreference.com/w/cpp/language/consteval) sofort einem
> Keyword würdig, ein variant darf aber kein Language Feature werden? Das
> is einfach absurd. Pattern Matching auf Sprachebene ist in meinen Augen
> DAS fehlende C++ Feature.

Die Schwierigkeit wird vermutlich darin liegen, das Zusammenspiel
mit anderen Konzepten so zu gestalten, dass keine gefährlichen
Doppeldeutigkeiten entstehen.

Ich halte mich bei C++ meistens an "alt bewährtes" (~ C++11).
Ich hatte vor Kurzem mit touchgfx Bibliothek zu tun und bin
von derem C++ Still auch in dieser Hinsicht bestätigt worden.

von Daniel -. (root)


Lesenswert?

>>Wie soll C++ mit std::variant rust nachahmen, wenn es boost::variant
>>offiziell seit Jan 2004 gibt und rust erst seit Jul 2010?

vielleicht könnte man Rust die Einführung von "move" attributieren,
die C++ ja bekanntlich nun auch hat. Allerdings muss hier der 
Programmierer
aufpassen alles richtig zu tun.

: Bearbeitet durch User
von mh (Gast)


Lesenswert?

Daniel -. schrieb:
> vielleicht könnte man Rust die Einführung von "move" attributieren,

Versucht du jetzt zu behaupten, dass C++ move Semantik hat, weil es rust 
gibt? Dir ist klar, dass es move seit c++11 gibt und dass man so einen 
Standard nicht in ein paar Wochen zusammenschustert?

von Heiko L. (zer0)


Lesenswert?

Daniel -. schrieb:
> das beispiel ist abschreckend. genauso wie regex eine dsl ist,
> könnte man statemachine in eigene dsl packen.
> das wäre sprachübergreifend, mächtig und würde das erfinden des rades
> erübrigen.

Mein Punkt war eher: das Beispiel ist eigentlich okay, aber trotzdem 
völlig ungeeignet, damit im Team ernsthaft zu arbeiten oder solchen Code 
ggf. in andere Hände zu geben. Deswegen ist das mit der Feature-Flut in 
C++ auch eine zweischneidige Sache. Ich persönlich habe schon den 
Eindruck, dass man von der Sprache nicht mehr unbedingt alles in Tiefe 
erfassen kann (oder das nur so stückchenweise wird tun können). Dadurch, 
dass es diese Möglichkeiten aber gibt, ist man, wenn man sie braucht, 
nicht darauf verwiesen, sich gleich völlig in exotisch-akademische 
Gefilde zu begeben, von denen man dann noch viel, viel weniger Ahnung 
hat. Wer zückt schon gleich Eiffel, wenn er meint, dass ein Stück seiner 
Anwendung es Wert wäre, sie mit constraints zu versehen? Soll man sowas 
ernsthaft mit asserts lösen? Merke: Die stehen in der Implementierung!
Ich bin nicht mehr sicher, wo das stand - aber ein übermäßig großer 
Prozentsatz von Security-Issues zum Beispiel wird, direkt oder indirekt, 
durch ungeprüfte 3rd-Party-Libraries verursacht. Mal nicht geprüft, was 
die genau tut, und schon knallts. - "Ist doch völlig intuitiv zu 
bedienen."
Siehe zum Beispiel den Robot-Attack https://robotattack.org/. "Einfach 
mal 'ne SSL-Lib reingelinkt"
1
So, at some point last year, Hanno and friends decided to ask the Internet another question: do web servers really still have RSA padding oracles, the kind Daniel Bleichenbacher discovered back in 1998? It’s 20 years later! We’ve dealt with that problem by now, right?
2
3
And the result is a Bleichenbloodbath.
4
5
They’re publishing documents signed with Facebook’s private key (not once, but twice, breaking Facebook’s fix for the bug). They’ve killed the RSA on F5 Big-IP boxes. Does anyone still use Radware? I guess they do, because the ROBOT team broke those. Citrix, too. Cisco’s ACE boxes are broken — Cisco won’t fix them, mind you, because they’re out of support now, but, oh shit, hold on, CISCO.COM is vulnerable too! Paypal’s vulnerable! A chunk of the Alexa top million. BouncyCastle breaks. The custom non-OpenSSL libraries like WolfSSL and MatrixSSL break. Erlang is broken. Cavium is broken. Unisys ClearPath MCP is broken! The MCP! It’s bananas.
https://pwnies.com/winners/

von Vincent H. (vinci)


Lesenswert?

Writing better embedded Software - Dan Saks
https://www.youtube.com/watch?v=3VtGCPIoBfs

von Wilhelm M. (wimalopaan)


Lesenswert?

Vincent H. schrieb:
> Writing better embedded Software - Dan Saks
> https://www.youtube.com/watch?v=3VtGCPIoBfs

Als Keynote finde ich den Vortrag eher schwach.

Im übrigen reicht es m.E. hier ab Minute 40 einzusteigen.

von Wilhelm M. (wimalopaan)


Lesenswert?


von Wilhelm M. (wimalopaan)


Lesenswert?

CppCon 2019 läuft gerade:

https://www.youtube.com/watch?v=u_ij0YNkFUs

von zitter_ned_aso (Gast)


Lesenswert?

Wilhelm M. schrieb:
> Zugegeben: ich von von der C++-Fraktion ;-)

Der ganze Thread ist über C++

von Wilhelm M. (wimalopaan)


Lesenswert?

zitter_ned_aso schrieb:
> Wilhelm M. schrieb:
>> Zugegeben: ich von von der C++-Fraktion ;-)
>
> Der ganze Thread ist über C++

Gut, dass Du das gemerkt hast ;-)

von Wilhelm M. (wimalopaan)


Lesenswert?

Wieder ein sehr guter Vortrag von Sean:

https://www.youtube.com/watch?v=ejF6qqohp3M

Beitrag #5983502 wurde von einem Moderator gelöscht.
von Vincent H. (vinci)


Lesenswert?

Jener Vortrag über type punning ist ein must-see für die gesamte 
Community:
https://youtu.be/_qzMpk-22cc

von Nop (Gast)


Lesenswert?

Vincent H. schrieb:

> Youtube-Video "CppCon 2019: Timur Doumler “Type punning in modern C++”"

Tja, in C kann man problemlos type punning mit unions machen, jedenfalls 
seit C99. Geht in C++ halt wegen name mangling nicht.

Lustig ist auch, daß das, was er als "C style cast" bezeichnet, in C 
ebenfalls UB wäre, zumindest bei seinen Beispielen.

Was übrigens bezüglich aliasing im Standard-C++ nicht vorhanden ist, das 
ist "restrict", wie C das seit C99 hat. Kommt natürlich daher, daß man 
in C++ immer weniger mit direkt Pointern arbeitet und restrict nie für 
Klassen entworfen war.

von Wilhelm M. (wimalopaan)


Lesenswert?

Nop schrieb:
> Vincent H. schrieb:
>
>> Youtube-Video "CppCon 2019: Timur Doumler “Type punning in modern C++”"
>
> Tja, in C kann man problemlos type punning mit unions machen, jedenfalls
> seit C99. Geht in C++ halt wegen name mangling nicht.

Das hat mit name-mangling gar nichts zu tun: wird doch alles in dem 
guten Vortrag besprochen und ist auch hier im Forum x-mal diskutiert 
worden (und wird es wohl auch in Zukunft werden).

: Bearbeitet durch User
von Nop (Gast)


Lesenswert?

Wilhelm M. schrieb:

> Das hat mit name-mangling gar nichts zu tun: wird doch alles in dem
> guten Vortrag besprochen

Nein, wird es nicht. Da wird nur gesagt, DASS es in C++ eben UB ist (bei 
10:19), aber nicht wieso. Und C++ wird hier mit dem bitcast in C++23 ein 
Problem lösen, das man in C schon seit 20 Jahren auch ohne memcpy nicht 
mehr hat.

von Jan (Gast)


Lesenswert?

Es wird aber zumindest gesagt, dass z.B. type aliasing in C++ auf den 
selben Typ erlaubt sind. Auf unterschiedliche Typen aber eben nicht, 
weil dann der Compiler paranoid sein müsste und damit schlecht 
optimiert.
Warum aber konkret type punning mit unions bei C++ nicht erlaubt ist 
wird aber mMn nicht gesagt und verstehe ich auch noch nicht 100%.

von Wilhelm M. (wimalopaan)


Lesenswert?

Jan schrieb:
> Es wird aber zumindest gesagt, dass z.B. type aliasing in C++ auf den
> selben Typ erlaubt sind. Auf unterschiedliche Typen aber eben nicht,
> weil dann der Compiler paranoid sein müsste

das erwarte ich von ihm

> und damit schlecht
> optimiert.

Nein, je paranoider, desto besser die Optimierung.

> Warum aber konkret type punning mit unions bei C++ nicht erlaubt ist
> wird aber mMn nicht gesagt und verstehe ich auch noch nicht 100%.

Wird alles im Vortrag ausführlich behandelt, sogar mit Auszügen des 
Standards.

Die Stichworte sind: object-lifetime und strict-aliasing

von S. R. (svenska)


Lesenswert?

Wilhelm M. schrieb:
> Nein, je paranoider, desto besser die Optimierung.

Ein paranoider Compiler muss davon ausgehen, dass nichts von dem, was er 
tut, real oder persistent ist, z.B. der Speicher. Aus der Annahme, dass 
alle Variablen jederzeit ihren Inhalt ändern können (Paranoia) folgt 
also, dass alle Variablen volatile sein müssen. Keine gute 
Optimierungsgrundlage.

Oder du hast eine seltsame Definition von paranoiden Compilern. :-)

von Nop (Gast)


Lesenswert?

Wilhelm M. schrieb:

> Wird alles im Vortrag ausführlich behandelt, sogar mit Auszügen des
> Standards.

Die Frage ist nicht, ob es im Standard steht (tut es), sondern warum man 
das in C++ nicht so gemacht hat wie in C.

Object lifetime wird's ja wohl nicht sein, weil unions in C++ ohnehin 
keine eigenen Konstruktoren, Destruktoren usw. enthalten dürfen - woher 
sollte der Compiler auch wissen, welchen er bei der Deklaration aufrufen 
soll.

Strict aliasing - ja, hat C auch, und trotzdem darf man union type 
punning machen. In C++ dagegen nicht. Aber warum? Hat man union type 
punning in C++ einfach für unwichtig gehalten und sich daher lieber 
zugunsten von Performance entschieden, weil weniger erlaubtes aliasing 
ja auch weniger reloads bedeutet?

In dem Fall wäre das Argument wohl, daß man ja seit jher noch memcpy 
hat, was der Compiler in dem Fall sowieso wegoptimiert, so daßr union 
type punning als Feature nicht zwingend notwendig ist.

von Niklas G. (erlkoenig) Benutzerseite


Lesenswert?

Nop schrieb:
> weil unions in C++ ohnehin
> keine eigenen Konstruktoren, Destruktoren usw. enthalten dürfen

Doch, dürfen sie. Das macht sich z.B. std::variant zunutze. Warum auch 
nicht - unions sind dazu da, Speicher zu sparen indem man im selben 
Bereich nacheinander unterschiedliche Objekte anlegt, statt sie ständig 
"parallel" herumliegen zu haben. Das soll dann natürlich auch mit 
Klassen funktionieren, welche Konstruktoren haben usw.

Nop schrieb:
> woher
> sollte der Compiler auch wissen, welchen er bei der Deklaration aufrufen
> soll.

Je nachdem welcher Member im Konstruktor der union selbst initialisiert 
wird.

Bei so einem Konstrukt
1
#include <string>
2
#include <iostream>
3
4
using std::string;
5
6
union Foo {
7
  Foo () : str ("foo") {}
8
  ~Foo () { str.~string(); }
9
10
  string str;
11
  float f;
12
};
13
14
int main () {
15
  Foo f;
16
  std::cout << f.f << std::endl;
17
}

Was soll da rauskommen? Die Ausgabe ist jedes Mal eine andere. Weil das 
UB ist, darf der Compiler das Programm komplett verunstalten.

von Nop (Gast)


Lesenswert?

Niklas G. schrieb:

> Doch, dürfen sie.

Nee, ich meinte das als union von Klassen, die ihrerseits Konstruktoren 
haben. Das geht nicht, d.h. im Wesentlichen kann man unions nur über 
PODs legen. Folglich ist die object lifetime hier kein spezieller 
Gesichtspunkt gegen type punning.

von Niklas Gürtler (Gast)


Lesenswert?

Nop schrieb:
> Nee, ich meinte das als union von Klassen, die ihrerseits Konstruktoren
> haben.

Ja, und das geht, wie im Beispiel gezeigt - string hat einen Konstruktor 
und Destruktor!

Nop schrieb:
> Das geht nicht, d.h. im Wesentlichen kann man unions nur über PODs
> legen.

Nein, du kannst beliebige Klassen in eine union legen, wie eben string, 
vector, und auch solche mit virtuellen Funktionen. Sehr praktisch um auf 
Systemen mit wenig Speicher (Mikrocontroller) das State Pattern zu 
implementieren.

von mh (Gast)


Lesenswert?

Nop schrieb:
> Niklas G. schrieb:
>
>> Doch, dürfen sie.
>
> Nee, ich meinte das als union von Klassen, die ihrerseits Konstruktoren
> haben. Das geht nicht, d.h. im Wesentlichen kann man unions nur über
> PODs legen. Folglich ist die object lifetime hier kein spezieller
> Gesichtspunkt gegen type punning.

Bist du sicher, dass du von C++ redest?

von Wilhelm M. (wimalopaan)


Lesenswert?

Nop schrieb:
> Niklas G. schrieb:
>
>> Doch, dürfen sie.
>
> Nee, ich meinte das als union von Klassen, die ihrerseits Konstruktoren
> haben. Das geht nicht, d.h. im Wesentlichen kann man unions nur über
> PODs legen. Folglich ist die object lifetime hier kein spezieller
> Gesichtspunkt gegen type punning.

Ich glaube, Du weißt nicht sehr viel über C++.

Aber wenn Du so etwas unbedingt in Frage stellen willst, dann mach bitte 
einen eigenen Thread dazu auf.

von Nop (Gast)


Lesenswert?

Niklas Gürtler schrieb:

> Nein, du kannst beliebige Klassen in eine union legen, wie eben string,
> vector, und auch solche mit virtuellen Funktionen.

https://en.cppreference.com/w/cpp/language/union sagt mir:

"A union can have member functions (including constructors and 
destructors), but not virtual functions."

Und das galt nur bis C++11:

"Unions cannot contain a non-static data member with a non-trivial 
special member function (copy constructor, copy-assignment operator, or 
destructor)."

OK, dann verstehe ich Wilhelms Argument mit der object lifetime auch.

von Wilhelm M. (wimalopaan)


Lesenswert?

Die "kleinen" Features sind manchmal die nützlichsten:

https://www.youtube.com/watch?v=Xb6u8BrfHjw

Und mein "Liebling" constinit kommt auch vor (nicht dort erwähnt, 
vermeidet aber auch _guards für statics).

von Vincent H. (vinci)


Lesenswert?

Wilhelm M. schrieb:
> Und mein "Liebling" constinit kommt auch vor (nicht dort erwähnt,
> vermeidet aber auch _guards für statics).

Was sich bisher durch -fno-threadsafe-statics aber auch vermeiden ließ.

von Wilhelm M. (wimalopaan)


Lesenswert?

Vincent H. schrieb:
> Wilhelm M. schrieb:
>> Und mein "Liebling" constinit kommt auch vor (nicht dort erwähnt,
>> vermeidet aber auch _guards für statics).
>
> Was sich bisher durch -fno-threadsafe-statics aber auch vermeiden ließ.

Leider nicht komplett: zwar wurden oft die lock/count-calls nicht 
generiert, dafür hatte man die _guards trotzdem.

Außerdem wirkt -fno-threadsafe-statics nur auf local-statics und nicht 
auf static-members oder globals.

von Vincent H. (vinci)


Lesenswert?

Ah gut zu wissen. Muss demnächst mal checkn ob das keyword im gcc oder 
clang trunk schon existiert.

von Wilhelm M. (wimalopaan)


Lesenswert?

Vincent H. schrieb:
> Ah gut zu wissen. Muss demnächst mal checkn ob das keyword im gcc oder
> clang trunk schon existiert.

Ja, tut es.

s.a. https://en.cppreference.com/w/cpp/compiler_support

von Vincent H. (vinci)


Lesenswert?

Absolut fantastischer Talk von Matt Godbolt über die Entwicklung eines 
Path-Tracers in 3 verschiedenen Paradigmen (OO, FP und data-oriented)

https://youtu.be/HG6c4Kwbv4I

Leider gegen Ende auch etwas traurig da er aufzeigt dass man als 
Entwickler in Zeiten von Caches und Branch-Prediction Punkto Performance 
weniger Mitspracherecht besitzt als einem vielleicht lieb wär...

von S. R. (svenska)


Lesenswert?

Ja, der Vortrag ist super; danke.

Das Ende zeigt in erster Linie nur, dass man in Bezug auf Performance 
nicht nur wenig Mitspracherecht hat, sondern dass alle Ansätze sehr 
empfindlich auf Kleinigkeiten reagieren können.

Ich sehe zwei wesentliche Punkte als Schlussfolgerung für mich:
- für kleine Mikrocontroller sollte die DoD-Variante (effektiv "C-Code 
mit STL") wesentlich effizienter sein als die Alternativen, weil nur die 
Hälfte an Instruktionen nötig sind;
- für große Prozessoren ist Lowlevel-Optimierung auf dieser Ebene für 
mich irrelevant, da die Performance-Schwankungen zu groß sind - würde 
sich nicht lohnen, lesbarer Code ist wichtiger.

: Bearbeitet durch User
von Wilhelm M. (wimalopaan)


Lesenswert?

Nicht neu, aber immer wieder erwähnenswert (sollten sich auch die C 
Leute mal anschauen):

https://www.youtube.com/watch?v=KJW_DLaVXIY

Die entsprechenden Warnungen sind im gcc-trunk schon umgesetzt, was ich 
sehr lobenswert finde.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Es wäre nett, wenn es zusätzlich zu den DeineRöhre-Links noch eine kurze 
Zusammenfassung des Inhalts gäbe. Nicht jeder wird sich, nur weil jemand 
einen Vortrag ganz toll findet, einfach mal so XXX Minuten Videos 
angucken wollen, wenn er vorher noch gar nicht weiß, ob ihn das Thema 
wirklich sooo brennend interessiert.

von Wilhelm M. (wimalopaan)


Lesenswert?

Jörg W. schrieb:
> Es wäre nett, wenn es zusätzlich zu den DeineRöhre-Links noch eine kurze
> Zusammenfassung des Inhalts gäbe. Nicht jeder wird sich, nur weil jemand
> einen Vortrag ganz toll findet, einfach mal so XXX Minuten Videos
> angucken wollen, wenn er vorher noch gar nicht weiß, ob ihn das Thema
> wirklich sooo brennend interessiert.

Wozu? Ein Klick auf den Link und Du hast das Video, und jeder 
Vortragende fängt mit einer Agenda an, so wie sich das gehört. Da hast 
Du doch alle Infos, zudem auch einen Eindruck vom Vortragenden selbst 
inkl. seiner sprachlichen Qualitäten.

von Carl D. (jcw2)


Lesenswert?

Wilhelm M. schrieb:
> Nicht neu, aber immer wieder erwähnenswert (sollten sich auch die C
> Leute mal anschauen):
>
> https://www.youtube.com/watch?v=KJW_DLaVXIY
>
> Die entsprechenden Warnungen sind im gcc-trunk schon umgesetzt, was ich
> sehr lobenswert finde.

Obwohl er eigentlich recht hat, hätte ich mir etwas mehr "dafür braucht 
man es wirklich" gewünscht. Und weniger "keine Ahnung warum, aber es 
scheint zu manchmal helfen".

von mh (Gast)


Lesenswert?

Wilhelm M. schrieb:
> Jörg W. schrieb:
>> Es wäre nett, wenn es zusätzlich zu den DeineRöhre-Links noch eine kurze
>> Zusammenfassung des Inhalts gäbe. Nicht jeder wird sich, nur weil jemand
>> einen Vortrag ganz toll findet, einfach mal so XXX Minuten Videos
>> angucken wollen, wenn er vorher noch gar nicht weiß, ob ihn das Thema
>> wirklich sooo brennend interessiert.
>
> Wozu? Ein Klick auf den Link und Du hast das Video, und jeder
> Vortragende fängt mit einer Agenda an, so wie sich das gehört. Da hast
> Du doch alle Infos, zudem auch einen Eindruck vom Vortragenden selbst
> inkl. seiner sprachlichen Qualitäten.

Zusätzlich gibt es auf youtube für das Video einen kurzen Text des 
Vortragenden.

von Yalu X. (yalu) (Moderator)


Lesenswert?

Damit Wilhelm nicht die Links sämtlicher 920 CppCon-Videos einzeln
posten muss:

Hier sind sie alle auf einmal:

  https://www.youtube.com/user/CppCon/videos

Da kann sich jeder genau das aussuchen, was ihn persönlich am meisten
interessiert.

PS: Der wahre C++-Freak klickt jetzt einfach auf "PLAY ALL" und lehnt
sich für die nächsten fünfeinhalb Wochen entspannt in seinem Sessel
zurück ;-)

von Nop (Gast)


Lesenswert?

Wilhelm M. schrieb:

> Youtube-Video "CppCon 2019: JF Bastien “Deprecating volatile”"

Das mit den Bitfields und Register: So verwendet man Bitfields nicht, 
weil der Standard nicht definiert, wie die Bits im Bitfield angeordnet 
sind.

Den "Verbesserungsvorschlag" an sich finde ich z.T. sinnfrei, weil man 
bei "x=x+1" ebensowenig wie bei "x+=1" oder "++x" weiß, ob das atomar 
ist oder nicht, weil das eh vom Befehlssatz der CPU und außerdem dem 
Datentyp von x abhängt.

Es fügt lediglich eine neue Regel hinzu, daß bei volatile-Variablen der 
übliche syntaktische Zucker auf einmal nicht mehr funktioniert. IMO ein 
nerviges Antifeature.

von Wilhelm M. (wimalopaan)


Lesenswert?

Nop schrieb:
> Wilhelm M. schrieb:
>
>> Youtube-Video "CppCon 2019: JF Bastien “Deprecating volatile”"
>
> Das mit den Bitfields und Register: So verwendet man Bitfields nicht,
> weil der Standard nicht definiert, wie die Bits im Bitfield angeordnet
> sind.

Darüber spricht er auch nicht. Er prangert nur an, dass für diesen Fall 
die Bedeutung von volatile nicht klar definiert ist, wie an vielen 
anderen Stellen auch.

> Den "Verbesserungsvorschlag" an sich finde ich z.T. sinnfrei, weil man
> bei "x=x+1" ebensowenig wie bei "x+=1" oder "++x" weiß, ob das atomar
> ist oder nicht, weil das eh vom Befehlssatz der CPU und außerdem dem
> Datentyp von x abhängt.

volatile und atomic hat auch nichts miteinander zu tun. Bei einem 
volatile x = x + 1; ist es klar, dass explizite load/store (und damit 
nicht atomare) Instruktionen generiert werden müssen. Bei ++x; erscheint 
das nicht so klar. Es geht bei dieser speziellen Ausprägung "nur" um die 
Intentionalität des Codes. Deswegen wurde auch ein ganz anderes API wie 
volatile_store() / volatile_load() vorgeschlagen, um die 
nicht-notwendige Atomarizität deutlich zu machen.

> Es fügt lediglich eine neue Regel hinzu, daß bei volatile-Variablen der
> übliche syntaktische Zucker auf einmal nicht mehr funktioniert. IMO ein
> nerviges Antifeature.

Für mich das genaue Gegenteil.

von Rolf M. (rmagnus)


Lesenswert?

Jörg W. schrieb:
> DeineRöhre-Links

DuRöhre, nicht DeineRöhre.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Rolf M. schrieb:
> Jörg W. schrieb:
>> DeineRöhre-Links
>
> DuRöhre, nicht DeineRöhre.

ok :)

von Wilhelm M. (wimalopaan)


Lesenswert?

Ich glaube der hier

https://www.youtube.com/watch?v=KAWA1DuvCnQ

von Scott wurde noch nicht hier gelistet.
Ein amüsanter, augenzwinkernder Vortrag, der wohl auch über so ziemlich 
jede Sprache und Ihre Bibliothek gehalten werden könnte. Trotzdem: er 
enthält eine sehr wichtige Botschaft.

von Vincent H. (vinci)


Lesenswert?

Ich mag Talks die für ein Problem verschiedene Lösungen präsentieren:
https://youtu.be/fwXaRH5ffJM

von mh (Gast)


Lesenswert?

Vincent H. schrieb:
> Ich mag Talks die für ein Problem verschiedene Lösungen präsentieren:
> Youtube-Video "[MUC++] Klaus Iglberger - Embrace No Paradigm
> Programming!"

Generell stimme ich dir zu, verschiedene Lösungen sind super. Er gibt 
einen ganz guten Überblick, über die verschiedenen Möglichkeiten. Aber 
die Bewertungskriterien sind für mich nicht wirklich nachvolliehbar.

Ein paar Dinge die mir beim gucken sofort aufgefallen sind (bitte nicht 
in diesem Thread die Punkte selbst diskutieren):
Warum z.B. bekommt die std::function Variante eine 7 bei "Seperation of 
Concerns"? Jede shape muss jede Operation kennen und zusätzlich noch die 
DrawStrategy. Was ist daran besser als bei der enum oder OO Variante? 
Und warum hat std::function die zweit beste Simplicity-Wertung? Wenn ich 
z.b. mit OpenGl auf den Bildschirm und zusätzlich als pdf zeichnen will, 
müssen alle shapes kopiert werden, damit sie ne andere Strategy bekommen 
können. Warum bekommt die variant Version so ne schlechte "Addition of 
Shapes" Bewertung? Ja, man muss alle Visitor modifizieren, aber der 
Compiler sagt einem, wo die sind, wenn man welche vergisst.

von Vincent H. (vinci)


Lesenswert?

Imho bester Überblick über concepts bis jetzt:
https://youtu.be/ut40iShzqEY

von Martin K. (Gast)


Lesenswert?

Ich sehe keinen Unterschied, ob ich für PCs oder MCUs entwickle. Es geht 
einzig um die Funktion, Struktur und Umfang des Programmes. Und wenn ich 
ein OS ansteuern möchte, braucht es MT-Unterstützung, die man in C 
einfach nicht hat.

von mh (Gast)


Lesenswert?

Cppcon ist vorbei und das erste Video ist auf youtube 
(https://www.youtube.com/channel/UCMlGfpWw-RUdWX_JbLCukXg) aufgetaucht. 
Mal schauen was dieses Jahr an interessanten Beiträgen dabei ist. Wenn 
es wie in den letzten Jahren läuft, dauert es einige Wochen, bis alle 
Beiträge online sind. Das Programm ist unter 
https://cppcon.org/program2020/ zu finden.

von Wilhelm M. (wimalopaan)


Lesenswert?

Meine Sichtweise scheint mittlerweile auch im Main-Stream angekommen zu 
sein:

https://www.b2bseminare.de/entwicklung/embedded-programmierung-mit-modernem-c/anmeldung

von Ben S. (bensch123)


Lesenswert?

Assembler: Wird nur noch benutzt, wenn es wirklich absolut nicht anders 
geht, sprich zur Optimierung. Ganze Projekte in Assembler habe ich nur 
zu Anfang gemacht, fand das damals cool - würde ich aber heute 
konsequenterweise grundsätzlich ablehnen.
C: Wird nur noch angewendet, wenn C++ nicht zur Verfügung steht.
C++: Ist auf Mikrocontrollern für mich inzwischen Standard. Da die 
meisten auf ARM basieren, ist in der Regel C++ möglich. Auch AVR lassen 
sich mit C++ programmieren.

Also auf C oder Assembler weiche ich selbst bei kleinen Mikrocontrollern 
nur noch im Notfall aus. Assembler nur noch zur Optimierung einzelner 
Stellen. Und da andere Sprachen eh Mangelware sind, ist das das Mittel 
der Wahl.

: Bearbeitet durch User
von Wilhelm M. (wimalopaan)


Lesenswert?

Ben S. schrieb:
> C: Wird nur noch angewendet, wenn C++ nicht zur Verfügung steht.

Oh ha, dann bist Du wohl noch nicht lang in diesem Forum ;-)

von Ben S. (bensch123)


Lesenswert?

Wilhelm M. schrieb:
> Oh ha, dann bist Du wohl noch nicht lang in diesem Forum ;-)

Angemeldet seit 24.10.2019 09:12 - bin jedoch in Wirklichkeit schon seit 
über 10 Jahren dabei. Ich Autist verstehe deine Anmerkung dennoch nicht 
😁 ... ja der Thread wurde ausm Grab geholt.

von Wilhelm M. (wimalopaan)


Lesenswert?

Ben S. schrieb:
> Ich Autist verstehe deine Anmerkung dennoch nicht

In diesem Forum wird ja C++ für µC regelmäßig verteufelt. Ich habe da 
seit Jahren eine andere Sichtweise, und es gab/gibt immer noch 
entsprechende Kommentare. Doch nun scheint die Erkenntnis auch bei 
solchen Hochglanz-Seminaren angekommen zu sein. Wobei in der ernsthaften 
Entwicklerwelt sich das Thema "Modernes C++ auf µC" doch schon mehr 
durchgesetzt hat.

von Carl D. (jcw2)


Lesenswert?

Ben S. schrieb:
> Wilhelm M. schrieb:
>> Oh ha, dann bist Du wohl noch nicht lang in diesem Forum ;-)
>
> Angemeldet seit 24.10.2019 09:12 - bin jedoch in Wirklichkeit schon seit
> über 10 Jahren dabei.  Ich Autist verstehe deine Anmerkung dennoch nicht

Es ging um die Verteilung der Vorlieben. Viele mögen C++ nicht, weil 
angeblich viel zu fett für arme kleine Rechner. Manche hassen sogar 
alles, was mit C anfängt.

> 😁 ... ja der Thread wurde ausm Grab geholt.

Das ist eher ein schlafender Thread, der an so Dinge wie "es ist wieder 
CppCon-Zeit" erinnern soll. Traffic hat der nur, wenn es keine 
Alternativen gibt. Aktuell läuft "weshalb Linux so blöd ist" auf einem 
Parallel-Thread, da bleibt es hier ruhig.

von Jan (Gast)


Lesenswert?

Wilhelm M. schrieb:
> Doch nun scheint die Erkenntnis auch bei solchen Hochglanz-Seminaren
> angekommen zu sein.

Naja, c++ für embedded (auch Cortex m3) Kurse gibt's aber schon länger, 
zb von microconsult oder beningo.

Tatsächlich überlege ich aber gerade, welche Fortbildung nächstes Jahr 
sinnvoller ist. Wollen über den Tellerrand gucken. C++ oder Rust. 
Speziell Richtung testen von kleinen eingebetteten Systemen. Fundiertes 
C Wissen ist vorhanden, C++ sehr rudimentär, wobei ich die Features der 
neueren Versionen und dem was hier so vorgestellt wird auch sehr 
interessant finde.

Meinungen?

Beitrag #6416608 wurde von einem Moderator gelöscht.
Beitrag #6416919 wurde von einem Moderator gelöscht.
Beitrag #6417006 wurde von einem Moderator gelöscht.
von Vincent H. (vinci)


Lesenswert?

Wilhelm M. schrieb:
> Meine Sichtweise scheint mittlerweile auch im Main-Stream angekommen zu
> sein:
>
> 
https://www.b2bseminare.de/entwicklung/embedded-programmierung-mit-modernem-c/anmeldung

Rainer Grimm is für mich ein BWLer der C++ unterrichtet.
Ich find seine Artikel stilistisch katastrophal und bei seinem 
"Englisch" bekomm ich Brechreiz.

Beitrag #6417223 wurde von einem Moderator gelöscht.
Beitrag #6417243 wurde von einem Moderator gelöscht.
Beitrag #6417296 wurde von einem Moderator gelöscht.
von Wilhelm M. (wimalopaan)


Lesenswert?

Der Vollständigkeit wegen hier auch mal angefügt:

Beitrag "std::bit_cast nun auch im gcc / avr-gcc"

von Christoph M. (mchris)



Lesenswert?

Lange Nacht der Programmiersprachen, DLF: Ausschnitt mit einer 
Sichtweise auf C++.

von Wilhelm M. (wimalopaan)


Lesenswert?

Christoph M. schrieb:
> DLF: Ausschnitt mit einer
> Sichtweise auf C++.

Völlig sinnfrei: kann über jede (Programmier-)Sprache gesagt werden.

von Robert K. (Firma: Zombieland) (rko)


Lesenswert?

Wilhelm M. schrieb:
> der Titel sagt es schon: es geht um das (alte) Thema: C vs C++ für
> eingebettete Systeme / MCUs.
Du hast das Thema verfehlt, weil Deine Links (habe nicht alle probiert) 
entweder schon gestorben sind (z.B. erster Link) oder aber zu 99% C++ 
behandeln.
Schade, weil die Idee mit der Linksammlung gut war.
Benenne das Thema in Embedded Programmierung mit C++ um, dann stimmt es 
:-)

von Wilhelm M. (wimalopaan)


Lesenswert?

Robert K. schrieb:
> Du hast das Thema verfehlt, weil Deine Links (habe nicht alle probiert)
> entweder schon gestorben sind (z.B. erster Link) oder aber zu 99% C++
> behandeln.

Tja, Du kommst eben mindestens 4 Jahre zu spät ...

von Vincent H. (vinci)


Lesenswert?

Ben Deane über 'deducing this'
https://youtu.be/jXf--bazhJw

In meinen Augen das wohl sinnvollste C++23 (?) Feature für die Embedded 
Entwicklung.

von Mombert H. (mh_mh)


Lesenswert?

Vincent H. schrieb:
> Ben Deane über 'deducing this'
> https://youtu.be/jXf--bazhJw
>
> In meinen Augen das wohl sinnvollste C++23 (?) Feature für die Embedded
> Entwicklung.

Von den Features, die bis jetzt sicher sind. Und ich würde das Embedded 
aus der Aussage streichen ;-)

von Wilhelm M. (wimalopaan)


Lesenswert?

Und das leidige Thema der views (und des non-propagating-const) mal 
schön dargestellt:

https://www.youtube.com/watch?v=O8HndvYNvQ4

von Rolf M. (rmagnus)


Lesenswert?

Wilhelm M. schrieb:
> Und das leidige Thema der views (und des non-propagating-const) mal
> schön dargestellt:

Na danke. Jetzt habe ich das Gefühl, dass die Standardisierungsgruppe 
komplett den Verstand verloren hat…

von Wilhelm M. (wimalopaan)


Lesenswert?

Rolf M. schrieb:
> Wilhelm M. schrieb:
>> Und das leidige Thema der views (und des non-propagating-const) mal
>> schön dargestellt:
>
> Na danke. Jetzt habe ich das Gefühl, dass die Standardisierungsgruppe
> komplett den Verstand verloren hat…

Das gab es in der Vergangenheit auch schon mehrfach. man denke an 
std::auto_ptr<> oder std::thread<>.

von Rolf M. (rmagnus)


Lesenswert?

Naja, auto_ptr war dann doch von den Auswirkungen her deutlich 
begrenzter als die Views. Ich bin aktuell noch bei C++17, aber nach dem 
Vortrag werde ich die Views wahrscheinlich nicht einsetzen, weil sie 
einfach kaputt sind. Das sind mir zu viele Stolpersteine.
Leider scheint es auf Josuttis' github-Seite seine "Belleviews" nicht 
mehr zu geben. Weißt du, was damit passiert ist?

von Wilhelm M. (wimalopaan)


Lesenswert?

Rolf M. schrieb:
> Leider scheint es auf Josuttis' github-Seite seine "Belleviews" nicht
> mehr zu geben. Weißt du, was damit passiert ist?

Lizenzverletzung, daher musste das Repo erstmal gelöscht werden.

von Vincent H. (vinci)


Lesenswert?

Wilhelm M. schrieb:
> Rolf M. schrieb:
>> Wilhelm M. schrieb:
>>> Und das leidige Thema der views (und des non-propagating-const) mal
>>> schön dargestellt:
>>
>> Na danke. Jetzt habe ich das Gefühl, dass die Standardisierungsgruppe
>> komplett den Verstand verloren hat…
>
> Das gab es in der Vergangenheit auch schon mehrfach. man denke an
> std::auto_ptr<> oder std::thread<>.

Soll das eine Ausrede sein? :D

Wer glaubt Views sein schon böse, der möge sich mal anschaun wie viel 
Boilerplate man für eine Coroutine braucht...

von Wilhelm M. (wimalopaan)


Lesenswert?

Vincent H. schrieb:
> Soll das eine Ausrede sein? :D

Nein, eine Feststellung.

> Wer glaubt Views sein schon böse, der möge sich mal anschaun wie viel
> Boilerplate man für eine Coroutine braucht...

Da gibt es einen Unterschied: bei den coros braucht man zwar viel 
Codierungsaufwand, jedoch funktioniert es mehr oder weniger wie 
erwartet; und die coro-Baustelle ist definitiv noch nicht fertig. Es 
folgen convenience-wrapper in den nä. Ausgaben des Standards.

Bei std::auto_ptr<>, std::thread<> und jetzt auch std::views<> ist es 
broken-by-design bzw. broken-by-implementation.

von Robert K. (Firma: Zombieland) (rko)


Lesenswert?

Wilhelm M. schrieb:
> Tja, Du kommst eben mindestens 4 Jahre zu spät ...
mag sein, aber wenn Dir das Thema am Herzen liegt (was nicht der Fall zu 
sein scheint, wenn das Deine Antwort ist), dann macht man ein Update ... 
so ist der ganze Thread Schrott und kann bzw. sollte geschlossen werden, 
weil veraltet - aber der Moderation scheint das total egal zu sein.

von Wilhelm M. (wimalopaan)


Lesenswert?

Robert K. schrieb:
> Wilhelm M. schrieb:
>> Tja, Du kommst eben mindestens 4 Jahre zu spät ...
> mag sein, aber wenn Dir das Thema am Herzen liegt (was nicht der Fall zu
> sein scheint, wenn das Deine Antwort ist), dann macht man ein Update ...

Die Updates kommen hier als Posts, das solltest Du auch gemerkt haben.

> so ist der ganze Thread Schrott und kann bzw. sollte geschlossen werden,
> weil veraltet - aber der Moderation scheint das total egal zu sein.

Viele hier stecken noch bei C++03/98 fest, oder beginnen gerade erst mit 
C++11 oder halten compile-time-computation, etc. für Teufelszeug.

von Mikro 7. (mikro77)


Lesenswert?

Wilhelm M. schrieb:
>> Na danke. Jetzt habe ich das Gefühl, dass die Standardisierungsgruppe
>> komplett den Verstand verloren hat…
>
> Das gab es in der Vergangenheit auch schon mehrfach. man denke an
> std::auto_ptr<> oder std::thread<>.

Ich wäre an einen Link interessiert: Was ist das Problem mit thread<>?

von Vincent H. (vinci)


Lesenswert?

Mikro 7. schrieb:
> Wilhelm M. schrieb:
>>> Na danke. Jetzt habe ich das Gefühl, dass die Standardisierungsgruppe
>>> komplett den Verstand verloren hat…
>>
>> Das gab es in der Vergangenheit auch schon mehrfach. man denke an
>> std::auto_ptr<> oder std::thread<>.
>
> Ich wäre an einen Link interessiert: Was ist das Problem mit thread<>?

Es ist kein RAI Typ. Wenn ein Thread das Scope verlässt und weder joined 
noch detached is, dann gibts Probleme.

von Robert K. (Firma: Zombieland) (rko)


Lesenswert?

Wilhelm M. schrieb:
> Die Updates kommen hier als Posts, das solltest Du auch gemerkt haben.
Wirklich? Dann sollte man wenigstens die toten Links entfernen ... das 
kostet nur unnötig Zeit.

Wilhelm M. schrieb:
> Viele hier stecken noch bei C++03/98 fest, oder beginnen gerade erst mit
> C++11 oder halten compile-time-computation, etc. für Teufelszeug.
Beide Sprachen, also C wie auch C++ sind mehr oder weniger tot, weil 
sich die Anwendungen und auch die Systemvoraussetzungen geändert haben - 
wie haben jetzt 2023.
Man kann mit C++03 oder auch C99 vollkommen auskommen, aber aktuell sind 
andere Sprachen angesagt, also sind C und C++ nur noch Nischen für 
Alt-Programme ... für Reparatur irgendwelcher fehlgeschlagenen Projekte 
und Anwendungen mit wenig Speicherplatz (also Mikrocontroller) macht C 
als auch C++ noch Sinn - aber das war's dann auch schon.
Aus Nostalgie-Gründen sind beide Sprache eine schöne Sache, aber sonst 
eine reine Nische ... und selbst die Nische fällt irgendwann weg, dann 
ist es nur noch Nostalgie.

von Wilhelm M. (wimalopaan)


Lesenswert?

Vincent H. schrieb:
> Mikro 7. schrieb:
>> Wilhelm M. schrieb:
>>>> Na danke. Jetzt habe ich das Gefühl, dass die Standardisierungsgruppe
>>>> komplett den Verstand verloren hat…
>>>
>>> Das gab es in der Vergangenheit auch schon mehrfach. man denke an
>>> std::auto_ptr<> oder std::thread<>.
>>
>> Ich wäre an einen Link interessiert: Was ist das Problem mit thread<>?
>
> Es ist kein RAI Typ.

RAII: ressource acquisition is initialization

std::thread ist schon ein RAII-like Ressourceverwalter, jedoch in 
"ungewöhnlicher" Form. Das Problem hierbei ist, das der Zustand des 
std::thread-Objektes extern bekannt sein muss, um den dtor korrekt 
aufrufen zu können. Wird der dtor im Zustand "joinable" aufgerufen, dann 
resultiert std::terminate. Dies ist broken-by-design, weil es auch die 
exception-safety torpediert (Abrahams guarantees).

Weiterhin gibt es keine "einfache, eingebaute" Möglichkeit, den Thread 
über std::thread (das Verwaltungsobjekt) abzubrechen.

Links dazu gibt es zu Hauf: google std::thread vs std::jthread

: Bearbeitet durch User
von Mikro 7. (mikro77)


Lesenswert?

Naja, man muss beachten dass ein Thread eine doch sehr spezielle 
Resource ist.

Wilhelm M. schrieb:
> Wird der dtor im Zustand "joinable" aufgerufen, dann
> resultiert std::terminate. Dies ist broken-by-design, weil es auch die
> exception-safety torpediert (Abrahams guarantees).

Broken-by-design impliziert für mich ein Design-Problem. Das sehe ich 
hier nicht. Der User kann ja den Thread detachen. Und für joinable 
Threads einen Wrapper drum-herum setzen (mache ich bspw. so). Klar, 
letzteres hätte die STL schon mitbringen können...

> Weiterhin gibt es keine "einfache, eingebaute" Möglichkeit, den Thread
> über std::thread (das Verwaltungsobjekt) abzubrechen.

Existiert im Prozess mehr als ein Thread, dann kann ein Abbruch zu einem 
undefinierten Prozesszustand führen. Das ist kein C++ Problem. Bekannte 
Workarounds: Thread sich selbst beenden lassen; dedizierten Prozess 
starten.

von Wilhelm M. (wimalopaan)


Lesenswert?

Mikro 7. schrieb:
> Naja, man muss beachten dass ein Thread eine doch sehr spezielle
> Resource ist.
>
> Wilhelm M. schrieb:
>> Wird der dtor im Zustand "joinable" aufgerufen, dann
>> resultiert std::terminate. Dies ist broken-by-design, weil es auch die
>> exception-safety torpediert (Abrahams guarantees).
>
> Broken-by-design impliziert für mich ein Design-Problem. Das sehe ich
> hier nicht. Der User kann ja den Thread detachen. Und für joinable
> Threads einen Wrapper drum-herum setzen (mache ich bspw. so). Klar,
> letzteres hätte die STL schon mitbringen können...

Wenn Du so argumentierst, braucht es std::thread gar nicht. Jeder kann 
sich seine eigene Variante schreiben.
Ein Schnittstelle sollte leicht einfach und nicht schwer falsch zu 
benutzen sein.

>> Weiterhin gibt es keine "einfache, eingebaute" Möglichkeit, den Thread
>> über std::thread (das Verwaltungsobjekt) abzubrechen.
>
> Existiert im Prozess mehr als ein Thread, dann kann ein Abbruch zu einem
> undefinierten Prozesszustand führen. Das ist kein C++ Problem.

In der Art wie std::thread existiert, ist es schon ein C++ Problem.

> Bekannte
> Workarounds: Thread sich selbst beenden lassen

Und genau das realisiert std::jthread. Problem gelöst in einer 
standardisierten Variante.

von Mikro 7. (mikro77)


Lesenswert?

Wilhelm M. schrieb:
> Wenn Du so argumentierst, braucht es std::thread gar nicht. Jeder kann
> sich seine eigene Variante schreiben.

Das gehst du ein bisschen zu weit. Vorher gab es in C++ gar keine 
Threads.

Mehr zum Thema, wen es interessiert, von Nicolai in einer Keynote:

https://www.youtube.com/watch?v=elFil2VhlH8

Da spricht er dann tatsächlich von einem Design Problem (wegen RAII). 
-.-

War mir so nie aufgefallen da ich Threads zum Pool und Exception 
Handling eh kapsele.

von Wilhelm M. (wimalopaan)


Lesenswert?

Mikro 7. schrieb:
> Wilhelm M. schrieb:
>> Wenn Du so argumentierst, braucht es std::thread gar nicht. Jeder kann
>> sich seine eigene Variante schreiben.
>
> Das gehst du ein bisschen zu weit.

Keineswegs.

> Vorher gab es in C++ gar keine
> Threads.

Man konnte schon immer das API des OS benutzen ;-)

von Wilhelm M. (wimalopaan)


Lesenswert?

Ein interessantes und lange überfälliges Paper für C++26:

https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2723r1.html

von Vincent H. (vinci)


Lesenswert?

Bin dafür, fürcht nur dass das keinen großen Anklang finden wird.

von Hans-Georg L. (h-g-l)


Angehängte Dateien:

Lesenswert?

Beitrag "Re: C++ in (deeply) Embedded Systemen für Neuprojekte"
In diesem Thread hatte ich geschrieben:
Meine Zutaten zur embedded Programmierung sind im Moment:
templates, scoped enums, meta programming, type_traits, requires,
concepts also C++20.

Ich muss es zuerst das embedded ein wenig einschränken, ich meine damit 
den reinen Hardware Zugriff über dedizierte Register. Embedded 
Algorithmen und Datenstrukturen sind damit nicht gemeint. Dafür ist die 
std Library da.

Also warum ?
Das übliche : void write_reg (unsigned regaddress, unsigned regvalue);
hat verschiedene Probleme. Als Parameter wird jeder unsigned int-wert 
und alles was der Compiler automatisch automatisch konvertiert 
akzeptiert (z.B. unscoped enums). Auch die Parameter können vertauscht 
werden. Compiler, Assembler und auch externe Tools können nichts dagegen 
tun. Man kann das alles ein wenig durch Vorschriften einschränken aber 
nicht sicher machen und es kann zu Laufzeitfehlern führen.
Klassisches C++ kennt Signaturen, das hilft aber in diesem Falle auch 
nichts (sind ja alles unsigned int). Also brauchen wir etwas das aus 
einem individuellen int einen Datentyp macht. Da kommen die Templates 
ins Spiel
und auch gleich die type_traits ;-) zum testen . Und weil wir den 
Laufzeitcode nicht aufblähen wollen lassen wir das alles zu Compilzeit 
machen ( meta-programming). Es werden also nur Template Instanzen und 
consteval functions erzeugt

<C>
#include <stdint.h>
#include <type_traits>

template< unsigned v>
struct uint_wrapper {
static constexpr unsigned val =v;
};
int main() {
// return std::is_same_v<int_wrapper<5>,int_wrapper<5> >;    // true
return std::is_same_v<uint_wrapper<3>,uint_wrapper<5> >;     // false
}
</C>

ARM GCC 11 erzeugt folgenden code
main:
        mov     r0, #0 bzw #1 wenn true
        bx      lr


Der nächste Schritt wir machen das ganze generisch
<c>
template< T v>
struct wrapper {
static constexpr T val = v;
}
</c>

Damit schaffen wir uns ein neues Problem ein double oder String macht 
als Registeradresse wenig Sinn. Wir müssen den generischen Typ auf 
sinnvolle Typen begrenzen und dann sind wir auch schon bei requires
und damit können wir auch die Values auf zulässige Werte begrenzen.

Fazit wir können uns eigene Anwendungs-Domain Datentypen schaffen.
Template strukturen können auch erben und man kann über die type_traits 
abfragen von wem sie abstammen. Man kann Template Strukturen mit 
zusätzlichen statischen Parametern versorgen wie z.B. Versionsnummern.

scoped enums erzeugen auch einen eindeutigen Datentyp, der erhalten 
bleibt und nicht automatisch nach dem underlying type gecastet wird wenn 
er als Parameter übergeben wird.

Es ist auch möglich damit eigene type_traits zu schreiben und die 
spezialisierung der templates für das Endprodukt zu steuern. usw. usw

Und manchmal muss man sich entscheiden andere Wege wie die std library 
zu gehen weil man auf die gegebene Hardware angewiesen ist und die hat 
weniger Freiheiten wie Softwarekonzepte.

Anbei noch ein snippet wo ich mit scoped enums und templates ohne
 requires und concepts mal angefangen habe einen STM32F Timer bis 
herunter zu den register-field-values zu modelieren.  Leider sind die 
zulässigen field values nicht in den svd files definiert und alles muss 
man aus den datenblätter lesen. Der Rest lässt sich so ziemlich 
automatisch generieren.

von Wilhelm M. (wimalopaan)


Lesenswert?

Hans-Georg L. schrieb:
> Das übliche : void write_reg (unsigned regaddress, unsigned regvalue);
> hat verschiedene Probleme. Als Parameter wird jeder unsigned int-wert
> und alles was der Compiler automatisch automatisch konvertiert
> akzeptiert (z.B. unscoped enums).

Mehrstellige Funktionen mit Parametern derselben Typen ist immer eine 
schlechte Idee!!! Das sind Basics.

> Auch die Parameter können vertauscht
> werden. Compiler, Assembler und auch externe Tools können nichts dagegen
> tun. Man kann das alles ein wenig durch Vorschriften einschränken aber
> nicht sicher machen und es kann zu Laufzeitfehlern führen.

Man braucht keine Vorschriften ...

> Klassisches C++ kennt Signaturen, das hilft aber in diesem Falle auch
> nichts (sind ja alles unsigned int).

Doch.

> Also brauchen wir etwas das aus
> einem individuellen int einen Datentyp macht. Da kommen die Templates
> ins Spiel

Dazu braucht es keine Templates.
Es reicht:
1
void write_reg (Address a, uint32_t value);

> und auch gleich die type_traits ;-) zum testen . Und weil wir den
> Laufzeitcode nicht aufblähen wollen lassen wir das alles zu Compilzeit
> machen ( meta-programming).

Unter TMP wird schon ein wenig mehr verstanden.

von J. S. (jojos)


Lesenswert?

Und wenn value nur 1, 2 oder 3 sein darf?
Das Problem ist eher das man für die komplexe Peripherie eines H7 zB 
nicht alles selber neu erfinden möchte. Und HAL benutzt als kleinsten 
gemeinsamen Nenner ‚nur‘ C.

von Hans-Georg L. (h-g-l)


Lesenswert?

Wilhelm M. schrieb:
> Hans-Georg L. schrieb:
>> Das übliche : void write_reg (unsigned regaddress, unsigned regvalue);
>> hat verschiedene Probleme. Als Parameter wird jeder unsigned int-wert
>> und alles was der Compiler automatisch automatisch konvertiert
>> akzeptiert (z.B. unscoped enums).
>
> Mehrstellige Funktionen mit Parametern derselben Typen ist immer eine
> schlechte Idee!!! Das sind Basics.
>
findest du aber in sehr vielen Programmen. Das es schlecht ist sind wir 
einer Meinung

>> Auch die Parameter können vertauscht
>> werden. Compiler, Assembler und auch externe Tools können nichts dagegen
>> tun. Man kann das alles ein wenig durch Vorschriften einschränken aber
>> nicht sicher machen und es kann zu Laufzeitfehlern führen.
>
> Man braucht keine Vorschriften ...
>
>> Klassisches C++ kennt Signaturen, das hilft aber in diesem Falle auch
>> nichts (sind ja alles unsigned int).
>
> Doch.
>
>> Also brauchen wir etwas das aus
>> einem individuellen int einen Datentyp macht. Da kommen die Templates
>> ins Spiel
>
> Dazu braucht es keine Templates.
> Es reicht:
>
>
1
> void write_reg (Address a, uint32_t value);
2
>
>
Einfach Address ist kein Schlüsselwort oder Datentyp.
Und eine Möglichkeit aus einem einfachen int einen datentyp zu machen 
ist über ein struct template.  Gut der Zusammenhang zu dem write_reg 
fehlt bei mir.

>> und auch gleich die type_traits ;-) zum testen . Und weil wir den
>> Laufzeitcode nicht aufblähen wollen lassen wir das alles zu Compilzeit
>> machen ( meta-programming).
>
> Unter TMP wird schon ein wenig mehr verstanden.

Das ist doch auch klar
Ich wollte einfach zu jedem Begriff den ich geschrieben habe ein 
Beispiel geben, keine erschöpfende Abhandlung schreiben und möglichst 
verständlich für Anfänger bleiben.

von Wilhelm M. (wimalopaan)


Lesenswert?

Hans-Georg L. schrieb:
> Einfach Address ist kein Schlüsselwort oder Datentyp.

Was? Natürlich ist Address ein DT, eben ein UDT.

von Hans-Georg L. (h-g-l)


Lesenswert?

J. S. schrieb:
> Und wenn value nur 1, 2 oder 3 sein darf?
dann nimmst du anstelle uint32_t ein (scoped) enum.
> Das Problem ist eher das man für die komplexe Peripherie eines H7 zB
> nicht alles selber neu erfinden möchte. Und HAL benutzt als kleinsten
> gemeinsamen Nenner ‚nur‘ C.

Das ist ja das Problem für so einen Boliden etwas eigenes zu schreiben 
kostet wahnsinnig viel Zeit.
Aus eigener Erfahrung ... wenn es komplizierter wird kannst du dich auf 
die HAL und den von CubeMX erzeugten Code auch nicht immer verlassen ... 
Fehlersuche kostet auch viel Zeit.

von A. B. (Firma: ab) (bus_eng)


Lesenswert?

Hans-Georg L. schrieb:

> Das ist ja das Problem für so einen Boliden etwas eigenes zu schreiben
> kostet wahnsinnig viel Zeit.

Etwas eigenes zu schreiben wäre nicht nötig, wenn es etwas brauchbares 
gäbe und eine Community vorhanden wäre. Deshalb zieht Arduino die Massen 
so magisch an.

Ich kenne zwei brauchbare "c++ Template-Boliden". Einer ist etwas älter 
und einfacher, der andere sehr aktuell aber offenbar geheim. Normale 
Programmierer nutzen Werkzeuge die verfügbar und verständlich sind.
Ohne Grundgerüst, nur mit Stichworten und Hinweisen wird das nix. So 
bleibt ein tolles Werkzeug Spielwiese für einige hochbegabte Experten.

Das Code-Snippet von Hans-Georg L. zeigt in die richtige Richtung.

Es braucht aber ein funktionierendes c++ Gerüst mit templates/concepts, 
das auf Source-Code Ebene die Abstraktion sichtbar und auch begreifbar 
macht und anhand von Beispielen die Anwendung erklärt. Mehr kommt von 
selber, wenn das Interesse einmal geweckt ist ..

Andernfalls bleibt es akademisch.

von Hans-Georg L. (h-g-l)


Lesenswert?

Wilhelm M. schrieb:
> Hans-Georg L. schrieb:
>> Einfach Address ist kein Schlüsselwort oder Datentyp.
>
> Was? Natürlich ist Address ein DT, eben ein UDT.
Wo und wie ist er bitte definiert ? cppreference.com kennt ihn nicht.

Entweder wir reden aneinander vorbei, oder auf verschiedenen Ebenen, 
oder ich steh einfach auf dem Schlauch ;-)

von Wilhelm M. (wimalopaan)


Lesenswert?

Hans-Georg L. schrieb:
> Wilhelm M. schrieb:
>> Hans-Georg L. schrieb:
>>> Einfach Address ist kein Schlüsselwort oder Datentyp.
>>
>> Was? Natürlich ist Address ein DT, eben ein UDT.
> Wo und wie ist er bitte definiert ? cppreference.com kennt ihn nicht.

Natürlich nicht, ich schrieb ja auch UDT = user-defined-type.
1
struct Address {
2
    const uint32_t value;
3
};

> Entweder wir reden aneinander vorbei, oder auf verschiedenen Ebenen,
> oder ich steh einfach auf dem Schlauch ;-)

Schlauch.
1
void write(Address, uint32_t);
2
3
...
4
5
write(Address{0x100}, 42);

Wenn Du willst, kannst Du die Parameterliste auch permutieren. Dann geht 
auch:
1
write(42, Address{0x100});

von Hans-Georg L. (h-g-l)


Lesenswert?

Wilhelm M. schrieb:
> Hans-Georg L. schrieb:
>> Wilhelm M. schrieb:
>>> Hans-Georg L. schrieb:
>>>> Einfach Address ist kein Schlüsselwort oder Datentyp.
>>>
>>> Was? Natürlich ist Address ein DT, eben ein UDT.
>> Wo und wie ist er bitte definiert ? cppreference.com kennt ihn nicht.
>
> Natürlich nicht, ich schrieb ja auch UDT = user-defined-type.
>
>
1
> struct Address {
2
>     const uint32_t value;
3
> };
4
>
>
>> Entweder wir reden aneinander vorbei, oder auf verschiedenen Ebenen,
>> oder ich steh einfach auf dem Schlauch ;-)
>
> Schlauch.
>
>
1
> void write(Address, uint32_t);
2
> 
3
> ...
4
> 
5
> write(Address{0x100}, 42);
6
>
>
> Wenn Du willst, kannst Du die Parameterliste auch permutieren. Dann geht
> auch:
>
>
1
> write(42, Address{0x100});
2
>

Da sind wir doch schon wieder beieinander ;-)
Die write_reg funktion stammt aus C-code, das habe ich nicht explizit 
geschrieben OK.
Die "Arbeit" der Typwandlung macht die struct, dazu ist kein template 
notwendig. Ok

Das Template brauche ich erst wenn ich Adressen parametrieren möchte und 
getrennte Datentypen für verschiedene Adressen haben will. Das war die 
Absicht siehe: is_same in main ;-)

noch Einwände oder Fragen ?

von Hans-Georg L. (h-g-l)


Lesenswert?

A. B. schrieb:
> Hans-Georg L. schrieb:
>
>> Das ist ja das Problem für so einen Boliden etwas eigenes zu schreiben
>> kostet wahnsinnig viel Zeit.
>
> Etwas eigenes zu schreiben wäre nicht nötig, wenn es etwas brauchbares
> gäbe und eine Community vorhanden wäre. Deshalb zieht Arduino die Massen
> so magisch an.
>
> Ich kenne zwei brauchbare "c++ Template-Boliden". Einer ist etwas älter
> und einfacher, der andere sehr aktuell aber offenbar geheim. Normale
> Programmierer nutzen Werkzeuge die verfügbar und verständlich sind.
> Ohne Grundgerüst, nur mit Stichworten und Hinweisen wird das nix. So
> bleibt ein tolles Werkzeug Spielwiese für einige hochbegabte Experten.
>
Eine List mit Quellcodes zu dem Thema

 Arduino:
 https://github.com/arduino/

 mBed:
 https://os.mbed.com/mbed-os/

 C++ library bit-fields:
 https://github.com/wkaras/C-plus-plus-library-bit-fields

 embxx
 https://github.com/arobenko/embxx

 jaxos:
 https://sourceforge.net/p/jaxos/code/HEAD/tree/trunk/

 kvasir:
 https://github.com/kvasir-io/Kvasir

 libstm32pp:
 https://github.com/JorgeAparicio/libstm32pp

 mcucpp:
 https://github.com/KonstantinChizhov/Mcucpp

 openmptl:
 https://github.com/digint/openmptl

 PeripheralTemplateLibrary:
 https://github.com/pfalcon/PeripheralTemplateLibrary

 Real Time C++ (Buch von Christopher Kormanyos) ref_app
 https://github.com/ckormanyos/real-time-cpp

 stm32f103 template lib:
 https://github.com/ekoeppen/stm32f103-template-lib

 Stm32-Template-Gpio-Library:
 https://github.com/ThatEmbeddedGuy/Stm32-Template-Gpio-Library

von A. B. (Firma: ab) (bus_eng)


Lesenswert?

Danke für die Literatur-Liste.

von Torsten R. (Firma: Torrox.de) (torstenrobitzki)


Lesenswert?

Hans-Georg L. schrieb:

> Eine List mit Quellcodes zu dem Thema

Bluetooth für kleine Microcontroller (Bluetoe):

https://github.com/TorstenRobitzki/bluetoe

von Wilhelm M. (wimalopaan)


Lesenswert?

Hans-Georg L. schrieb:
> Die write_reg funktion stammt aus C-code, das habe ich nicht explizit
> geschrieben OK.

Zumindest habe ich es nicht gelesen!

> Das Template brauche ich erst wenn ich Adressen parametrieren möchte und
> getrennte Datentypen für verschiedene Adressen haben will.

Ja, kann man machen.

> Das war die
> Absicht siehe: is_same in main ;-)

Das Beispiel sagt nur, dass Du std::integral_constant<> halb nachgebaut 
hast.

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.