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!
:
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.
wer soll denn das alles lesen? C++: nicht lange diskutieren, just do it und fertig.
Johannes S. schrieb: > C++: nicht lange diskutieren, just > do it > und fertig. Nach zwei Jahren C++ Studium und mit dickem MC zur Hand :)
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.
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
Ein schöner Vortrag von Bjarne: https://isocpp.org/blog/2016/12/bjarne-stroustrup-meeting-cpp-2016-keynote-what-c-is-and-what-it-will-becom
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.
https://www.youtube.com/watch?v=PJwd4JLYJJY&index=15&list=PLHTh1InhhwT6bwIpRk0ZbCA0N2p1taxd6 Ben Deane is ein Genie... Wahnsinn.
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) ...
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.
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
Vincent H. schrieb: > der ASM/C Fraktion Es geht halt nichts über ein gut gepflegtes Vorurteil – oder was soll diese Bezeichnung sonst sein?
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
Raoul D. schrieb: > Dafür gibt es schon genug andere Sehe ich auch so, daher meine Kritik an Vincents unsinnigem Vorurteil.
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.
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
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.
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.
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.
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.
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".
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.
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.
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
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
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?)
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.
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.
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.
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.
AutoSAR C++14 Interessantes Thema, leider ein sehr schlechter Vortrag: https://www.youtube.com/watch?v=YzyGgZ_RClw
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
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
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.
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.
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.
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
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
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
Kostenloses Buch über C++ Meta-Templates http://www.oreilly.com/programming/free/practical-c-plus-plus-metaprogramming.csp
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
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?
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.
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.
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.
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.
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.
Real Programmers can write FORTRAN in any language. :-)
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 ;-)
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.
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 ...
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.
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.
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.
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..
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.
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.
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!
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.
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 | );
|
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.
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...
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.
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!
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.
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.
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).
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
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.
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?
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).
Falls wer heut noch was zum Lachen braucht: https://www.youtube.com/watch?v=tsG95Y-C14k&index=32&list=PLHTh1InhhwT7GoW7bjOEe2EjyOTkm6Mgd Zu gut. :)
Hier eine schöne Zusammenstellung vieler sehr interessanter Vorträge https://www.cjdb.com.au/sg20-and-videos Viel Spaß!
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." :/
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
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.
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 ...
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?
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.
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.
>>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
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?
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/
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.
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 ;-)
Beitrag #5983502 wurde von einem Moderator gelöscht.
Jener Vortrag über type punning ist ein must-see für die gesamte Community: https://youtu.be/_qzMpk-22cc
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.
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
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.
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%.
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
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. :-)
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.
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.
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.
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.
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?
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.
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.
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).
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ß.
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.
Ah gut zu wissen. Muss demnächst mal checkn ob das keyword im gcc oder clang trunk schon existiert.
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
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...
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
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.
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.
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.
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".
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.
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 ;-)
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.
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.
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.
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.
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.
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.
Meine Sichtweise scheint mittlerweile auch im Main-Stream angekommen zu sein: https://www.b2bseminare.de/entwicklung/embedded-programmierung-mit-modernem-c/anmeldung
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
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 ;-)
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.
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.
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.
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.
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.
Lange Nacht der Programmiersprachen, DLF: Ausschnitt mit einer Sichtweise auf C++.
Christoph M. schrieb: > DLF: Ausschnitt mit einer > Sichtweise auf C++. Völlig sinnfrei: kann über jede (Programmier-)Sprache gesagt werden.
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 :-)
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 ...
Ben Deane über 'deducing this' https://youtu.be/jXf--bazhJw In meinen Augen das wohl sinnvollste C++23 (?) Feature für die Embedded Entwicklung.
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 ;-)
Und das leidige Thema der views (und des non-propagating-const) mal schön dargestellt: https://www.youtube.com/watch?v=O8HndvYNvQ4
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…
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<>.
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?
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.
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...
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.
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.
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.
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<>?
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.
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.
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
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.
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.
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.
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 ;-)
Ein interessantes und lange überfälliges Paper für C++26: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2723r1.html
Bin dafür, fürcht nur dass das keinen großen Anklang finden wird.
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.
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.
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.
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.
Hans-Georg L. schrieb: > Einfach Address ist kein Schlüsselwort oder Datentyp. Was? Natürlich ist Address ein DT, eben ein UDT.
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.
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.
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 ;-)
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}); |
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 ?
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
Hans-Georg L. schrieb: > Eine List mit Quellcodes zu dem Thema Bluetooth für kleine Microcontroller (Bluetoe): https://github.com/TorstenRobitzki/bluetoe
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.
Thread beobachten
Seitenaufteilung abschaltenBitte 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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.