c++ 11/14/17?

Klaus schrieb:
> Hi
> ich arbeite zwar lange mit C, musste hier und da auch kleinere Projekte
> mit C++ angehen.
> sind diese ganzen Erweiterungen von c++11/14/17 weltbewegend und
> verbreitet?

Definitiv.

> Auch im embedded Bereich?

Hmm, schwer zu sagen. Ich nutze sie dort. Kommt aber auch drauf an, was 
der verfügbare Compiler kann. Manche sind bei solchen Änderungen ja 
nicht gerade rasend schnell unterwegs, vor allem, wenn sie zertifiziert 
sein müssen.

Klaus schrieb:
> c++11/14/17

Inzwischen kannst du auch noch C++20 mit hinzunehmen.

Einige der Neuerungen sind sehr praktisch und erleichtern das 
Programmieren, weswegen sich die Beschäftigung damit auf jeden Fall 
lohnt.

Andere blähen IHMO die Sprache nur weiter auf und hätten genauso gut 
weggelassen werden können. Aber das ist ein allgemeines Problem bei 
Kommiteesprachen (nicht nur C++): Da will jeder Beteiligte auf Biegen 
und Brechen seine supertolle Idee in den Standard einbringen, und wenn 
der Vorschlag nicht völlig destruktiv ist, stimmen die anderen halt 
irgendwann zu, damit der Standardisierungsprozess nicht zu sehr ins 
Stocken gerät.

Leider sind die Toolchain-Anbieter im Embedded-Bereich seeeehr träge, 
was das Implementieren der "neuen" C++-Standards angeht. C++11 ist bei 
vielen schon das höchste der Gefühle.
Aber ja: C++ hat viele Features, die auch im Embedded-Bereich sehr 
sinnvoll wären oder sind.

In Automotive und Co (alles was mit FuSi zu tun hat), braucht man 
zertifizierte Komponenten, das schließt den Compiler, die Hardware, die 
Toolchain mit ein. Ein zertifizierter C++11 (wenn man überhaupt das 
Glück hat, C++ benutzen zu dürfen (!)) wird nicht mal eben durch einen 
C++17 (falls es den überhaupt "schon" gibt) ersetzt. Das ist zu teuer 
(denn man muss häufig dann mehrere Varianten parallel haben, um alte 
builds reproduzieren zu können) und dabei ist die Entwicklungszeit 
(Lambdas, constexpr etc) leider fast vollkommen egal - zumindest war es 
das in den letzten Firmen, die ich von innen gesehen habe.

edit: Von Keil gibts beispielsweise gerade mal C++11: 
https://developer.arm.com/tools-and-software/embedded/arm-compiler/safety

Hau wech den Scheiss schrieb:
>>Echte Verifikation wird in der Automobilindustrie nicht gemacht, da
>>praktisch unmöglich.
>
> Klar, und ich bin der Kaiser von China.

Ich denke, da hat er Recht. Echte aka formale Verifikation ist bei 
komplexen Zusammenhängen extremst aufwendig oder nahezu unmöglich.

mh schrieb:
> Dann, gib mal wenigstens ein Beispiel aus dem c++20 Standard
...
> - zuwenig Manpower (was auch immer du damit meinen magst) hat

Es geht dabei nicht um den Standard selbst, sondern um die 
Compiler-Entwickler, die das dann in ihren Produkten umsetzen müssen.

Programmierer schrieb:
> Neue C++-Versionen bieten bessere Möglichkeiten zur typsicheren
> (Meta-)Programmierung, damit kann man mehr Fehler direkt beim
> Kompilieren erkennen, wodurch sich die Fehlerwahrscheinlichkeit wieder
> reduziert.

Das basiert aber auf der Annahme, dass der Compiler selbst generell 
keine Fehler hat. Als Entwickler der Software hat man allerdings nur auf 
den Quellcode Einfluss, nicht aber auf den Compiler selbst.

Hau wech den Scheiss schrieb:
> Hau wech den Scheiss schrieb:
>>> Und da bleibt man lieber bei
>>> gut bewährter Software .
>
>>Warum?
>
> Naja, weil man davon ausgeht das sich Software die sich in der
> Vergangenheit als Fehlerarm gezeigt hat, auch in Zukunft das selbe
> Fehlerarme Verhalten zeigen wird. Software unterliegt keinem Verschleiß
> und muss daher nicht permanent erneuert werden.

Darüber hinaus kennt man bei länger verwendeter Software die bestehenden 
Fehler, und ein Wechsel auf eine neue Software würde die Fehler durch 
neue ersetzen, die man noch nicht kennt. Und bekannte Fehler sind immer 
besser als unbekannte. Deshalb wird auch in der Raumfahrt gerne "gut 
abgehangene" Hardware verwendet, also z.B. Prozessor-Typen, die es schon 
sehr lange gibt. Neben der geringen Komplexität sind dort auch mehr von 
den Fehlern bereits gefunden worden als bei neuerer Hardware.

>>Echte Verifikation wird in der Automobilindustrie nicht gemacht, da
>>praktisch unmöglich.
>
> Klar, und ich bin der Kaiser von China.

Er meint mit "Verfikiation" vermutlich die Erbringung eines formalen 
Beweises für die Korrektheit.

Jan K. schrieb:
> In Automotive und Co (alles was mit FuSi zu tun hat), braucht man
> zertifizierte Komponenten, das schließt den Compiler, die Hardware, die
> Toolchain mit ein.

Nur braucht das der größte Teil der Software in einem Auto gar nicht.

Und da zur Zeit jeder Kommentar über die deutsche Automobilindustrie in 
etwas lautet "können alles, ausser Software", würde ich auf die 
bisherigen Gepflogenheiten dort auch nicht allzuviel geben.

Ich bin mir ziemlich sicher, daß weder Google, noch Apple oder Tesla 
sich mit Misratenen Normentwürfen herumschlagen. Die sitzen stattdessen 
in den C++-Normungsgremien, und gehen damit vorwärts.

Oliver

Oliver S. schrieb:
> Ich bin mir ziemlich sicher, daß weder Google, noch Apple oder Tesla
> sich mit Misratenen Normentwürfen herumschlagen. Die sitzen stattdessen
> in den C++-Normungsgremien, und gehen damit vorwärts.

Das stimmt vermutlich. Und glaub mir, ich bin über den langsamen 
Fortschritt auch angenervt, bekomme es tagtäglich auf der Arbeit mit.

Möchte man aber Hardware/Module in einem Auto oder in der Industrie 
unterbringen, muss häufig nach den erwarteten Normen entwickelt werden. 
Macht man das nicht, bekommt man das Projekt nicht - ganz einfach. Und 
ISO26262 und co kommen gerade erst richtig und schwappen von purem 
Automotive in Richtung Transportation, Industrie, Baumaschinen etc.

@Hau wech den Scheiss (Gast), du kennst leider den Begriff formale 
Verifikation nicht. Das hat nichts mit Testen zu tun. Natürlich wird 
viel getestet und wer seine Software samt Drumherum nicht testbar 
gestaltet, hat irgendwann grundsätzlich die A-Karte.

Klaus schrieb:
> sind diese ganzen Erweiterungen von c++11/14/17 weltbewegend

ja

> und
> verbreitet?

In diesem Forum stoßen sie regelmäßig auf Kritik ;-) Das scheint ein 
gutes Zeichen zu sein.

> Auch im embedded Bereich?

Eigentlich gerade da.

Meine persönliche Hitliste im µC-Bereich (inkl. c++20) sind:

1) concepts: der Schlüssel zu compiletime-polymorphie und TMP
2) constexpr everywhere
3) lambda-expr. Verbesserungen (e.g. explicit template-lambda parameter)
4) stdlib: tuple<>, variant<>, bit_cast<>, etc. zusammen mit 2)
5) template-alias (using) und viele Kleinigkeiten vereinfachen die TMP

mh schrieb:
> Yalu X. schrieb:
>> Andere blähen IHMO die Sprache nur weiter auf und hätten genauso gut
>> weggelassen werden können.
>
> Was würdest du sagen bläht die Sprache nur auf?

Zwei Beispiele, die mich besonders stören:


1. Die Uniform Initialization:

   Zu den bereits bestehenden mehreren Möglichkeiten der Initialisierug
   kommt nun noch eine weitere hinzu

     https://xkcd.com/927/

   beschreibt die Situation ganz treffend, wenn man dort "standards"
   durch "initialization methods" ersetzt.

   Nicht ganz so schlimm fände ich die Uniform Initialization, wenn sie
   wenigstens die klassischen Initialisierungsmethoden komplett ersetzen
   könnte, aber das tut sie nicht.

   Dazu kommt noch, dass nun einige meinen, deren Verwendung auf die
   Spitze treiben zu müssen, so dass dann Stilblüten wie diese
   entstehen:

1

     for (int i{}; i<3; i++)

2

       ...

   Das ist zwar legaler Code, aber was soll der Unfug?

   Anfangs habe ich die Uniform Initialization selber verwendet, u.a. um
   in meinem Code zu dokumentieren, dass ich mit der Zeit gehe und nicht
   an alten Zöpfen hänge ;-) Mittlerweile ist mir das egal, weswegen ich
   wieder zu den klassischen Initialisierungsmethoden zurückgekehrt bin.
   Mich spricht auch deren Syntax mehr an.


2. Typsynonyme mit using als Alternative zu typedef:

   Ich frage mich, was an der typedef-Syntax schlecht ist. Den einzigen
   Mangel sehe ich darin, dass typedef nicht getemplatet werden kann,
   ein Problem, das seit der Einführung der Templates in C++ (also schon
   lange vor C++11) diskutiert wird, aber nie behoben wurde. Statt
   einfach auch typedef-Templates zu erlauben, wurde die völlig neue
   using-Syntax eingeführt. Wozu? Habe ich irgendwelche schwerwiegende
   Gründe übersehen, warum das für typedef nicht möglich ist?


Es gibt noch ein paar weitere IHMO unsinnige neue Features, die ich aber
aus meinem Gesichtsfeld entschwunden sind, da sie auch von anderen kaum
genutzt werden. Sie machen damit lediglich das Standarddokument und die
Lehrbücher fett, stören aber wenigstens bei der täglichen Arbeit nicht.


Bitte nicht missverstehen: Meine Kritik bedeutet keineswegs, dass ich
zurück zu C++03 möchte, ganz im Gegenteil. C++11 und Nachfolger bringen
insgesamt mehr positive als negative Erweiterungen mit. Die für mich
wichtigsten positiven Punkte sind:

1. Range based Loops:

   Endlich kann man über die Elemente eines Containers ohne dieses
   lästige begin() und end() iterieren.

2. Lambda-Ausdrücke:

   C++ war eine der letzten Sprachen, die das noch nicht hatte, deswegen
   wurde es höchste Zeit, das nachzuliefern.

3. Neue Datentypen in Standardbibliothek

   Tuple, Optional, verschiedene Sorten von Smart Pointers usw.

4: π

   Ich hätte nicht geglaubt, dass das bisher GCC-spezifische M_PI noch
   irgendwann in den Standard aufgenommen werden wird. Seit letzten
   Dezember (C++20) ist es aber tatsächlich so weit: Es gibt jetzt u.a.
   std::numbers::pi in <numbers>. Ich frage mich nur, warum das fast ein
   halbes Jahrhundert gedauert hat.

5. Compilezeitberechnungen mit constexpr:

   Wenn ich sehe, wie man solche Dinge früher mit Template-Hacks
   hingedoktert hat (einige haben daraus eine regelrechte Wissenschaft
   gemacht), ist diese Erweiterung ein wirklicher Segen.

6. Contraints und Concepts:

   Endlich wird das leidige Problem mit dem Duck-Typing in Templates und
   den damit verbundenen schwer interpretierbaren Fehlermeldungen etwas
   entschärft. Diese Lösung ist zwar nicht besonders schön und bedarf
   zusätzlicher Zuarbeit vonseiten des Template-Entwicklers, aber mehr
   war unter Beibehaltung der Abwärtskompatibilität wohl nicht möglich.

7. Stark typisierte Enums

   Ein weitere Schritt zu mehr Fehlererkennung durch den Compiler.

8. Type Inference:

   Implementiert wurde zwar nur eine schwache Form davon, aber auch
   diese ist oft sehr hilfreich, bspw. bei der Deklaration eines
   Iterators zu einem gegebenen Container-Objekt.

9. Korrekte Unterscheidung zwischen doppelten Temnplate-Klammern und dem
   >>-Operator

   Früher musste bspw. bei std::vector<std::vector<int>> zwischen den
   beiden ">" ein Leerzeichen eingefügt werden.

Das aus meiner Sicht größte Problem an C++ ist die Komplexität. Es gibt 
alles und dann noch die kleine Schwester davon.

Im Ergebnis übersteigt die Komplexität der Sprache die Hirne der 
Entwickler, die dann nur einen kleinen Teil der Möglichkeiten überhaupt 
nutzen. Ohne einen übergeordneten Standard nutzt dann jeder noch einen 
anderen Teil, was die Sprache für Menschen schlecht lesbar machen kann.

Kompatiblität ist schön und gut, aber im Drei-Jahres-Takt ausschließlich 
neue Dinge hinzufügen macht das nicht gerade besser.

Das "es gibt mehr als eine gute Lösung" ist es, was Perl so nervig macht 
und C++ geht aus meiner Sicht den gleichen Weg.

S. R. schrieb:
>
> Kompatiblität ist schön und gut, aber im Drei-Jahres-Takt ausschließlich
> neue Dinge hinzufügen macht das nicht gerade besser.
>
> Das "es gibt mehr als eine gute Lösung" ist es, was Perl so nervig macht
> und C++ geht aus meiner Sicht den gleichen Weg.

Es gibt aus gutem Grund mehrere Lösungen. Denn wenn wegen neuer Ideen 
die alten Projekte nicht mehr übersetzbar sind, dann wird das wie bei 
Python 2 vs 3, wo auch heute noch beides parallel installiert sein muß.

Wenn nun etwas, was bisher umständlich war, durch ein neues, eleganteres 
Verfahren ersetzt werden kann, dann sollte da ein "endlich" zu hören 
sein. Falls es es keine übergeordneten Gründe gibt, das komplizierte zu 
behalten (Zertifizierung).
"Immer schon so gemacht" haben wir eben "auf den Bäumen sitzen".

Ausnahmen würde ich bei so Dingen machen wie "ich habe 'volatile' nicht 
verstanden und plädiere dafür es abzuschaffen". Wenn sowas von Firmen 
kommt, die eigentlich lieber ihre homebrew Sprachen verwenden, da kann 
man über die wirklichen Gründe mutmaßen. Da ist Apple nicht anders als 
MS.

Carl D. schrieb:
> Es gibt aus gutem Grund mehrere Lösungen.

Das ist mir schon klar und ich kann auch das C++-Konsortium verstehen. 
Ändert aber nichts daran, dass der enorme Sprachumfang allein schon 
dafür sorgt, dass niemand die Sprache mehr vollständig überblicken kann.

Fällt z.B. immer dann auf, wenn bei den Vorträgen mal in die Runde 
gefragt wird, welchen Datentyp (oder welche Fehlermeldung) ein 
bestimmter Ausdruck jetzt erzeugt - und das selbst den Experten, die den 
Standard schreiben, nicht klar ist.

Mir kommen echt die Tränen, dass Ihr Euch in so viele neue Dinge 
einarbeiten müsst.

Wilhelm M. schrieb:
> Mir kommen echt die Tränen, dass Ihr Euch in so viele neue Dinge
> einarbeiten müsst.

Du beherrschst sämtliche Features von C++20? :-)

Wilhelm M. schrieb:
> Mir kommen echt die Tränen, dass Ihr Euch in so viele neue Dinge
> einarbeiten müsst.

Hängt schlicht davon ab, ob man für das "sich in viele neue Dinge 
einarbeiten" oder etwas anderes bezahlt wird, und ob man dafür eher eine 
Stunde oder drei Monate braucht.

mh schrieb:
> Die 2h, um einmal alle Änderungen zu überfliegen, sollte man haben.

Sicherlich, aber die Konsequenzen daraus sind nochmal eine ganz andere 
Hausnummer.

mh schrieb:
> Was sind denn die Konsequenzen "daraus"?
>
> Ich sehe Nichts, das große Konsequenzen hat, wenn es nicht einsetzt.

Nun ja, mit concepts, auto überall, constexpr lambdas, ranges, und was 
da alles noch so an Kleinigkeiten dabei ist, sieht der Code doch schon 
sehr anders aus als das, was man mit C++11 so gebastelt hat. Bis man das 
in voller Konsequenz mal mental umgesetzt hat, dauerts schon länger als 
nur zwei Stunden.

Aber new und delete gibts auch immer noch, wer will, kannn nach wie vor 
"C mit Klassen"-Code schreiben.

Oliver

mh schrieb:
> Ich sehe Nichts, das große Konsequenzen hat, wenn es nicht einsetzt.

Die Konsequenz daraus ist, das du die Chance verschenkst deinen Code 
(typ) sicherer zu machen ;-)

mh schrieb:
> Ich sehe Nichts, das große Konsequenzen hat, wenn es nicht einsetzt.

Wenn man es nicht einsetzt, dann bleibt man aber bei C++03 stehen. Also: 
Entweder lernt man die neuen Features, oder man benutzt sie halt nicht.

mh schrieb:
> Es ging um C++20, also sind nur die Änderungen seit C++17 relevant.

Es ging um C++20 im Vergleich zu dem Stand vor C++11.

mh schrieb:
> Ich sehe Nichts, das große Konsequenzen hat, wenn es nicht einsetzt.

Es geht nicht darum, ob ich es einsetze, sondern ob jemand anderes das 
in der gleichen Codebasis einsetzt, mit der ich arbeiten muss. Und 
selbst wenn ich einsetze heißt das noch lange nicht, dass der Rest des 
Teams damit arbeiten kann.

Oliver S. schrieb:
> Nun ja, mit concepts, auto überall, constexpr lambdas, ranges, und was
> da alles noch so an Kleinigkeiten dabei ist, sieht der Code doch schon
> sehr anders aus als das, was man mit C++11 so gebastelt hat.

Schöne Zusammenfassung.

Genau das macht modernes C++20 effektiv zu einer völlig anderen 
Programmiersprache als der, die ich vor garnicht so vielen Jahren mal 
als "C++" kennengelernt habe.

mh schrieb:
> Dann verfolge die Kette mal bis zu dem Betrag,
> aus dem dieser Satz von mir stammt.

Der Thread handelt von den "ganzen Erweiterungen von C++11/14/17".

Die Beschränkung auf "die Unterschiede zwischen C++17 und C++20" kam 
tatsächlich von dir, hat aber sonst niemanden interessiert. ;-)

mh schrieb:
> S. R. schrieb:
>> mh schrieb:
>>> Dann verfolge die Kette mal bis zu dem Betrag,
>>> aus dem dieser Satz von mir stammt.
>>
>> Der Thread handelt von den "ganzen Erweiterungen von C++11/14/17".
>>

So sehe ich das auch.

>> Die Beschränkung auf "die Unterschiede zwischen C++17 und C++20" kam
>> tatsächlich von dir, hat aber sonst niemanden interessiert. ;-)
>
> Wenn Mark B. schreibt "Du beherrschst sämtliche Features von C++20",
> kommt das also plötzlich von mir?

Es kam nicht von dir, aber du hast dich auf die Reduktion darauf 
eingelassen.

Wenn man generisch programmiert ist es auf jeden Fall sinnvoll die C++20 
Constraints und concepts sich anzuschauen.

Was wollen wir?

[] Wir wollen eine Programmiersprache, die sich nicht ändert, damit wir 
unser Denken nicht ändern müssen.

[] Wir wollen eine Programmiersprache, die vollständig abwärtskompatibel 
ist, damit der alte Code immmer noch compiliert werden kann, und ohne 
neue Bugs läuft. Alte Bugs sollen erhalten bleiben.

[] Wir wollen ein Programmiersprache, die top-modern ist, und die 
allerneuesten Features, die diskutiert werden, inkludiert.

[] Wir wollen eine Programmiersprache, die nicht aufgebläht ist, weil 
regelmäßig alte Features entfernt werden.

[] Wir wollen eine Programmiersprache, die möglichst wenig Features hat, 
damit sie leicht zu lernen ist.

[] Wir wollen eine Programmiersprache, die immer den schnellsten 
Maschinen-Code und auch sonstwie den effizientesten Ressourcengebrauch 
liefert.

[] Wir wollen ein Programmiersprache, dessen Syntax uns persönlich am 
besten passt.

[] Wir wollen eine Programmiersprache, die sich nicht ändert, damit wir 
nichts neues lernen müssen.

[] Wir wollen eine Programmiersprache, die nicht von einem Gremium 
definiert wird, damit wir uns nicht engagieren müssen.

[] Wir wollen eine Programmiersprache, die wir erlernen können, ohne zu 
lernen bzw. ihr Historie oder ihre grundlegenden Ideen zu verstehen.

[] ...

[] ...

Schaut aus, wie im richtigen Leben ;-)

Im übrigen ist das hier Diskutierte eher ein Problem der "alten Säcke" 
als der "jungen Hüpfer". Die Jungen kommen oft aus eine Script-Welt o.ä. 
und sind "überglücklich" über die Möglichkeiten des "modernen C++". Die 
Umständlichkeiten des "alten C++" erzählt man einmal, und dann lassen 
sie die auch sofort gerne links liegen.

Wenn’s für dich so passt, dann ja.

Oliver

Eumel schrieb:
> Also entweder gefällt mir ausnahmslos alles an C++, oder ich bin
> lernfaul, alt oder sonst wie minderbemittelt. Ist das in etwa richtig
> zusammengefasst?

Wenn Du das darin liest, dann sicherlich ja ;-)

Wilhelm M. schrieb:
> Im übrigen ist das hier Diskutierte eher ein Problem der "alten Säcke"
> als der "jungen Hüpfer". Die Jungen kommen oft aus eine Script-Welt o.ä.
> und sind "überglücklich" über die Möglichkeiten des "modernen C++". Die
> Umständlichkeiten des "alten C++" erzählt man einmal, und dann lassen
> sie die auch sofort gerne links liegen.
Ich bin so ein alter Sack, der mit programmieren angefangen hat als der 
8080 Assembler noch vom Lochstreifen eingelesen wurde, mit "klassischem" 
C++ später sein Geld verdient hat und schon ein Weilchen Rentner ist 
;-).
Wenn du keine Erfahrung hast wie man ein System in wieder verwendbare 
Klassen aufteilt nützen dir die tollsten Features einer Sprache nichts. 
Ob Erfahrungen aus der Script Welt dabei helfen sei mal dahin gestellt.

Im Moment versuche ich meine C Programme für die STM32 MC auf C++ um zu 
stellen und da sind Klassen eher unwichtig und die neuen Features sehr 
willkommen. Allerdings unterstützt die STM Cube-IDE nur den gcc 9.3.1
und somit C++17 aber es lässt sich nur -std=c++14 einstellen. Diese 
blöden Eclipse IDEs sind alle so vermurkst, die Build Systeme und die 
Debugger Unterstützung sind untereinander nicht kompatibel. Den gcc 
scheint es aber nicht zu stören wenn man zusätzlich noch -std=c++17 
hinzu fügt.

Ich bin immer noch dabei zu lernen, auch wenn es langsamer geht ;-)

Hans-Georg L. schrieb:
> Im Moment versuche ich meine C Programme für die STM32 MC auf C++ um zu
> stellen und da sind Klassen eher unwichtig und die neuen Features sehr
> willkommen.

So sehe ich es auch: OOP auf Mikrocontrollern in Embedded Systemen 
braucht man oft nicht, bzw. bringt für viele typische Anwedungsfälle 
(z.B. Abarbeiten eines Schnittstellenprotokolls) oft keine nennenswerten 
Vorteile gegenüber prozeduraler Programmierung. Aber C++ ist eben nicht 
nur OOP. Man sagt ja auch, es sei eine "multi-paradigm" 
Programmiersprache.

Hans-Georg L. schrieb:
> Im Moment versuche ich meine C Programme für die STM32 MC auf C++ um zu
> stellen und da sind Klassen eher unwichtig und die neuen Features sehr
> willkommen.

Klassen sind an der Stelle sehr(!) wichtig. Und zwar als die Basis der 
Meta-Programmierung. Denn Meta-Funktionen F: type -> type sind im 
allgemeinen als Klassentemplates bzw. Spezialisierungen derselben 
realisiert.

Was Du allerdings meinst mit Deiner Aussage ist ein Teilbereich der OOP, 
nämlich Laufzeitpolymorphie. Das mag für den µC Bereich eher weniger 
wichtig sein (in meinen Augen ist es das). Wobei es auch da Ersatz gibt, 
der auf µC besser geeignet ist.

Mark B. schrieb:
> Man sagt ja auch, es sei eine "multi-paradigm"
> Programmiersprache.

Genau: und klassische OOP ist nur ein Teil davon!

Aber selbst von man klassische OOP nicht einsetzt, heißt dass nicht, 
dass Klassen (in C++) unnütz sind ...

Wilhelm M. schrieb:
> Hans-Georg L. schrieb:
>> Im Moment versuche ich meine C Programme für die STM32 MC auf C++ um zu
>> stellen und da sind Klassen eher unwichtig und die neuen Features sehr
>> willkommen.
>
> Klassen sind an der Stelle sehr(!) wichtig. Und zwar als die Basis der
> Meta-Programmierung. Denn Meta-Funktionen F: type -> type sind im
> allgemeinen als Klassentemplates bzw. Spezialisierungen derselben
> realisiert.
>
> Was Du allerdings meinst mit Deiner Aussage ist ein Teilbereich der OOP,
> nämlich Laufzeitpolymorphie. Das mag für den µC Bereich eher weniger
> wichtig sein (in meinen Augen ist es das). Wobei es auch da Ersatz gibt,
> der auf µC besser geeignet ist.

Wenn ich mich undeutlich ausdrücke darfst du mich gerne korrigieren ;-)
Ich lerne gerne dazu ...

Mein Bestreben war es erst einmal das C Konstrukt :
RCC->AHB1ENR = GPIOA | 1<<GPIOB | 1<<GPIOC /*usw...*/ ;
durch eine typsichere und einfach verständliche C++ Version zu ersetzen.

Meine Version:
AHB1_EnableClock(GPIOA_CLK,GPIOB_CLK,GPIOC_CLK);

Meine Datentypen sind enums und die kann man in diesem Zusammenhang auch 
als Klassen sehen.

Anbei noch ein Code Ausschnitt dazu.

ps .. die enums lassen sich auch noch nach read/write only erweitern

Hau wech den Scheiss schrieb:
> Hans-Georg L. schrieb:
>
>> Anbei noch ein Code Ausschnitt dazu.
>
> Zeile 40 enthält einen Fehler.

Danke.

Das ist nur ein erster Versuch im Endeffekt möchte ich diese 
Declarationen wenn ich mir über die Strukturierung der namespaces klar 
bin, automatisch aus dem svd File erzeugen aber auch diese sind nicht 
unbedingt Fehlerfrei.

Hau wech den Scheiss schrieb:
> Hans-Georg L. schrieb:
>>  automatisch aus dem svd File erzeugen aber auch diese sind nicht
>> unbedingt Fehlerfrei.
>
> Vielleicht einen Plausibilitätscheck drüber laufen lassen, der auf
> doppelte vergebenen Addressen schaut.
>
> Misaligment für dword-Adressen wäre auch so ein Check der sich anbietet,
> aber letzteres sollte doch auch der Assembler finden und als Warning
> bemeckern. Vielleicht auch aus den pdf-docs mit tesseract rauspulen wenn
> man den mitgelieferten Headern nicht trauen kann.
 Assembler hat nichts gefunden

nochmal mit datenblatt verglichen, das müsst jetzt stimmen
Es geht übrigends um den STM32F411 (Blackpill)

<code>
    namespace Regs {
        constexpr reg32_t RCC_BASE         AHB1PERIPH_BASE + 0x3800UL;
        // RCC register
        constexpr reg32_t RCC_CR                = RCC_BASE;
        constexpr reg32_t RCC_PLLCFGCR          = RCC_BASE + 0x04U;
        constexpr reg32_t RCC_CFGCR             = RCC_BASE + 0x08U;
        constexpr reg32_t RCC_CIR               = RCC_BASE + 0x0CU;
        constexpr reg32_t RCC_AHB1RSTR          = RCC_BASE + 0x10U;
        constexpr reg32_t RCC_AHB2RSTR          = RCC_BASE + 0x14U;
        constexpr reg32_t RCC_APB1RSTR          = RCC_BASE + 0x20U;
        constexpr reg32_t RCC_APB2RSTR          = RCC_BASE + 0x24U;
        constexpr reg32_t RCC_AHB1ENR           = RCC_BASE + 0x30U;
        constexpr reg32_t RCC_AHB2ENR           = RCC_BASE + 0x34U;
        constexpr reg32_t RCC_APB1ENR           = RCC_BASE + 0x40U;
        constexpr reg32_t RCC_APB2ENR           = RCC_BASE + 0x44U;
        constexpr reg32_t RCC_AHB1LPENR         = RCC_BASE + 0x50U;
        constexpr reg32_t RCC_AHB2LPENR         = RCC_BASE + 0x54U;
        constexpr reg32_t RCC_APB1LPENR         = RCC_BASE + 0x60U;
        constexpr reg32_t RCC_APB2LPENR         = RCC_BASE + 0x64U;
        constexpr reg32_t RCC_BDCR              = RCC_BASE + 0x70U;
        constexpr reg32_t RCC_CSR               = RCC_BASE + 0x74U;
        constexpr reg32_t RCC_SSCGR             = RCC_BASE + 0x80U;
        constexpr reg32_t RCC_PLLI2SCFGR        = RCC_BASE + 0x84U;
  }

</code>

Hau wech den Scheiss schrieb:
> Hans-Georg L. schrieb:
>>  automatisch aus dem svd File erzeugen aber auch diese sind nicht
>> unbedingt Fehlerfrei.
>
> Vielleicht einen Plausibilitätscheck drüber laufen lassen, der auf
> doppelte vergebenen Addressen schaut.
>
> Misaligment für dword-Adressen wäre auch so ein Check der sich anbietet,
> aber letzteres sollte doch auch der Assembler finden und als Warning
> bemeckern. Vielleicht auch aus den pdf-docs mit tesseract rauspulen wenn
> man den mitgelieferten Headern nicht trauen kann.

Guter Tip, das könnte ich dann alles in mein Programm einbauen das die 
svd Files einliest.

Hans-Georg L. schrieb:
> Wenn ich mich undeutlich ausdrücke darfst du mich gerne korrigieren ;-)
> Ich lerne gerne dazu ...
>
> Mein Bestreben war es erst einmal das C Konstrukt :
> RCC->AHB1ENR = GPIOA | 1<<GPIOB | 1<<GPIOC /*usw...*/ ;
> durch eine typsichere und einfach verständliche C++ Version zu ersetzen.

Wunderbar. Das ist der erste Schritt.

1

    template<reg32_t ra,typename T, typename ... Args>

2

    requires((... && std::is_same<Args, T>{}))

3

    constexpr void set_bit(Args ... args ) {

4

//        static_assert((... && std::is_same<Args, T>()));   // parameter test

5

        reg32_t mask =(... | args);                       // folding OR

6

        *reinterpret_cast<volatile reg32_t*>(ra) |= mask; // set bitmask

7

    };

Ich habe Dein static_assert() mal durch ein adhoc-requirement ersetzt. 
DAs macht die Fehlermeldung ggf. intuitiver.

Desweiteren ist es eher unüblich, die traits zu instanziieren und dann 
implizit nach bool zu koinvertieren.

1

    template<reg32_t ra,typename T, typename ... Args>

2

    constexpr void clear_bit(Args ... args ) {

3

        static_assert((... && std::is_same_v<Args, T>));   // parameter test

4

        reg32_t mask =(... | args);                       // folding OR

5

        *reinterpret_cast<volatile reg32_t*>(ra) &= ~mask; // clear bitmask

6

    };

Habe das mal kurz hier geändert, nur als Idee.

Du könntest dann auch noch scoped-enums einsetzen.

Statt extra Funktionen für set/clear einzuführen, kannst Du nach dem 
gleichen Muster ggf. die Op-|| und Op-&& für die Typen überladen. Ggf. 
sogar als template und per enable-if/concept ganz gezielt aktivieren für 
die Typen, für die Du das haben möchtest.

temp schrieb:
> Leider ist es bis
> heute so, will man beim Debuggen und im Release annähernd gleiche
> Resultate beim erzeugten Code, geht um ein C—Macro auch 2021 immer noch
> kein Weg vorbei. Ich lasse mich aber gern eines besseren Belehren.

Du kannst doch sicher -Og benutzen. Das reicht aus, um die 
template-calls (inline) zu optimieren.

Die obige Lösung kannst Du natürlich verbessern, und möglichst viel zur 
Compilezeit erledigen:

1

        template<reg32_t adr, auto ... Args>

2

        constexpr void enable() {

3

            constexpr reg32_t mask = (... | Args);            

4

            *reinterpret_cast<volatile reg32_t*>(adr) |= mask;

5

        }

(Oder Du schreibst noch eine Meta-Funktion für den |-Op, ist wegen 
constexpr aber unnötig, etwa static_or<...>).

Mit dem static_or dann:

1

   *reinterpret_cast<volatile reg32_t*>(Regs::RCC_AHB1ENR) = static_or_v<CRC_CLK,GPIOA_CLK,GPIOB_CLK,GPIOC_CLK,GPIOD_CLK>;

bzw:

1

GPIOA->BSS = static_or_v<...>;

Auf die Typ-Prüfungen habe ich jetzt verzichtet, kann man aber ja noch 
obigem Muster ebenfalls einbauen.

Programmierer schrieb:
...
>

1

static_assert ((ra % 4) == 0, "Address not aligned");

>
 Werde ich einbauen Danke.

Wilhelm M. schrieb:
> temp schrieb:
>> Leider ist es bis
>> heute so, will man beim Debuggen und im Release annähernd gleiche
>> Resultate beim erzeugten Code, geht um ein C—Macro auch 2021 immer noch
>> kein Weg vorbei. Ich lasse mich aber gern eines besseren Belehren.
>
> Du kannst doch sicher -Og benutzen. Das reicht aus, um die
> template-calls (inline) zu optimieren.
>
> Die obige Lösung kannst Du natürlich verbessern, und möglichst viel zur
> Compilezeit erledigen:
>
> [c]
>         template<reg32_t adr, auto ... Args>
>         constexpr void enable() {
>             constexpr reg32_t mask = (... | Args);
>             *reinterpret_cast<volatile reg32_t*>(adr) |= mask;
>         }
Wilhelm M. schrieb:
>     template<reg32_t ra,typename T, typename ... Args>
>     requires((... && std::is_same<Args, T>{}))
>     constexpr void set_bit(Args ... args ) {
> //        static_assert((... && std::is_same<Args, T>()));   //
> parameter test
>         reg32_t mask =(... | args);                       // folding OR
>         *reinterpret_cast<volatile reg32_t*>(ra) |= mask; // set bitmask
>     };
>
> Ich habe Dein static_assert() mal durch ein adhoc-requirement ersetzt.
> DAs macht die Fehlermeldung ggf. intuitiver.
>
requires ist c++20 und wie schon geschrieben ist mein compiler auf c++17 
begrenzt aber eine sinnvolle Fehlermeldung könnte ich noch ausgeben

> Desweiteren ist es eher unüblich, die traits zu instanziieren und dann
> implizit nach bool zu koinvertieren.
>     template<reg32_t ra,typename T, typename ... Args>
>     constexpr void clear_bit(Args ... args ) {
>         static_assert((... && std::is_same_v<Args, T>));   // parameter
> test
>         reg32_t mask =(... | args);                       // folding OR
>         *reinterpret_cast<volatile reg32_t*>(ra) &= ~mask; // clear
> bitmask
>     };
>
Finde den Unterschied nicht so leicht für ältere Augen ;-)

> Du könntest dann auch noch scoped-enums einsetzen.

Das wollte ich sowieso und vorsichtshalber den underlying typ auf 
unsigned ändern. Nicht das der Compiler, durch Bit-Schiebereien, 
irgendwann auf die Idee kommt Bit31 als Vorzeichen aufzufassen.

> Statt extra Funktionen für set/clear einzuführen, kannst Du nach dem
> gleichen Muster ggf. die Op-|| und Op-&& für die Typen überladen. Ggf.
> sogar als template und per enable-if/concept ganz gezielt aktivieren für
> die Typen, für die Du das haben möchtest.

Ich bin ehrlich gesagt kein großer Freund davon erstmal alles zusammen 
zu fassen und dann wieder mit if zu zerlegen. Mal sehen.. es gibt ja 
noch andere Registertypen.

Hans-Georg L. schrieb:
> Finde den Unterschied nicht so leicht für ältere Augen ;-)

1

std::is_same_v<Args, T>

statt

1

std::is_same<Args, T>()

Hans-Georg L. schrieb:
> Ich bin ehrlich gesagt kein großer Freund davon erstmal alles zusammen
> zu fassen und dann wieder mit if zu zerlegen

Nicht if, sondern enable-if.

Hans-Georg L. schrieb:
> requires ist c++20 und wie schon geschrieben ist mein compiler auf c++17
> begrenzt

Ist das ein gcc? Und c++2a kann der noch nicht?

Das requires dannst Du ggf. auch durch ein enable-if ersetzen, um die 
Instantiierung aus dem overload-set zu entfernen.

Sorry, ich wollte diesen Thread nicht für mich kapern aber ich denke es 
geht immer noch um allgemeines C++ Wissen.

Wilhelm M. schrieb:
> Hans-Georg L. schrieb:
>> requires ist c++20 und wie schon geschrieben ist mein compiler auf c++17
>> begrenzt
>
> Ist das ein gcc? Und c++2a kann der noch nicht?
>
> Das requires dannst Du ggf. auch durch ein enable-if ersetzen, um die
> Instantiierung aus dem overload-set zu entfernen.

Es ist wie geschrieben ein gcc 9.3.1 der sich mit STM CUBE-IDE (Eclipse) 
maximal auf c++14 stellen lässt. Aber man kann zusätzlich c++17 
einfügen, was er dann auch benutzt. Das funktioniert auch mit 
-std=c++2a. :-)

gibt es auch eine Option zum Removen einer anderen Option ? Also um das 
-std=c++14 los zu werden.

Hans-Georg L. schrieb:
> Es ist wie geschrieben ein gcc 9.3.1

Sorry, hatte ich nicht gelesen.

Im übrigen ist das Compilieren des Gcc aus dem git-repo kein Problem.

Hans-Georg L. schrieb:
> gibt es auch eine Option zum Removen einer anderen Option ? Also um das
> -std=c++14 los zu werden.

Das ist ein Problem des Cube-Eclipse-Plugins, nicht des Compilers. Da 
musst du dich an die dazu zuständigen Programmierer wenden.

Andere Plugins bieten in dem Auswahlfeld zumindest ein leeres Feld an.

Oliver

Oliver S. schrieb:
> Hans-Georg L. schrieb:
>> gibt es auch eine Option zum Removen einer anderen Option ? Also um das
>> -std=c++14 los zu werden.
>
> Das ist ein Problem des Cube-Eclipse-Plugins, nicht des Compilers. Da
> musst du dich an die dazu zuständigen Programmierer wenden.
>
> Andere Plugins bieten in dem Auswahlfeld zumindest ein leeres Feld an.
>
> Oliver

Unter Window->Preferences->StmCube->Build gibt es dieses Leerfeld.

Unter den Project->settings aber dann nicht mehr.

Dieses Plugin hat mich schon Nerven gekostet. Ich benutze die Cube IDE 
nur weil man damit problemlos zwischen ST-Link und Segger J-Link 
umschalten kann  und der Build mit dem CubeMX Code kompatibel ist was 
bei anderen, wo man seinen eigenen Compiler einbinden kann leider nicht 
funktioniert. Und anpassen kann man bei allen selbst nichts, sondern 
muss irgendwo betteln das es einer macht.

Programmierer schrieb:
> Hans-Georg L. schrieb:
>> Ich benutze die Cube IDE
>> nur weil man damit problemlos zwischen ST-Link und Segger J-Link
>> umschalten kann
>
> Das geht mit dem GNU-MCU-Eclipse Plugin auch.
>
> Hans-Georg L. schrieb:
>> und der Build mit dem CubeMX Code kompatibel ist was
>> bei anderen, wo man seinen eigenen Compiler einbinden kann leider nicht
>> funktioniert.
>
> Wieso das? Die CubeIDE nutzt auch nur den normalen GCC-ARM-Embedded.
> Wenn man den separat herunterlädt (und ggf. in eine beliebige IDE
> einbindet) kann man damit auch den CubeMX-generierten Code kompilieren.
> Wenn das bei dir nicht klappt hast du irgendwas falsch gemacht (Makros
> vergessen oder so).

Es geht nicht um den Code sondern die .(c)project files. Irgendwann hast 
du eine Sammlung von .project files die untereinander nicht kompatibel 
sind.

Diese Baustelle möchte ich nicht mehr öffnen ;-)

temp schrieb:
> Und das ganze Geschwafel von Typesicherheit ist überflüssig wie ein
> Kropf.

Selten so gelacht.

temp schrieb:
> Das paradoxe an C++
> ist hat, mit jeder Erweiterung (c++11/14/17) wurde die Tipparbeit immer
> mehr.

Das stimmt nicht, zumindest nicht in dieser Pauschalität. 7 der 9 von
mir oben genannte Vorzüge von C++≥11

Yalu X. schrieb:
> Die für mich wichtigsten positiven Punkte sind:

führen zu kompakterem und übersichtlicherem Code. Die verbleibenden 2
(Punkte 6 und 7) erfordern zwar etwas mehr Tipparbeit, helfen aber bei
der Aufdeckung von Programmierfehlern, deren Suche sonst i.Allg. mehr
Zeit beansprucht als die paar zusätzlich zu tippenden Zeichen.

Gerade Ast schrieb:
> Was mir nicht so gut gefällt, ist daß die "uniform initialisation" nicht
> der alten Initialisierung gleichwertig ist:

Und das ist m.E. gut so!

Gerade Ast schrieb:
> Siehe auch:
> https://www.youtube.com/watch?v=-AQfQFcXac8  :-)

Da wird einem ja schlecht: new / delete ;-)

Wilhelm M. schrieb:
> Gerade Ast schrieb:
>> Was mir nicht so gut gefällt, ist daß die "uniform initialisation" nicht
>> der alten Initialisierung gleichwertig ist:
>
> Und das ist m.E. gut so!

Das kann man so sehen oder auch nicht. "Gerade Ast", meine Wenigkeit und
viele andere sehen das offensichtlich anders als du.

Wie ich oben schon schrieb und das Beispiel von "Gerade Ast" deutlich
zeigt, ist die "uniform initialization" alles andere als "uniform".

Rätselfrage: Was gibt folgendes Programm aus?

1

#include <iostream>

2

#include <vector>

3

#include "myclasses.h"

4

5

int main() {

6

7

  // use uniform initialization

8

9

  std::vector<MyClass1> v1{2};

10

  std::vector<MyClass2> v2{2};

11

12

  std::cout << v1.size() << '\n';

13

  std::cout << v2.size() << '\n';

14

15

  // use classic initialization

16

17

  std::vector<MyClass3> v3={2};

18

  std::vector<MyClass4> v4(2);

19

20

  std::cout << v3.size() << '\n';

21

  std::cout << v4.size() << '\n';

22

}

Das kommt u.a, darauf an, ob MyClassX ein int ist...

Oliver

Yalu X. schrieb:
> std::vector<MyClass1> v1{2};

och, da können wir doch gleich weitermachen:

1

std::vector<MyClass1> v1(2, 3);

Oliver S. schrieb:
> Das kommt u.a, darauf an, ob MyClassX ein int ist...

Richtig, oder ob MyClassX einen Konstruktor mit int-Argument hat oder
ob int in MyClassX konvertierbar ist ...

Kurz: Verwendet man die uniform Initialization (v1 und v2), muss man
sich in myclasses.h die Typ- bzw. Klassendefinition von MyClassX
anschauen. Mit der klassischen Initialisierung (v3 und v4) ist das
Verhalten sofort ohne weitere Nachforschungen erkennbar.

Wilhelm M. schrieb:
> std::vector<MyClass1> v1(2, 3);

Was ist daran Besonderes? Bei zwei int-Argumenten ist das erste die
Anzahl der Elemente, und damit ist v1.size() auch ohne Kenntnis der
Klassendefinition eindeutig bestimmt, oder nicht?

Yalu X. schrieb:
> Wilhelm M. schrieb:
>> std::vector<MyClass1> v1(2, 3);
>
> Was ist daran Besonderes?

Ich finde die "uniform initialization" konsistenter:

1

    {

2

        std::vector<int> v1(); // ups

3

        std::vector<int> v2(3);

4

        std::vector<int> v3(3, 2); // ist das [2, 2, 2] oder [3, 3] ?

5

        std::vector<int> v4(2, 3);    

6

//        std::vector<int> v5(1, 2, 3);  // warum geht das nicht? 

7

    }

8

    {

9

        std::vector<int> v1{};

10

        std::vector<int> v2{3};

11

        std::vector<int> v3{3, 2};

12

        std::vector<int> v4{2, 3};    

13

        std::vector<int> v5{1, 2, 3};    

14

    }

15

    {

16

        std::array<int, 10> a1; // warum uninitialisierte Elemente?

17

//        std::array<int, 10> a2(3); // warum geht das nicht?

18

    }

19

    {

20

        std::array<int, 10> a1{};

21

        std::array<int, 10> a2{3};

22

        std::array<int, 10> a3{3, 2};

23

        std::array<int, 10> a4{1, 2, 3};

24

    }

25

    {

26

        int i0;   // ?

27

        int i1(); // ups

28

        int i2(4); // s.o. Konsistenz

29

    }

30

    {

31

        int i0{}; // num. Standardwert

32

        int i1{}; 

33

        int i2{4};

34

    }

Yalu X. schrieb:
> Kurz: Verwendet man die uniform Initialization (v1 und v2), muss man
> sich in myclasses.h die Typ- bzw. Klassendefinition von MyClassX
> anschauen. Mit der klassischen Initialisierung (v3 und v4) ist das
> Verhalten sofort ohne weitere Nachforschungen erkennbar.

Was Du hier zitierst, ist nicht ein Thema der uniform-initialization, 
sondern es ist Design-Defekt von std::vector<>. Dieser entsteht durch 
Abwärtskompatibilität, was m.E. auch ein sehr hohes Gut ist.
Der ctor std::vector<T>(int) bzw. std::vector<T>(int, T) gehören nicht 
in die Schnittstelle (zumindest wenn T=int; das sieht man auch daran, 
dass dann die Bedeutung der beiden int nicht klar ist -> Strong-Types). 
Da die jedoch vorher da waren, war es ein Fehler, den 
std::vector<T>(std::initializer_list<T>) hinzuzunehmen (Dies ist ja auch 
schon oft diskutiert worden, aber wegen Abwärtskompatibiliät ... nun 
ja).
Eine Variante wäre es gewesen, in einem anderen Namensraum ein korrekte 
Variante von vector<> anzubieten.

Wilhelm M. schrieb:
> Was Du hier zitierst, ist nicht ein Thema der uniform-initialization,
> sondern es ist Design-Defekt von std::vector<>.

Ob man den Design-Defekt dem std::vector oder der uniform Initialization
zuschreibt, ist IMHO Ansichtssache. Fest steht, dass dieser "Defekt" vor
der Einführung der uniform Initialization nicht in Erscheinung trat.

> Der ctor std::vector<T>(int) bzw. std::vector<T>(int, T) gehören nicht
> in die Schnittstelle (zumindest wenn T=int;

Ich finde den Konstruktor zur Initialisierung des Vektors mit n gleichen
Elementen ganz praktisch.

> das sieht man auch daran, dass dann die Bedeutung der beiden int nicht
> klar ist -> Strong-Types).

Dann wäre also jede Funktion mit zwei oder mehr Argumenten gleichen Typs
defekt? Dann müssten deiner Ansicht nach auch die pow- und die
atan2-Funktion und sogar die Operatoren für Subtraktion und Division
abgeschafft werden? Alternativ könnte man spezielle Datentypen für
Basis, Exponent, y-Koordinate, x-Koordinate, Minuend, Subtrahend,
Dividend und Divisor einführen. Ich bin mir aber sicher: Wenn dies
geschehen würde, würde C++ 90% seiner Gefolgschaft verlieren.

> Da die jedoch vorher da waren, war es ein Fehler, den
> std::vector<T>(std::initializer_list<T>) hinzuzunehmen

Diese ist aber eine der wirklich wertvollen Neuerungen von C++, auf die
ich nicht verzichten wollte. Sie beißt sich auch überhaupt nicht mit
bestehenden Features der Sprache. Der Konflikt entsteht erst im
Zusammenhang mit der – IMHO weitgehend nutzlosen – uniform
Initialization. Letztere wurde nicht vor sondern zusammen mit der
initializer_list (beides C++11) eingeführt, deswegen lag hier der große
Fehler. Diesen Fehler umschiffe ich, indem ich die uniform
Initialization einfach nicht nutze. Es wäre schön, wenn jeder, mit
dessen Quellcode ich arbeiten muss, ebenso handeln würde.

Wilhelm M. schrieb:
> Eine Variante wäre es gewesen, in einem anderen Namensraum ein korrekte
> Variante von vector<> anzubieten.

Eine sehr viel einfachere und elegantere Variante wäre es gewesen, die
uniform Initialization komplett wegzulassen. Für mich scheint das ein
Feature zu sein, dass einfach nicht zu Ende gedacht wurde.

Wilhelm M. schrieb:
> Ich finde die "uniform initialization" konsistenter:
>     {
>         std::vector<int> v1(); // ups
>         std::vector<int> v2(3);
>         std::vector<int> v3(3, 2); // ist das [2, 2, 2] oder [3, 3] ?
>         std::vector<int> v4(2, 3);
> //        std::vector<int> v5(1, 2, 3);  // warum geht das nicht?

Ist doch einfach. Der erste Parameter ist hier immer die Größe. Das ist 
auch ganz unabhängig vom Elementtyp des vectors.

>     }
>     {
>         std::vector<int> v1{};
>         std::vector<int> v2{3};
>         std::vector<int> v3{3, 2};
>         std::vector<int> v4{2, 3};
>         std::vector<int> v5{1, 2, 3};
>     }

Wie mache ich einen vector, der 100 default-initialisierte Elemente hat?

Wilhelm M. schrieb:
> Was Du hier zitierst, ist nicht ein Thema der uniform-initialization,
> sondern es ist Design-Defekt von std::vector<>. Dieser entsteht durch
> Abwärtskompatibilität, was m.E. auch ein sehr hohes Gut ist.

Das ist eben die Crux. Ja, Abwärtskompatibilität ist wichtig, und ja, 
viele der neuen Features haben durchaus ihre Berechtigung, aber es macht 
die Sprache auch sehr unübersichtlich.

Yalu X. schrieb:
> Wilhelm M. schrieb:
>> Was Du hier zitierst, ist nicht ein Thema der uniform-initialization,
>> sondern es ist Design-Defekt von std::vector<>.
>
> Ob man den Design-Defekt dem std::vector oder der uniform Initialization
> zuschreibt, ist IMHO Ansichtssache.

Ja. Offensichtlich sind wir da schon lange unterschiedlicher Ansicht. 
Wir hatten in anderen Threads schon desöfteren darüber geredet.

> Fest steht, dass dieser "Defekt" vor
> der Einführung der uniform Initialization nicht in Erscheinung trat.

Ja. Für den Grund: s.o.

Dafür gab es andere: most-vexing-parse, keine list-initialisierung, ...

>> Der ctor std::vector<T>(int) bzw. std::vector<T>(int, T) gehören nicht
>> in die Schnittstelle (zumindest wenn T=int;
>
> Ich finde den Konstruktor zur Initialisierung des Vektors mit n gleichen
> Elementen ganz praktisch.

Ich auch ;-) Das kann ja auch so bleiben. Falls Du das anders verstanden 
hast, dann hast Du mich oben falsch verstanden. Es ging um den 
mehrstelligen ctor.

>> das sieht man auch daran, dass dann die Bedeutung der beiden int nicht
>> klar ist -> Strong-Types).
>
> Dann wäre also jede Funktion mit zwei oder mehr Argumenten gleichen Typs
> defekt?

Grundsätzlich: ja. Mehrstellige Funktionen mit denselben, unspezifischen 
Datentypen sind m.E. zu vermeiden.

> Dann müssten deiner Ansicht nach auch die pow- und die
> atan2-Funktion und sogar die Operatoren für Subtraktion und Division
> abgeschafft werden?

Nein. Du musst nicht gleich das Kinde mit dem Bade ausschütten.

>> Da die jedoch vorher da waren, war es ein Fehler, den
>> std::vector<T>(std::initializer_list<T>) hinzuzunehmen
>
> Diese ist aber eine der wirklich wertvollen Neuerungen von C++, auf die
> ich nicht verzichten wollte. Sie beißt sich auch überhaupt nicht mit
> bestehenden Features der Sprache.

Genau.

> Der Konflikt entsteht erst im
> Zusammenhang mit der – IMHO weitgehend nutzlosen – uniform
> Initialization.

Und da bin ich eben anderer Meinung: s.o.. Die beiden ctoren (s.o.) 
hätte man eben abschaffen müssen, was natürlich nicht geht. Da die Sache 
aber seit Urzeiten verbockt ist, hätte man es anders lösen müssen.

> Diesen Fehler umschiffe ich, indem ich die uniform
> Initialization einfach nicht nutze. Es wäre schön, wenn jeder, mit
> dessen Quellcode ich arbeiten muss, ebenso handeln würde.

Ich mache es anders herum wie Du weißt: ich / wir arbeiten nur mit 
uniform-initialisation.

> Wilhelm M. schrieb:
>> Eine Variante wäre es gewesen, in einem anderen Namensraum ein korrekte
>> Variante von vector<> anzubieten.
>
> Eine sehr viel einfachere und elegantere Variante wäre es gewesen, die
> uniform Initialization komplett wegzulassen. Für mich scheint das ein
> Feature zu sein, dass einfach nicht zu Ende gedacht wurde.

Der Fehler ist m.E. gewesen, dass man eben die Konsequenzen speziell im 
std::vector<> u.a. nicht bedacht hat. Das kann passieren. Da das Problem 
aber schon sehr früh entdeckt und bemängelt wurde. hätte man es auf 
verschiedene Weise korrigieren können. Das war der fatale Folgefehler.
Bei den Concepts etwa hat man ja wegen ähnlicher Probleme aus dem TS die 
function-style-concepts wieder entfernt - und zwar kurz vor knapp!

Rolf M. schrieb:
> Wilhelm M. schrieb:
>> Ich finde die "uniform initialization" konsistenter:
>>     {
>>         std::vector<int> v1(); // ups
>>         std::vector<int> v2(3);
>>         std::vector<int> v3(3, 2); // ist das [2, 2, 2] oder [3, 3] ?
>>         std::vector<int> v4(2, 3);
>> //        std::vector<int> v5(1, 2, 3);  // warum geht das nicht?
>
> Ist doch einfach. Der erste Parameter ist hier immer die Größe. Das ist
> auch ganz unabhängig vom Elementtyp des vectors.
>
>>     }
>>     {
>>         std::vector<int> v1{};
>>         std::vector<int> v2{3};
>>         std::vector<int> v3{3, 2};
>>         std::vector<int> v4{2, 3};
>>         std::vector<int> v5{1, 2, 3};
>>     }
>
> Wie mache ich einen vector, der 100 default-initialisierte Elemente hat?

Vorschlag:

1

auto v1 = MyVector<MyClass2>{}.fill(10).with(MyClass2{3});

2

auto v2 = MyVector<int>{}.fill(10);

3

auto v3 = fill<MyVector<MyClass2>>(10).with(MyClass2{3});

> Wilhelm M. schrieb:
>> Was Du hier zitierst, ist nicht ein Thema der uniform-initialization,
>> sondern es ist Design-Defekt von std::vector<>. Dieser entsteht durch
>> Abwärtskompatibilität, was m.E. auch ein sehr hohes Gut ist.
>
> Das ist eben die Crux. Ja, Abwärtskompatibilität ist wichtig, und ja,
> viele der neuen Features haben durchaus ihre Berechtigung, aber es macht
> die Sprache auch sehr unübersichtlich.

s.o. meine "Wunschliste" ;-)

Also ich bleibe bei C, im embedded Bereich.

temp schrieb:
> Ich nutze C++, allerdings nicht um jeden Preis. Gerade wenn so ein
> kleiner Controller nur 20k RAM hat dürfte die excessive Verwendung der
> STL sowieso ausgeschlossen sein.

Gerade für kleine µC nutze nur noch C++, natürlich dann ohne stdlib. 
Dadurch werden viel mehr Fehler schon zur Compilezeit aufgedeckt bzw. 
verhindert.

interessant schrieb:
> leider ist das kacke, weil dann alle Interfaces die GpioPin entgegen
> nehmen auch templates sein müssen.

Der sog. CodeBloat, den viele befürchten, ist in der Praxis (bei realen 
Programmen und nicht nur Mini-Beispielen) viel geringen - wenn überhaupt 
vorhanden, und nicht das Gegenteil eintritt - als man denkt. Verzichtet 
man komplett auf dyn. Polymorphie und bei der Modellierung von HW auf 
die Erzeugung von Instanzen, macht stattdessen nur stat. Polymorphie und 
header-only hat man m.E. nur Vorteile.

Wilhelm M. schrieb:
> interessant schrieb:
>> leider ist das kacke, weil dann alle Interfaces die GpioPin entgegen
>> nehmen auch templates sein müssen.
>
> Der sog. CodeBloat, den viele befürchten, ist in der Praxis (bei realen
> Programmen und nicht nur Mini-Beispielen) viel geringen - wenn überhaupt
> vorhanden, und nicht das Gegenteil eintritt - als man denkt. Verzichtet
> man komplett auf dyn. Polymorphie und bei der Modellierung von HW auf
> die Erzeugung von Instanzen, macht stattdessen nur stat. Polymorphie und
> header-only hat man m.E. nur Vorteile.

Da bin ich der gleichen Meinung und Bloat kann man auch mit C erzeugen.
z.B. die STM-HAL erzeugt nicht so knapp Bloat im RAM.

temp schrieb:

snip ...

> Auch hier gibt es keinen Weg bei ausgeschalteter Optimierung das gleiche
> Ergebnis wie mit dem Macro zu erzeugen.
> Das Problem ist ja, vieles wird heute in C++ in die Header verlagert.
> Viel Funktionalität von der man davon ausgeht es ist getesteter Code.
> Die Innereien davon will man meistens nicht debuggen sondern nur seinen
> eigenen Code der das benutzt. Und genau dafür um das zu steuern gibt es
> irgendwie keine Lösung. Es ist ja genauso als wenn ich zum Debuggen
> unter Windows bzw. Linux immer mit den Debug-Versionen alles Systemlibs
> arbeiten würde. Auch auf dem PC komme ich immer ins Fluchen, da die
> Einzelschrittabarbeitung von Code im Debugger fast unmöglich ist.
> Ständig landet man da in den Untiefen der STL, die man ja eigentlich
> überhaupt nicht debuggen will. In dieser Hinsicht hat das jetzte
> Jahrzehnt jedenfalls keinen Fortschritt gebracht.

Ich habe das gerade mit meinem geposteten Code und mit dem gcc 9.3.1 
-std=c++17 -Og gestestet. Beim debugger single step landet er direct in 
meinem "set_bit" mit der Einschränkung das ich mir nicht den parameter 
pack angucken kann. Damit kann ich aber leben. Kommt halt darauf an was 
man will. Ich will z.b. meine selbst geschriebene lib debuggen , aber 
die std libs nicht.

@Wilhelm M
requires kennt der gcc erst ab version 10.

ps. ich habe den Code nochmal angehängt damit man nicht lange suchen 
muss.

Hans-Georg L. schrieb:
> @Wilhelm M
> requires kennt der gcc erst ab version 10.

Bis Du sicher? Auch mit -fconcepts-ts oder -fconcepts? Aber ich weiß es 
nicht mehr genau, ab welcher Version, ist schon sooo lange her.

Trotzdem gebe ich Dir den guten Rat, auf eine aktuelle Version des gcc 
zu gehen, wenn Du den Weg - der super sinnvoll ist - weiter verfolgen 
willst. Denn Concepts sind DAS feature für stat. Polymorphie.

Begreife Klassentemplates als Meta-Funktionen, die Du mit Hilfe von 
Concepts durch partielle Spezialisierung "überladen" kannst: Du kannst 
also eine Meta-Funktion (partielle Spezialisierung) anhand eines 
Concepts für einen template-typ-parameter (oder nttp) aktivieren. Das 
ist die statische Analogie zu single-dispatch bzw. zu tag-dispatching.

Hans-Georg L. schrieb:
> Beim debugger single step landet er direct in
> meinem "set_bit" mit der Einschränkung das ich mir nicht den parameter
> pack angucken kann.

Sollte im mangled-name stehen ...

temp schrieb:
> Deinen Code oben würde ich nicht mal ansatzweise in Erwägung ziehen.
> Alles was nicht mit den Definitionen aus den Headern des Controllers
jeder hat seine Vorlieben ;-)

1

#define RCC_BASE              (AHB1PERIPH_BASE + 0x3800UL)

2

// wird zu

3

constexpr reg32_t RCC_BASE              = AHB1PERIPH_BASE + 0x3800UL;

4

//---------------------

5

typedef struct

6

{

7

  ...

8

   __IO uint32_t AHB1ENR;       /*!< RCC AHB1 peripheral clock register, Address offset: 0x30 */

9

  ...

10

} RCC_TypeDef;

11

// wird zu

12

constexpr reg32_t RCC_AHB1ENR           = RCC_BASE + 0x30U;

13

//------------------------  

14

#define RCC_AHB1ENR_GPIOAEN_Pos            (0U)                                

15

#define RCC_AHB1ENR_GPIOAEN_Msk            (0x1UL << RCC_AHB1ENR_GPIOAEN_Pos)   /*!< 0x00000001 */

16

#define RCC_AHB1ENR_GPIOAEN                RCC_AHB1ENR_GPIOAEN_Msk             

17

// wird zu

18

enum class AHB1_Clock : reg32_t {    

19

   GPIOA = 1<<0,

20

}

21

22

// sollte ich vielleicht besser umbenennen, dann passen alle Namen

23

// genau zum Datenblatt

24

25

enum class RCC_AHB1ENR : reg32_t {    

26

   GPIOAEN = 1<<0,

27

}

Das mit der Namen-Differenz Header zum Datenblatt stört mich bei der HAL 
und der LL.

Wilhelm M. schrieb:
> Trotzdem gebe ich Dir den guten Rat, auf eine aktuelle Version des gcc
> zu gehen, wenn Du den Weg - der super sinnvoll ist - weiter verfolgen
> willst. Denn Concepts sind DAS feature für stat. Polymorphie.
>
> Begreife Klassentemplates als Meta-Funktionen, die Du mit Hilfe von
> Concepts durch partielle Spezialisierung "überladen" kannst: Du kannst
> also eine Meta-Funktion (partielle Spezialisierung) anhand eines
> Concepts für einen template-typ-parameter (oder nttp) aktivieren. Das
> ist die statische Analogie zu single-dispatch bzw. zu tag-dispatching.
Ich habe dem gcc 10.2 von der ARM-Seite auf der Platte und in Eclipse 
als User defined Toolchain in eine Liste eintragen können aber es gibt 
keine Möglichkeit das zu aktivieren. Und im Moment reicht mir das auch 
so wie es ist, die Lib wird auch nicht so bleiben wie sie ist. Was mir 
von den neusten Errungenschaften von C++ das Leben leichter macht nehme 
ich gerne.

temp schrieb:
> Hans-Georg L. schrieb:
>> Das mit der Namen-Differenz Header zum Datenblatt stört mich bei der HAL
>> und der LL.
>
> Wenn es am Ende darauf hinausläuft, alle Registerdefinitionen des
> Controllers neu in eine andere Syntax zu pressen, kann ich mir kaum
> vorstellen, dass da in überschaubarer Zeit eine halbwegs fehlerfreie Lib
> rauskommt.

Das kommt darauf an, woher die ursprünglichen Definitionen kommen. Beim 
AVR gibt's z.B. XML-Dateien, die die Register und andere Dinge 
beschreiben, aus denen die Header generiert werden. Daraus könnte man 
auch entsprechende C++-Header automatisiert generieren.