Lohnt sich embedded in C++ zu programmieren

ManuelGast schrieb:
> Wie ist eure Erfahrung mit C++ in Embeddedwelt?
Definieren "Embeddedwelt"?
Meinst du damit einen Attiny mit 4k Flash oder einen Rechenboliden mit 
Linux?

ManuelGast schrieb:
> Meine Frage an euch: Lohnt es sich überhaupt in C Welt was zu machen
> oder soll ich weiterhin embedded mit C++ programmieren?

Kommt auf die Plattform an ... C++ verwendet viel dynamische allozierten 
Speicher und das funktioniert auf Plattformen ohne richtiger 
Speicherverwaltung nicht.

Außerdem ist zB die STL Library zu groß, als dass man sie sinnvoll auf 
zB einem ATMEGA8 verwenden könnte.

Ich würde sage, sobald man ein richtiges Betriebssystem (wie zB Linux) 
hat, kann man sich in vollem Umfang in C++ austoben.

ManuelGast schrieb:
> Lothar M. schrieb:
>> Definieren "Embeddedwelt"?
>
> genau gesagt der STM32

Ich vermute daher kein Linux?

Wie geschrieben, kannst du machen, du musst aber auf alles verzichten, 
was dynamisch allozierten Speicher verwendet.

Arduino F. schrieb:
> Nutze die Vorteile von C++ möglichst weitgehend.
Du meinst die Subklasse von C++, die für den Arduino implementiert ist?
Oder gibt es da auch Exceptions und Typinformationen zur Laufzeit?

Ich verweise mal auf 
https://www.mikrocontroller.net/articles/C_vs_C%2B%2B

Mampf F. schrieb:
> ManuelGast schrieb:
>> Lothar M. schrieb:
>>> Definieren "Embeddedwelt"?
>>
>> genau gesagt der STM32
>
> Ich vermute daher kein Linux?
>
> Wie geschrieben, kannst du machen, du musst aber auf alles verzichten,
> was dynamisch allozierten Speicher verwendet.

Würde ich so nicht sagen. Ich hab hier einen STM32F4 mit 192 kB RAM. Das 
ist durchaus genug, um auch mit dynamischem Speicher sinnvoll arbeiten 
zu können. Aber man kann auch schon viele C++-Features verwenden, ohne 
dazu dynamischen Speicher zu benötigen.
Ich finde C++ dort durchaus sinnvoll, allerdings ist es auch richtig, 
dass in der Praxis kaum jemand µCs in C++ programmiert.

Lothar M. schrieb:
> Arduino F. schrieb:
>> Nutze die Vorteile von C++ möglichst weitgehend.
> Du meinst die Subklasse von C++, die für den Arduino implementiert ist?

Vermutlich das, was der g++ für den AVR zur Verfügung stellt, denn den 
nutzt Arduino.

> Oder gibt es da auch Exceptions und Typinformationen zur Laufzeit?

Eher nicht. Als ich mir das das letzte mal angeschaut habe, ging das 
nicht, weil die libsupc++ nicht für den AVR geeignet war.
Aber man muss ja auch nicht zwingend alle Features von C++ verwenden, 
um einen Nutzen gegenüber C zu haben.

Lothar M. schrieb:
> Definieren "Embeddedwelt"?
> Meinst du damit einen Attiny mit 4k Flash oder einen Rechenboliden mit
> Linux?

Spielt das denn eine Rolle?

Mampf F. schrieb:
> Kommt auf die Plattform an ... C++ verwendet viel dynamische allozierten
> Speicher

Nein. Es ist nicht C++, das dynamische Speicherallokation benutzt, 
sondern der jeweilige Programmierer benutzt sie -- oder eben nicht.

> Ich würde sage, sobald man ein richtiges Betriebssystem (wie zB Linux)
> hat, kann man sich in vollem Umfang in C++ austoben.

Das ist zwar durchaus richtig, aber man kann viele Vorzüge von C++ auch 
ohne Betriebssystem nutzen -- auch auf kleinen Controllern.

ManuelGast schrieb:

> Wie ist eure Erfahrung mit C++ in Embeddedwelt?

Ich nutze C++ laufend für z.B. Cortex M / ARM Controller. Man muss 
wissen, was welches C++ feature kostest und es gibt ein paar Ecken und 
Kanten mit der Toolchain. Aber nichts was einem daran hindert, C++ 
sinnvoll einzusetzen.

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

Arduino F. schrieb:
> Wenn man in einem Team steckt, wird man sich an die Firmen/Team
> Ausrichtung halten müssen.
>
> Als Hobbybastler ist man da freier.
> Ich schätze mal, dass die Programme, welche man in seiner
> Lieblingssprache schreibt, im allgemeinen besser gelingen.
> Sei es C, oder C++, oder noch ganz was anderes.
>
> Das ultimative KO Kriterium ist immer wieder:
> Erfüllt die Anwendung die gestellten Anforderungen?

Das sehe ich ganz ähnlich, daher hab ich eigentlich immer C im Einsatz. 
Ich sehe für mich am Bastler-Tisch keine Notwendigkeit/Vorteil, C++ 
einzusetzen.  Und in der Firma ist es ähnlich.
Egal für welche Programmiersprache (ASM, C, C++, Bascom) man sich 
entscheidet, man muss sich einen roten Faden definieren und dann kommt 
man eigentlich mit Sprache auch zurecht.

Vielleicht auch einfach mal hier schauen:

Beitrag "Informationen zu C vs C++ / aka Futter für die Diskussion"

[1] In C ist es "einfach", Programme zu schreiben, die compiliert werden 
können, aber sich zur Laufzeit falsch verhalten.

[2] In C++ "kann" man so programmieren, dass Programme, die die 
einfachen Fehler aus [1] enthalten, nicht compiliert werden können.

Ich bevorzuge [2]: Compile-Zeit Fehler sind mit lieber als 
Laufzeit-Fehler ...

(... und ohne Overhead zu erzeugen ...)

Die "STL" ist eine von SGI in den 90ern entwickelte Bibliothek für C++. 
Diese wird kaum noch verwendet. Ihr meint wahrscheinlich die "C++ 
Standard Library", welche von der STL beeinflusst, aber nicht identisch 
und viel größer ist. Nur ein kleiner Teil dieser Bibliothek besteht aus 
Containern, und auch denen könnte man per Allokator die dynamische 
Speicherverwaltung abgewöhnen. Den Großteil kann man ganz problemlos 
auch auf Mikrocontrollern verwenden. Was spricht z.B. gegen die Nutzung 
von "uint32_t"? Oder von "std::numeric_limits"? Oder "std::max"? 
Letzteres ist z.B. etwas, das in C so nicht möglich wäre. templates 
ermöglichen ganz neue Arten der Programmstruktur, sind aber etwas schwer 
lesbar.

Ich durfte leider feststellen, dass wenn man Leuten gratis ein Embedded 
Programm anbietet, die dann nur daran herum kritteln dass es C++ ist. 
C++ scheint die Emotionen derart hoch kochen zu lassen, dass die Sicht 
auf die Funktionalität versperrt wird. Das ist ein Nachteil...

Folgende Punkte sind m.E. zu berücksichtigen, und zwar ganz unabhängig 
von der Sprache:

1) Sattelfestheit in der Sprache

Man sollte in der Sprache möglichst sattelfest sein. Wissen über die 
Sprache stützt sich auf Wissen über die Sprache und deren Spezifikation 
und nicht auf Reverse-Engineering (Debugging, Simulation, Trial & 
Error).

Das "Man" schließt hier alle Entwickler ein, also auch diejenigen, die 
Reviewing und Testing durchführen (insbesondere bei White-Box Testing) 
und schließlich mit der Wartung der Software betraut werden.

2) Verfügbarkeit und Support der Sprache.

Wie sieht die Entwicklungsumgebung aus:  Gibt es professionellen 
Support, etwa wenn ein Bug im Compiler oder den Standard-Bibliotheken 
gibt?  Wie sieht es aus mit Debugger, Simulator, Tools zur statischen 
Analyse?

3) Umfeld

Wer wir den Code pflegen und wer führt Reviews durch? Nur dass eine 
Sprache mehr Features zur Verfügung stellt, bedeutet noch nicht, dass 
man diese adäquat nutzen kann und daraus wartbarer Code entsteht.

Selbst wenn ein Sprachvirtuose die Software komponiert, besteht die 
Gefahr, dass die Software als "unwartbar" eingestuft wird, in der Tonne 
landet und neu aufgezogen wird, sobald der Virtuose nicht mehr verfügbar 
ist. (Manchmal wird das dann so gelesen, Virtuosität sei ein Vehikel, um 
sich "unersetzlich" zu machen).

Kernighan: Debugging is twice as hard as writing the code in the first 
place. Therefore, if you write the code as cleverly as possible, you 
are, by definition, not smart enough to debug it.

4) Wartbarkeit

Verfügbarkeit einer Vielzahl von Paradigmen / Features muss nicht 
unbedingt ein Vorteil sein.  Die Wartbarkeit hängt nicht nur von der 
Sprache ab, sondern vor allem auch vom Design:  In einer "alten" Sprache 
kann man sehr wohl ein guten Design haben, und eine "neue" Sprache 
schützt nicht vor schlechtem Desig.

5) Embedded

Man braucht eine recht konkrete Vorstellung davon, welcher Code 
generiert wird — je eingeschränkter die Systemresourcen (Laufzeit, 
Speicherverbrauch) in einer konkreten Situation / Modul sind, desto 
genauer muss man wissen was man tut, und desto genauer muss man dies 
kontrollieren können.

Wilhelm M. schrieb:
> [1] In C ist es "einfach", Programme zu schreiben, die compiliert werden
> können, aber sich zur Laufzeit falsch verhalten.
Öhm, das schafft man mit C++ aber auch wenn man will.
Wilhelm M. schrieb:
> [2] In C++ "kann" man so programmieren, dass Programme, die die
> einfachen Fehler aus [1] enthalten, nicht compiliert werden können.
-Wall -Werror kann ich da empfehlen.

ManuelGast schrieb:
> Lohnt es sich überhaupt in C Welt was zu machen
> oder soll ich weiterhin embedded mit C++ programmieren?

Ich würd mal sagen, probiers aus.
Wenn Du mit C++ klarkommst, warum nicht. Ich guck da eher rein, wie ein 
Schwein ins Uhrwerk.

Was willst Du denn auf dem µC programmieren. Richtige Harwaresteuerungen 
oder auch nur PC-Zeugs (GUI, Netzwerk, Datenträger).

Mampf (unterwegs) schrieb:
> Ich wollte damit sagen, das ist oft nicht ersichtlich, ob dynamischer
> Speicher verwendet wird.
Und das ist in C anders? Bei printf() würde man es auch nicht erwarten, 
aber z.B. das printf() der newlib C library benötigt malloc(). Da hilft 
bei beiden Sprachen nur, in die Doku zu schauen.

Stefan U. schrieb:

> Darüber haben wir gerade im Büro diskutiert. Es kommt darauf an, dass
> alle Beteiligten mit dem Code und den Tools zurecht kommen. Das bedeutet
> in der Praxis oft, dass man nicht alle Features verwendet.

Das klingt für mich nach er Anleitung zur Abwärtspirale. Damit 
orientiert ihr euch doch immer am "schwächsten" Kollegen (im 
Zweifelsfall, an dem Kollegen, der frisch von der Uni gekommen ist). 
Jeder muss ständig überlegen, ob sein Kollege dieses Feature nun kennt 
und versteht, statt seine Aufgaben in maximaler Effektivität zu 
erledigen.

Etwas neues lernt man so auch nicht (zumindest nicht von Kollegen). Und 
wahrscheinlich gehen die besten Kollegen irgendwann, weil sie keine Lust 
mehr haben, ausgebremst mit dem rechten Arm auf den Rücken gebunden zu 
arbeiten.

Stefan U. schrieb:
> Darüber haben wir gerade im Büro diskutiert. Es kommt darauf an, dass
> alle Beteiligten mit dem Code und den Tools zurecht kommen. Das bedeutet
> in der Praxis oft, dass man nicht alle Features verwendet.

Man muß ja auch nicht alle Features verwenden. Selbst wenn man nur ein 
einziges nützliches Feature einsetzt, spricht das schon für C++.

Torsten R. schrieb:
> Stefan U. schrieb:
>
>> Darüber haben wir gerade im Büro diskutiert. Es kommt darauf an, dass
>> alle Beteiligten mit dem Code und den Tools zurecht kommen. Das bedeutet
>> in der Praxis oft, dass man nicht alle Features verwendet.
>
> Das klingt für mich nach er Anleitung zur Abwärtspirale. Damit
> orientiert ihr euch doch immer am "schwächsten" Kollegen (im
> Zweifelsfall, an dem Kollegen, der frisch von der Uni gekommen ist).
> Jeder muss ständig überlegen, ob sein Kollege dieses Feature nun kennt
> und versteht, statt seine Aufgaben in maximaler Effektivität zu
> erledigen.
>
> Etwas neues lernt man so auch nicht (zumindest nicht von Kollegen). Und
> wahrscheinlich gehen die besten Kollegen irgendwann, weil sie keine Lust
> mehr haben, ausgebremst mit dem rechten Arm auf den Rücken gebunden zu
> arbeiten.

Das sehe ich genauso, und das ist genau auch die Antwort, die ich hier 
schon ab und zu mal im Forum gegeben habe.

Man sollte mal über Abhilfe nachdenken:

https://www.fluentcpp.com/2017/04/04/the-dailies-a-new-way-to-learn-at-work/

Torsten R. schrieb:
> Das klingt für mich nach er Anleitung zur Abwärtspirale. Damit
> orientiert ihr euch doch immer am "schwächsten" Kollegen (im
> Zweifelsfall, an dem Kollegen, der frisch von der Uni gekommen ist).

Nach meiner Erfahrung sind die Kollegen, die frisch von der Uni kommen, 
ziemlich fit, kennen auch aktuelle Features recht gut und können sich im 
Zweifelsfall auch schnell in Unbekanntes hinein fuchsen, weil sie jung, 
ans Lernen gewöhnt und offen für Neues sind. Problematischer ist es oft 
mit den älteren Kollegen, die schon seit Jahren im Beruf stehen und dies 
oder jenes "schon immer so gemacht" haben.

Das spiegelt sich auch in meinen Erfahrungen bei C++-Diskussionen hier 
im Forum: es scheinen eher die Älteren zu sein, die sich mit Händen und 
Füßen gegen neue Trends wehren, während viele Jüngere dem gegenüber 
offener zu sein scheinen. Möglicherweise liegt das daran, daß das Lernen 
neuer Sachverhalte mit zunehmendem Alter immer anstrengender wird, oder 
sich mit steigender Erfahrung auch eine gewisse Eingefahrenheit 
einstellt.

Mampf (unterwegs) schrieb:
> Sheeva P. schrieb:
>> Nein. Es ist nicht C++, das dynamische Speicherallokation benutzt,
>> sondern der jeweilige Programmierer benutzt sie -- oder eben nicht.
>
> Man sieht doch oft überhaupt nicht, ob ein Template aus der zb STL
> dynamischen Speicher verwendet, ob er vlt nur einmal alloziert wird oder
> ob da wild mit new und deletes jongliert wird.

In 95% der Fälle ist es offensichtlich, zum Beispiel bei allen 
Containern, denen zur Laufzeit neue Elemente hinzugefügt werden können. 
Und bei allen anderen Fällen reduziert es sich darauf, ob man sein 
Werkzeug beherrscht.

> New und delete komplett zu vermeiden ist erstaunlich schwer ... ich
> hatte längere Zeit nach einem zB demarshaller für JSON in C++ gesucht,
> der mit einem statischen Block RAM.auskommt.

Das findest Du dabei aber nicht ernsthaft verwunderlich, oder?

Torsten R. schrieb:
> Stefan U. schrieb:
>
>> Darüber haben wir gerade im Büro diskutiert. Es kommt darauf an, dass
>> alle Beteiligten mit dem Code und den Tools zurecht kommen. Das bedeutet
>> in der Praxis oft, dass man nicht alle Features verwendet.
>
> Das klingt für mich nach er Anleitung zur Abwärtspirale. Damit
> orientiert ihr euch doch immer am "schwächsten" Kollegen (im
> Zweifelsfall, an dem Kollegen, der frisch von der Uni gekommen ist).
> Jeder muss ständig überlegen, ob sein Kollege dieses Feature nun kennt
> und versteht, statt seine Aufgaben in maximaler Effektivität zu
> erledigen.

Wenn im Team gearbeitet wird, denn zählt zunächst die Effektivität des 
Teams als Ganzem.

Neues zu lernen ist erstmal eine Bremse.  Es braucht Zeit und es braucht 
Motivation.  Wenn jemand bereits flüssig und sicher in einer Sprache 
ist, und muss oder soll zur Lösung eines neuen Problems eine neue 
Sprache lernen, in der er unsicher ist und nur langsam voramkommt und 
womöglich noch Zeitdruck hat, dann ist das höchst unmotiviered.

Und zum Lernen gehört auch zu, sich mit anderen Lernenden austauschen zu 
können, keinen Zeit- oder Projektdruck zu daben, ohne Zweckbindung mit 
dem Neuen rumspielen zu können und auch Fehler machen zu dürfen.

Gerade letzteres ist bei "Learning by Doing" nicht gegeben, denn das 
Doing ist i.d.R. die Umsetzung eines Projekts.  Spätestens wenn die 
Fehler beim Kunden oder im Feld angekommen sind, kannst man sich 
ausmalen, dass da nicht mit Milde auf den (damals) Lernenden 
zurückgeblickt wird, sondern Projekt- und Geschäftsleitung höchst 
unerfreut sind.  Beim nächsten "Experiment" bleibt man dann bei den 
bewährten olle Kamellen.

Wie das genau gehandabt wird häng natürlich von der Unternehmenskultur 
oder -nichtkultur ab.  Ob sich nun die Fitten abgehängt sind oder die 
weniger Fitten sei dahingestellt und hängt auch von persönlichen 
Befindlichkeiten und vom Management ab.

Johann L. schrieb:
> Neues zu lernen ist erstmal eine Bremse.

Das Erlernen von Neuem ist vor allem eine Investition. Als solche muß 
sie sich zunächst amortisieren und sollte sich danach rentieren.

Achim S. schrieb:
> Als Fakt sehe ich aber auch an: Die Sprache C ist einfacher als C++.
> Einfacher im Sinne des Sprachumfangs.

Wenn das ein Argument wäre, dann wären die meistgenutzten Programmier- 
sprachen heute Brainfuck oder Whitespace [1]. Sind sie aber nicht.

> Das erlaubt es bei geschickter Benamung, Kapselung

Oh Ja. Laß uns doch einfach mal bei Kapselung bleiben. Hat C schlicht 
und ergreifend nicht. Und schon hat C++ gewonnen. Ja, ok ist nur ein 
Punkt. Aber ein wichtiger.


[1] 
https://de.wikipedia.org/wiki/Kategorie:Esoterische_Programmiersprache

batman schrieb:
> Axel S. schrieb:
>> Oh Ja. Laß uns doch einfach mal bei Kapselung bleiben. Hat C schlicht
>> und ergreifend nicht. Und schon hat C++ gewonnen. Ja, ok ist nur ein
>> Punkt. Aber ein wichtiger.
>
> Naja, wenn du alles von der Compilertechnik bzw. Sprache abhängig
> machst, hast du schon verloren, würde ich sagen. Konstrukte wie
> Kapselung sind da nur Krücken, um schlechte Konzepte möglichst
> abzublocken. Man kann aber auch gleich mit gutem Konzepten anfangen,
> wenn man es gelernt hat.

Kapselung IST eins der guten Konzepte!
Konzepte finden nämlich im Abstrakten statt und das ist doch, so die 
gängige Haßmeinung, DIE Domäne von C++.


(UpToDate)C++ hat vor allem constexpr, was bei kleinen Tiny's den 
Vorteil hat, daß ein Teil des Programms vorab auf dem Intel/AMD-Boliden 
gerechnet wird, wo GigaByte und GigaHerz in Hülle und Fülle bereit 
stehen, dem kleinen AVR unter die Arme zu greifen.

temp schrieb:
> Fakt ist eins, wenn man die neuen Features von C++ verwendet kann man
> nicht auf einmal Programme schreiben die man ohne nicht schreiben
> könnte.

Ja. Man kann aber ähnliche Programme eleganter, wartbarer und in vielen 
Fällen plattformunabhängig und standardkonform schreiben -- und man muß 
auch nicht alles sofort ändern, umstellen, oder gar neu machen. 
Zumindest nicht im Falle von C++, das mit dem etablierten 
Industriestandard C doch weitgehend kompatibel ist.

> Mit anderen Worten, die alten Hasen haben für die üblichen
> Problemstellungen längst Lösungen in der Schublade.

Ja, genau das meine ich mit "eingefahren": das beliebte "dat hamwer 
immer so jemacht". Nur: wer immer alles so macht, wie er es immer schon 
gemacht hat, macht zwar nichts falsch, entwickelt sich aber auch nicht 
weiter.

> Und nur zum
> Selbstzweck macht man das halt nicht eben mal alles neu nur weil es
> eventuell einen eleganteren Weg gibt.

Niemand redet davon, "eben mal alles neu" zu machen -- das geht doch gar 
nicht, schon gar nicht zum Selbstzweck. Was soll denn das?

> In einem anderen Thread hat gerade
> jemand eine ltoa-Variante in c++ vorgestellt. Angeblich schneller als
> die üblichen in den Libs. Kann ja sein. Allerdings ist das nun ein Roman
> geworden der wenigstens 3-5mal so lang im Quellcode geworden ist.

Tja... wenn das wirklich schneller ist, kann es je nach Anwendungsfall 
trotzdem sinnvoll sein, es zu nutzen.

Ansonsten ist es eher unklug, Herangehensweisen anhand einzelner 
Beispiele zu beurteilen. Statistische Betrachtungen mit einer 
Probengröße von 1 sind eher wertlos.

> Und
> in der Industrie lässt sich schon gleich niemand zu einer kompletten
> Neuentwicklung bewegen nur weil es moderner ist.

Meine Güte... von einer kompletten Neuentwicklung redet doch keiner, das 
ist doch Quatsch. Aber es ist durchaus möglich und eigentlich auch fast 
immer sinnvoller, schrittweise vorzugehen.

Achim S. schrieb:
> Das greift mir zu kurz. Ein unbeschriebenes Blatt ist natürlich
> flexibler und motivierter, weil es meist eben nicht mit C-Profis
> mithalten kann.

Das ist der Handel zwischen Erfahrung einer- und Kreativität 
andererseits. Ich habe einen jungen Mathematik-Master und eine 
mathematisch-technische Softwareentwicklerin im Team, und die schreiben 
C- und auch C++-Code, der einfach zum Niederknien schön ist.

> Und nach ein paar Jahren stellt man fest, dass die guten
> jungen Programmierer C++ Wüsten in Write-only-Style hinterlassen haben.
> So wie die guten alten in C. Den Produktivcode von heute haben halt die
> paar sehr guten Programmierer verantwortet, aufgrund derer die Firma
> heute noch lebt. Und nur wenn bei den jungen auch ein paar sehr gute
> dabei sind, wird sie die nächsten Jahre mit C, C++ oder auf Rollschuhen
> ebenfalls überleben.

Zu glauben, ein Unternehmen würde wegen seiner Codequalität überleben, 
... das würde mir einige Optionen für die nächste Gehaltsverhandlung 
eröffnen, erscheint mir aber etwas unrealistisch. Dafür überleben 
nämlich leider zu viele Unternehmen mit einer Codequalität, die mit 
"unter aller Sau" noch ausgesprochen wohlwollend beschrieben ist.

Darüber hinaus finde ich Deine Argumentation etwas inkonsistent. Du 
sagst ja, daß die "guten alten" "sehr guten Programmierer", eine "Wüste" 
in C hinterlassen hätten und die jungen das dann eben in C++ tun würden. 
Dabei ist mir allerdings nicht ganz klar, warum eine Code-Wüste in C 
besser sei als eine in C++. Möglicherweise siehst Du das ja anders als 
ich, aber ich persönlich bevorzuge gar keine Code-Wüsten -- in egal 
welcher Sprache.

Vielleicht habe ich ja wirklich Glück gehabt und bisher immer nur gute 
Jungspunde getroffen, das kann ich natürlich nicht ausschließen. Aber 
was denen an Erfahrung fehlt, machen sie mit aktuellem Knowledge, 
Querdenken, neuen Ideen und Engagement wett. Wenn Du solche Leute 
jemandem zuordnest, der sie mit seiner Erfahrung unterstützen oder sogar 
führen kann, ist das keine schlechte Kombination.

> Als Fakt sehe ich aber auch an: Die Sprache C ist einfacher als C++.

Ja, nein, vielleicht. Kommt darauf an. Und die Sprache Python ist 
einfacher als C. Spricht das gegen C, gegen C++, oder gegen Python? ;-)

batman schrieb:
> Konstrukte wie Kapselung sind da nur Krücken, um schlechte Konzepte
> möglichst abzublocken. Man kann aber auch gleich mit gutem Konzepten
> anfangen, wenn man es gelernt hat.

Ja klar. Und Sicherheitsgurte sind auch nur Krücken, um bei Unfällen den 
Schaden für die Insassen zu reduzieren. Man kann stattdessen aber auch 
einfach keine Unfälle bauen.

Axel S. schrieb:
> Oh Ja. Laß uns doch einfach mal bei Kapselung bleiben. Hat C schlicht
> und ergreifend nicht. Und schon hat C++ gewonnen. Ja, ok ist nur ein
> Punkt. Aber ein wichtiger.

Natürlich hat C Kapselung.

Sheeva P. schrieb:
>> New und delete komplett zu vermeiden ist erstaunlich schwer ... ich
>> hatte längere Zeit nach einem zB demarshaller für JSON in C++ gesucht,
>> der mit einem statischen Block RAM.auskommt.
>
> Das findest Du dabei aber nicht ernsthaft verwunderlich, oder?

Nein, aber nichtsdestotrotz hab ich so einen Demarshaller benötigt.

Mampf (unterwegs) schrieb:
> Man sieht doch oft überhaupt nicht, ob ein Template aus der zb STL
> dynamischen Speicher verwendet, ob er vlt nur einmal alloziert wird oder
> ob da wild mit new und deletes jongliert wird.
...
> Ich wollte damit sagen, das ist oft nicht ersichtlich, ob dynamischer
> Speicher verwendet wird.

Das siehst du in der Template Deklaration (Allocator = 
std::allocator<T>).

Du kannst dir auch deinen eigenen Allocator schreiben.

Oder du nimmst static Boost Versionen, bspw. boost::static_vector.

Stefan U. schrieb:
> Dann hast du noch nicht gesehen, wie man in C Objektorientiert
> programmiert. Namespaces würde man dort vermissen, kann man in der
> Praxis jedoch durch eine Namenskonvention ersetzen. Und
> objektorientierte Programmierung ist dort durchaus möglich.

Ich hab das mal gesehen, bei Gtk - und fand es nicht grad schön. 
Ellenlange Funktionsnamen, um Namespaces, Klassen und Überladung zu 
ersetzen und viel fehlerträchtige Makro-Magie, um das dynamische 
Typsystem zu ersetzen.

Mikro 7. schrieb:
> Oder du nimmst static Boost Versionen, bspw. boost::static_vector.

Oder halt gleich den Standard-Typ: std::array.

Rolf M. schrieb:
> Mikro 7. schrieb:
>> Oder du nimmst static Boost Versionen, bspw. boost::static_vector.
>
> Oder halt gleich den Standard-Typ: std::array.

Ein Vector kann seine Größe ändern, ein Array nicht. Das wird bspw. dann 
interessant, wenn du keinen Default Constructor für deine Elemente hast.

Stefan U. schrieb:
> Ja, C++ hat ein paar coole Features, die C nicht hat. Aber das heißt
> noch lange nicht, dass man nur in C++ sauber objektorientiert
> programmieren kann.

Ja, unter anderem Hashmaps ;-) Also 2 Tage in den Sand gesetzt, weil 
flasches Werkzeug verwendet.

avr schrieb:
> OOP ist in c++ auch ein recht kleiner Teil. Auf der anderen Seite kann
> OOP in c sehr ekelhaft werden und damit schlecht wartbar.

Wenn man sich keine Gedanken dazu vorher macht kann OOP auch in C++ sehr 
hässlich werden.

Aber mal ernsthaft: Der Thread driftet IMO zu sehr ins C/C++ gebashe ab. 
Das führt doch zu nichts. Beide Sprachen haben, auch im Embedded 
Bereich, ihre Berechtigung.

Nop schrieb:
> Torsten R. schrieb:
>
>> Ja, unter anderem Hashmaps ;-) Also 2 Tage in den Sand gesetzt, weil
>> flasches Werkzeug verwendet.
>
> Eine der Anforderungen war: "es stand nur die Programmiersprache und die
> Standard C Library zur Verfügung".

Naja, wenn er C++ genommen hätte, wären die Anforderungen halt: nur die 
Programmiersprache und die zugehörige Standard Library...

Stefan U. schrieb:
>>> Als Fakt sehe ich aber auch an: Die Sprache C ist einfacher als C++.
>>> Einfacher im Sinne des Sprachumfangs.
>
>> Wenn das ein Argument wäre, dann wären die meistgenutzten Programmier-
>> sprachen heute Brainfuck oder Whitespace [1]. Sind sie aber nicht.
>
> Nun, Java erfreut sich einer auffälligen Beliebtheit. Und Java fühlt
> sich für mich wie ein vereinfachtes C++ an (ich muss es wissen, denn ich
> verdiene damit seit 15 Jahren mein Brot).

Sprich mich lieber nicht auf Java an. Das ist eine der grauenhaftesten 
Programmiersprachen, die ich gesehen habe. Und ich habe viel gesehen.

>> Laß uns doch einfach mal bei Kapselung bleiben. Hat C schlicht
>> und ergreifend nicht. Und schon hat C++ gewonnen.
>
> Dann hast du noch nicht gesehen, wie man in C Objektorientiert
> programmiert.

Bedauerlicherweise habe ich das schon gesehen. Genau daher kommt meine 
Beobachtung, daß C keine Kapselung hat. Wenn ich in C++ ein Member einer 
Klasse als private deklariere, dann erlaubt mir der Compiler nicht, von 
außerhalb darauf zuzugreifen. Das ist Kapselung.

In C kann ich vielleicht einen Kommentar an ein "privates" struct-Member 
schreiben. Oder im Bezeichner die Silbe "privat" unterbringen. Aber der 
Compiler wird mir nicht mal eine Warnung geben, wenn jemand unbefugt 
darauf zugreift. Das ist die Abwesenheit von Kapselung.

Versteh mich recht: ich habe nicht gesagt daß es unmöglich wäre, in C 
objektorientiert und strukturiert und mit Kapselung und was auch immer 
gerade Mode ist, zu programmieren. Das geht immer. Auch in Assembler 
oder Brainfuck (Herr Turing läßt grüßen). Aber es ist doch deutlich 
komfortabler und vor allem viel weniger fehlerträchtig, wenn die 
Toolchain einen dabei unterstützt.

Axel S. schrieb:
> Sprich mich lieber nicht auf Java an. Das ist eine der grauenhaftesten
> Programmiersprachen, die ich gesehen habe. Und ich habe viel gesehen.

Und dennoch hält sich diese Sprache hartnäckig über Jahrzehnte und wird 
immer erfolgreicher. Soo schlecht kann diese Sprache also auch nicht 
sein.

Axel S. schrieb:
> In C kann ich vielleicht einen Kommentar an ein "privates" struct-Member
> schreiben. Oder im Bezeichner die Silbe "privat" unterbringen. Aber der
> Compiler wird mir nicht mal eine Warnung geben, wenn jemand unbefugt
> darauf zugreift. Das ist die Abwesenheit von Kapselung.

Dass es nicht wie in C++ funktioniert ist schon klar, man kann es aber 
schon so aufbauen, dass es auch eine Kapselung gibt. Dazu muss man 
natürlich erstmal klar definieren, was man unter Kapselung versteht.

M. K. schrieb:
> Axel S. schrieb:
>> Sprich mich lieber nicht auf Java an. Das ist eine der grauenhaftesten
>> Programmiersprachen, die ich gesehen habe. Und ich habe viel gesehen.
>
> Und dennoch hält sich diese Sprache hartnäckig über Jahrzehnte und wird
> immer erfolgreicher. Soo schlecht kann diese Sprache also auch nicht
> sein.

Dafür gibt es viele Gründe, aber sicher nicht, daß Java eine großartige 
Programmiersprache wäre. Zum einen hat Java zur Zeit seiner Entstehung 
durchaus eine Lücke gefüllt. Es war - der damaligen Mode entsprechend - 
objektorientiert [1]. Außerdem plattformunabhängig (was sich in der 
Praxis allerdings relativiert hat). Es erlaubt (wichtig!) Code in 
Binärform weiterzugeben und damit vor unauthorisierter Nutzung 
auszuschließen. Es enthielt (im Gegensatz zum damaligen 
Hauptkonkurrenten C++) Bibliotheken für GUI und Threads im 
Standard-Sprachumfang.

Und mittlerweile ist die Codebasis so groß, daß sich ein Wechsel weg von 
Java aus rein praktischen Gründen verbietet.

Der Vergleich mit VHS oder Microsoft Windows/Office drängt sich auf. 
Auch jeweils kein großer Wurf. Aber irgendwie "good enough" und "wir 
hatten ja nichts anderes" und schließlich "jetzt können wir nicht mehr 
wechseln" bzw. "alle anderen nutzen es, da müssen wir mit".


[1] Sogar zu objektorientiert, wenn du mich fragst. Daß z.B. eine 
Funktion wie max() oder main() nicht eigenständig sein darf, sondern als 
statische Methode einer ansonsten leeren Klasse implementiert werden 
muß, empfinde ich als sprachdesignerische Fehlleistung. Zumal wenn die 
totale Objektorientierung an anderer Stelle ganz zwanglos aufgehoben 
wird, z.B. um einen Datentyp (kein! Objekt) int neben der Klasse 
Integer zuzulassen. Und damit man sich auch ja unwohl fühlt, werden 
die Operationen die man typischerweise für Zahlen braucht, hübsch 
zwischen beiden aufgeteilt.

Axel S. schrieb:
> Dafür gibt es viele Gründe, aber sicher nicht, daß Java eine großartige
> Programmiersprache wäre.

Hab ich auch nicht behauptet, dass Java eine großartige 
Programmiersprache wäre. Ich sagte nur, dass sie nicht so schlimm sein 
kann

Axel S. schrieb:
> Und mittlerweile ist die Codebasis so groß, daß sich ein Wechsel weg von
> Java aus rein praktischen Gründen verbietet.

Dieser Grund ist IMO, ich sag mal, Unsinn. Wollte man davon weg wäre die 
Codebasis ziemlich egal. Aber auf der anderen Seite: Wenn man eine 
Codebasis hat, die man für OK findet, warum sollte man zu was anderem 
wechseln wollen? Man würde dann ja keinen Vorteil erringen.
Und da sind wir eigentlich am Punkt der Sache: Wenn man vernünftig 
programmiert, sich klare Strukturen erarbeitet hat, dann hat auch keine 
Programmiersprache einen klaren Vorteil. Daher wird sich die Diskussion 
auch stets nur im Kreis drehen können.

Diese Diskussion hier verläuft eigentlich wie immer, wenn es um das 
Thema C vs C++ geht. Man kann sich da gelassen zurück lehnen, und dem 
Treiben belustigt zusehen ... es ist immer das gleiche ;-)

Was allerdings m.E. dabei nie genügend beachtet wird, ist die Tatsache, 
das C++ eine Multiparadigmen-Sprache ist:

- man kann OOP nutzen
- man kann auch rein prozedural formulieren
- man kann meta-programmatisch arbeiten
- man kann funktional schreiben

Zudem kann man noch Laufzeit- und Compilezeit-Kontext unterscheiden. Und 
kann auch noch C-Code einbinden ...

Und bei allem ist man genauso effizient (manchmal effizienter) als im 
direkten Vergleich zu C.

Wenn wir jetzt noch den "starship"-Operator und "unified function call 
syntax" bekommen, wird es wohl noch schlimmer mit der Diskussion.

Dabei geht es ja wohl nur um die Vorlieben oder Kenntnisstand der 
einzelnen Entwickler bzw. das Einsatzgebiet des Softwareartefakts: auf 
Maschinen mit vielen Ressourcen wird man wohl eher gerne zu OOP inkl. 
Laufzeitpolymorphie  greifen. Auf Maschinen mit wenig Ressourcen eher 
prozedural bleiben und die Vorteile der Meta-Programmierung nutzen. Wer 
gerne abstrakt formuliert, mag sicher den funktionalen Ansatz. Und eine 
lange Tool-Kette zum Bauen kann man teilweise verkürzen durch einen 
Compilezeit-Kontext.

Das das alles den ein oder anderen verwirrt, kann ich verstehen. Für 
mich ist es eher eine Bereicherung, denn ich kann das Paradigma wechseln 
ohne eine neue Sprache benutzen zu müssen.

Aber man sollte bei dem Thema C vs C++ nicht vergessen, das es keinen 
Zwang gibt, sich so oder so auszurichten. Der Zwang entsteht durch 
äußere Einflüsse wie etwa Firmenpolitik oder Team-Skills. Wobei man 
beides durchaus weiter entwicklen kann ;-)

Nop schrieb:
> Nein. Das alles in einer anderen Programmiersprache nochmal neu zu
> machen kostet Zeit und Geld, ohne daß die Kunden davon was hätten.

Deswegen war bei mir ja auch der Konjunktiv drin: "Wollte man davon weg"
Dann beachtet man auch was es einen kostet "alles noch mal neu zu 
machen" ;)

Nop schrieb:
> Wilhelm M. schrieb:
>
>> Was allerdings m.E. dabei nie genügend beachtet wird, ist die Tatsache,
>> das C++ eine Multiparadigmen-Sprache ist:
>>
>> - man kann OOP nutzen
>> - man kann auch rein prozedural formulieren
>> - man kann meta-programmatisch arbeiten
>> - man kann funktional schreiben
>
> Und wenn dann in einem größeren Team kein Subsetting betrieben UND auch
> durchgesetzt wird, kriegt man eine Codebasis, in der jeder Beteiligte
> seine 30% Vorlieben eingebracht hat. Die arme Sau von
> Maintenance-Programmierer, die da drei Jahre nach Projektende ransoll.

Also am besten eine Sprache, die weniger kann als C ... am besten eine, 
die gar nichts kann, dann passieren keine Fehler und es entsteht kein 
Know-How-Problem ...

Wilhelm M. schrieb:
> Was allerdings m.E. dabei nie genügend beachtet wird, [...]
>
> - man kann [...]
> - man kann [...]
> - man kann [...]
> - man kann [...]
>
> Zudem kann man noch [...]

> Diese Diskussion hier verläuft eigentlich wie immer, wenn es um das
> Thema C vs C++ geht.

Weil es m.E. garnicht um C vs. C++ geht, sondern um die Frage, wie man 
als nicht-C++ Programmierer den Graben zu C++ überwinden kann.

> Der Zwang entsteht durch äußere Einflüsse wie etwa Firmenpolitik
> oder Team-Skills.

Wo hast du denn C++ gelernt?  Bist du in der Industrie in ein Team 
gekommen und hast es dort gelernt und auf dein heutiges Niveau gebracht?

Wievel Monate oder Jahre hat das gedauert? Und zurückblickend: Gibt es 
Code, von dem du sagen würdest "OMG! Heute würd ich das viel besser 
machen und statt XXX besser YYY verwenden?". Oder war alles je 
ausprogrammierte "zum niederknien schön", hat tadellos und ohne 
Reklamation funktioniert?

Allein in diesem Thread könnte ich 2 Duzend Buzz-Words (oder Paradigmen 
oder wie auch immer) von dir zusammenkratzen, wo ich keinen blassen 
Schimmer hab, was das ist und wozu ich das brauchen könnte.  Und von C++ 
weiß ich genug, um zu wissen, dass ich diese Sprache niemals auf einem 
Niveau beherrschen werde, welches meinen eigenen Maßstäben und 
Ansprüchen auch nur annähernd entsprechen würde — und mit jedem 
Buzz-Word wird meine Gewissheit darüber größer und nicht etwa kleiner.

Und ja, ich verwende C++, aber nur in einem durch Coding-Rules 
definierten Subset, das im Endeffekt "C with Classes" ist; oder in 
Fun-Projekten oder irdenwelchen Nerd-Tools. Wenn ich mir anschaue, wie 
Qt ein QObject::connect implementiert, dann ist das weiß Gott nicht zum 
niederknien schön.

Wenn PeDa oben schreibt, er blickt bei C++ wie'n "Schwein ins Uhrwerk", 
dann spricht das Bände.

Man steht eben nicht nach einer C++ Convention über einem Gläschen Sekt 
mit anderen Akademikern zusammen und fachsimpelt über das neueste C++ 
Feature.  Der harte Alltag sieht anders aus.

Folgende Analogie:  Nimm einen Mediziner, etwa einen sehr guten 
Zahnarzt.  Bei wem würdest du dich für eine Herz-OP unters Messer legen? 
Einem Kardiologen, der Kardiologie und Chirurgie an der Uni vertiefte 
und als Harzchirurg  erfolgreich gearbeitet hat, oder einem Dentisten, 
der Zahnmedizin an der Uni vertiefte, erfolgreich darin gearbeitet hat, 
und sich denn per Google und selbst gekaufter Bücher in Kardiologie und 
Chirurgie reingestrampelt hat?

Einen solchen Dentisten, der ablehnt dich zu operieren, würde ich nicht 
als rückständig oder lernfaul oder nicht-innovativ bezeichnen. Sondern 
er kennt einfach seine Grenzen und unterliegt nicht der Hybris zu 
glauben, etwas zu können, was er nicht von der Pike auf studiert hat. 
Und um wieviel besser oder cooler — gleich in welcher Metrik bemessen — 
Kardiologie und Chirurgie im Vergleich zur Zahnmedizin auch sein mögen, 
wieviel erfüllender die Arbeit oder auch sein mag; spielt schlicht und 
einfach keine Rolle.

> Kenntnisstand der einzelnen Entwickler

Ja.  Genau darum geht es.  Und wie man über das Uncanny Valley rüber 
kommt, oder eben nicht.

> Auf Maschinen mit wenig Ressourcen eher prozedural bleiben und die
> Vorteile der Meta-Programmierung nutzen. Wer gerne abstrakt formuliert,

oder verwenden graphische Tools oder Code-Generatoren.

> Tool-Kette zum Bauen

Oder so: Anstatt Software fit zu machen, lässt man die Tools für 
200€-500€ pro Zeile aufbohren weil:  Die Software ist ja zertifiziert 
und abgenommen, die Toolchain wird's richten.  Willkommen in der 
Realität.

Johann L. schrieb:
> Weil es m.E. garnicht um C vs. C++ geht, sondern um die Frage, wie man
> als nicht-C++ Programmierer den Graben zu C++ überwinden kann.

Naja, wie würdest Du denn vorgehen, um Haskell zu erlernen (sofern das 
noch nicht zu Deinen Lieblingssprachen gehört)?

> Wievel Monate oder Jahre hat das gedauert? Und zurückblickend: Gibt es
> Code, von dem du sagen würdest "OMG! Heute würd ich das viel besser
> machen und statt XXX besser YYY verwenden?".

Selbstvertsändlich. Leider gibt es davon immer mehr, je mehr ich lerne 
;-)

> Oder war alles je
> ausprogrammierte "zum niederknien schön", hat tadellos und ohne
> Reklamation funktioniert?

Mmh, kann mich nicht daran erinnern, das behauptet zu haben.

> Allein in diesem Thread könnte ich 2 Duzend Buzz-Words (oder Paradigmen
> oder wie auch immer) von dir zusammenkratzen,

Echt, nur zwei Dutzend ... wusste doch, dass ich das Computerwoche Abo 
nicht hätte kündigen sollen. Vielleicht kannst Du sie mir gerade nochmal 
zusammenstellen, damit ich mich beim nächsten Mal nicht wiederholen 
muss.

> wo ich keinen blassen
> Schimmer hab, was das ist und wozu ich das brauchen könnte.  Und von C++
> weiß ich genug, um zu wissen, dass ich diese Sprache niemals auf einem
> Niveau beherrschen werde, welches meinen eigenen Maßstäben und
> Ansprüchen auch nur annähernd entsprechen würde — und mit jedem
> Buzz-Word wird meine Gewissheit darüber größer und nicht etwa kleiner.

Das finde ich doch gar nicht schlimm - dann lass es doch einfach, wenn 
es Dich unglücklich macht ;-)

> Und ja, ich verwende C++, aber nur in einem durch Coding-Rules
> definierten Subset, das im Endeffekt "C with Classes" ist;

Wunderbar, wenn Du damit nichts vermisst und auch keine Zeile, kein 
Design siehst, die Du besser machen möchtest, ist das für mich auch 
absolut ok.

> oder in
> Fun-Projekten oder irdenwelchen Nerd-Tools. Wenn ich mir anschaue, wie
> Qt ein QObject::connect implementiert, dann ist das weiß Gott nicht zum
> niederknien schön.

Kann mich auch nicht erinnern, dass das hier in den Raum gestellt wurde. 
Ich glaube auch, dass würde sogar Lars Knoll, et. al. nicht unbedingt 
sagen.

> Wenn PeDa oben schreibt, er blickt bei C++ wie'n "Schwein ins Uhrwerk",
> dann spricht das Bände.

Das verstehe ich ja nun gar nicht !?

> Folgende Analogie:  Nimm einen Mediziner, etwa einen sehr guten
> Zahnarzt.  Bei wem würdest du dich für eine Herz-OP unters Messer legen?
> Einem Kardiologen, der Kardiologie und Chirurgie an der Uni vertiefte
> und als Harzchirurg

Harzchirurg ist jetzt aber kein Wortspiel, oder?

> Einen solchen Dentisten, der ablehnt dich zu operieren, würde ich nicht
> als rückständig oder lernfaul oder nicht-innovativ bezeichnen.

Absolut: ich wollte Dich auch gar nicht bitten, für mich C++-Code zu 
schreiben ;-)

>> Kenntnisstand der einzelnen Entwickler
>
> Ja.  Genau darum geht es.  Und wie man über das Uncanny Valley rüber
> kommt, oder eben nicht.

Da sind wir uns ja einer Meinung, denn ich gehe davon aus, dass auch Du 
Stillstand nicht als Lösung ansiehst. Übrigens hatte ich etwas weiter 
oben mal ein Maßnahme dazu erwähnt.

> Willkommen in der
> Realität.

Genau, es gibt auch schon wieder Spekulatius 8-()

Moby schrieb im Beitrag #5238859:
> aller Eigenwerbung der ach so eingängigen
> Objektorientierung zum Trotz.
OOP: 1 Pin = 1 Objekt. 1 Timer = 1 Objekt. 1 externer Portexpander = 1 
Port-Expander-Objekt bestehend aus 1 I²C-Slave-Objekt + 8 Pin-Objekte.
Prozedural: 1 Pin = Zwei Integer plus 23 Funktionen? 1 externer 
Portexpander = Zwei Funktions-Ebenen + 3 Integer? Super intuitiv. Es hat 
schon einen Grund warum OOP von den meisten Programmiersprachen 
unterstützt wird.

Niklas G. schrieb:
> Moby schrieb im Beitrag #5238859:
>> aller Eigenwerbung der ach so eingängigen
>> Objektorientierung zum Trotz.
> OOP: 1 Pin = 1 Objekt. 1 Timer = 1 Objekt. 1 externer Portexpander = 1
> Port-Expander-Objekt bestehend aus 1 I²C-Slave-Objekt + 8 Pin-Objekte.
> Prozedural: 1 Pin = Zwei Integer plus 23 Funktionen? 1 externer
> Portexpander = Zwei Funktions-Ebenen + 3 Integer? Super intuitiv. Es hat
> schon einen Grund warum OOP von den meisten Programmiersprachen
> unterstützt wird.

Da es eher selten ist, dass ein z.B. Portexpander zur Laufzeit die 
verwendeten Pins wechselt, macht es keinen Sinn, die Info zu den Pins 
oder des verwendeten I2C-Moduls zur Laufzeit zu repräsentieren. So etwas 
gehört in den Typ und damit wird dafür auch kein Ram verbraucht.

Wilhelm M. schrieb:
> So etwas
> gehört in den Typ und damit wird dafür auch kein Ram verbraucht.
Dann müssen aber alle anderen Klassen & Funktionen, die darauf 
zugreifen, ebenfalls templates sein. Je nach Programmgröße wird das 
ziemlich umständlich.

Niklas G. schrieb:
> Wilhelm M. schrieb:
>> So etwas
>> gehört in den Typ und damit wird dafür auch kein Ram verbraucht.
> Dann müssen aber alle anderen Klassen & Funktionen, die darauf
> zugreifen, ebenfalls templates sein. Je nach Programmgröße wird das
> ziemlich umständlich.

Nein, warum?

Wilhelm M. schrieb:
> Nein, warum?
Bezieht sich jetzt worauf genau?

Niklas G. schrieb:
> Wilhelm M. schrieb:
>> Nein, warum?
> Bezieht sich jetzt worauf genau?

Auf das umständlich.

Wilhelm M. schrieb:
> Auf das umständlich.

Wenn der Pin-Zugriff die unterste Architektur-Ebene ist und mehrere 
weitere Ebenen drauf aufsetzen, müssen alle deren Klassen templates 
sein. Wenn an einer Stelle ein Array von Pins, die per I²C oder direkt 
angesteuert werden können, angelegt werden soll, wird es auch 
interessant wenn jedes Element einen anderen Typ hat je nach 
Hardware-Interface. Auch dass praktisch immer alles neu kompiliert 
werden muss wenn sich ein Detail der untersten Ebene ändert macht es 
nicht einfacher.

Niklas G. schrieb:
> Wilhelm M. schrieb:
>> Auf das umständlich.
>
> Wenn der Pin-Zugriff die unterste Architektur-Ebene ist und mehrere
> weitere Ebenen drauf aufsetzen, müssen alle deren Klassen templates
> sein.

Ja klar. Aber wo ist das umständlich?

> Wenn an einer Stelle ein Array von Pins, die per I²C oder direkt
> angesteuert werden können, angelegt werden soll, wird es auch
> interessant wenn jedes Element einen anderen Typ hat je nach
> Hardware-Interface.

Variadische templates.

> Auch dass praktisch immer alles neu kompiliert
> werden muss wenn sich ein Detail der untersten Ebene ändert macht es
> nicht einfacher.

Da ist mir unklar, was Du meinst.

Wilhelm M. schrieb:
> Ja klar. Aber wo ist das umständlich?
Man schreibt sehr oft "template". Plötzlich sind Klassen templates, die 
gar nichts mehr mit einzelnen Pins zu tun haben.

Wilhelm M. schrieb:
> Variadische templates.
Ja. Super kompliziert. Iteration und wahlfreie Zugriffe sind schwierig. 
Generiert sehr viel Code.

Wilhelm M. schrieb:
> Da ist mir unklar, was Du meinst.
Wenn sich die template-Parameter an die Pin-Instanzen ändern und 
daraufhin auch die Parameter an alle darauf aufbauenden Instanzen, 
müssen die komplett neu kompiliert werden. Man hat eine sehr enge 
Kopplung.

Niklas G. schrieb:
> Wilhelm M. schrieb:
>> Ja klar. Aber wo ist das umständlich?
> Man schreibt sehr oft "template". Plötzlich sind Klassen templates, die
> gar nichts mehr mit einzelnen Pins zu tun haben.

Was ist daran umständlich, ein std::array<std::byte, 10> zu verwenden?

>
> Wilhelm M. schrieb:
>> Variadische templates.
> Ja. Super kompliziert. Iteration und wahlfreie Zugriffe sind schwierig.

Mit fold-expressions m.E. einfacher.

> Generiert sehr viel Code.

Gegenüber was?

> Wilhelm M. schrieb:
>> Da ist mir unklar, was Du meinst.
> Wenn sich die template-Parameter an die Pin-Instanzen ändern und
> daraufhin auch die Parameter an alle darauf aufbauenden Instanzen,
> müssen die komplett neu kompiliert werden.

Dafür haben wir doch den Compiler ;-)

> Man hat eine sehr enge
> Kopplung.

Die Koppelung zwischen generischen Typen ist m.E. i.a. geringer als bei 
anderen Arten der Polymorphie.

Arduino F. schrieb:
> Moby schrieb im Beitrag #5239023:
>
>
> Nen Papagei verschluckt?

Dem Typ zu antworten ist das Falsche.
Für ihn gibt es den "Beitrag melden"-Link.

temp schrieb:
> Ein Aspekt wurde hier noch nicht betrachtet den ich mal mit in die Runde
> werfe. Macht man sich z.B. eine Template-Klasse für Gpio-Ports ala
>
> GpioPort<PORTA, 5> LedRed;
.
> und hat alle Funktionen der Klasse schön als inline declariert, handelt
> man sich während des Debuggens Unannehmlichkeiten ein. Während des
> Debuggens mit der Optimierung -O0 macht der Compiler richtige
> Funktionsaufrufe und keine inline Funktionen. Klar kann man jetzt beim
> Debuggen z.B. -O1 benutzen, damit kann man aber häufig nicht mehr
> richtig Debuggen. Hätte man die in C üblichen Makros für die Gpio-Ports
> benutzt wäre das Problem nicht vorhanden. Gerade in Interrupt-Routinen
> ist so ein Verhalten nervig. Klar kann man das Umschiffen oder
> Optimierungs-Pragmas in den Code einbauen, aber schön ist das trotzdem
> nicht.
> Alles in allem muss man bei C++ als Effekt immer im Auge haben, dass die
> Laufzeitunterschiede -O0 zu -O2 in der Regel deutlich größer sind als
> unter C. Vielfach stört das nicht, aber wenn dann verflucht man es.

Man kann natürlich auch speziell für's Debuggen vorgesehene Option -Og 
benutzen, dann wird das Programm nicht "entstellt", aber auch nicht wie 
bei -O0 Registerinhalte immer wieder ohne Grund stupide neu geladen.

Carl D. schrieb:
> Man kann natürlich auch speziell für's Debuggen vorgesehene Option -Og
> benutzen, dann wird das Programm nicht "entstellt", aber auch nicht wie
> bei -O0 Registerinhalte immer wieder ohne Grund stupide neu geladen.

Allerdings hilft es nicht bei dem oben genannten Problem mit dem 
Inlining.