Welche Programmiersprache auf µC

[Wilhelm M. (wimalopaan)]

Atlas schrieb:
> Wilhelm M. schrieb:
>> Naja, wenn Du nur einen Faustkeil zur Verfügung hast, brauchst viele
>> Arbeitsschritte, machst viele Fehler und verbrauchst u.U. mehr Material,
>> um ein Handy zu bauen, als wenn Du die richtigen Maschinen verwendest.
>
> Und Du glaubst wirklich, Asm+C/C++ vs. Faustkeil/richtige Maschine wär
> ein passender Vergleich? Warum hat (Misra-)C eine jahrzehntelang
> unangefochtene Stellung bei den MCs? Die Antwort auf diese Frage würde
> glaube ich weiterführen!

Misra-C gibt keine Antwort auf die Frage C vs C++.

Misra-C++ gibt auch keine Antwort auf die Frage C++ vc C.

Diese Guidelines betrachten jeweils nur die Zielsprache.

[Carl D. (jcw2)]

Wilhelm M. schrieb:
> Atlas schrieb:
>
>> Sheeva P. schrieb:
>>> der
>>> Glaube, C++ würde mehr CPU-Takte, mehr RAM oder mehr Flash verbrauchen,
>>> ist falsch -- und ein Vorurteil
>>
>> Nö. Weil Menschen damit programmieren. Je komplexer das Werkzeug desto
>> schwieriger der richtige Einsatz. Das übersiehst Du mit einer
>> vehementen Konstanz die fast schon beängstigend ist :)
>
> Naja, wenn Du nur einen Faustkeil zur Verfügung hast, brauchst viele
> Arbeitsschritte, machst viele Fehler und verbrauchst u.U. mehr Material,
> um ein Handy zu bauen, als wenn Du die richtigen Maschinen verwendest.

Oder auch: wer bisher nur einen Faustkeil hatte, wird den Vorteil eines 
Hammers nicht verstehen, wenn er ihn identisch einsetzt. Er wird sich 
dann über den störenden Holzstock ärgern.

Eigentlich darf's aber jeder machen, wie er's will. (Sie auch)
Das gilt für Assembler-Freunde, C-Liebhaber,
aber das darf dann bitte auch für die gelten, die lieber C++ benutzen.

[Atlas (Gast)]

Wilhelm M. schrieb:
> Misra-C gibt keine Antwort auf die Frage C vs C++.

Misra-C und nicht etwa Misra-C++ steht hier in erster Linie für den 
Standard automobiler Steuergeräte-Software. Deren MC-Bedarf ist wie man 
weiß nicht ganz unwesentlich.

Carl D. schrieb:
> Eigentlich darf's aber jeder machen, wie er's will.

Das mag ja als salomonisches Urteil durchgehen gibt aber letztlich keine 
Hilfestellung zum Thema. Den Gläubigen des no-limit abstrakten C++ 
Himmels auf MCs möchte ich noch zurufen: Manchmal ist weniger mehr, man 
kann alles auch übertreiben!

[Jörg W. (dl8dtl) (Moderator)]

Atlas schrieb:
> Misra-C und nicht etwa Misra-C++ steht hier in erster Linie für den
> Standard automobiler Steuergeräte-Software.

Dass es aber mittlerweile ein Misra-C++ überhaupt gibt, zeigt, dass 
dafür offensichtlich durchaus Bedarf war.

[avr (Gast)]

@Atlas
Bevor das hier mit dir so weiter geht, würde mich zuerst interessieren, 
wie gut du überhaupt C++ kennst. Aus deinen Beiträgen heraus lese ich 
eher, dass du damit nicht wirklich zurecht kommst.

Dass C++ nur langsam in der Embedded-Welt ankommt, hängt mMn eher damit 
zusammen, dass die C++ Compiler, verglichen mit den C-Compilern, eher 
jung sind. Bis sich das dann in einer schon älteren Firma durchsetzt, 
dauert das eben etwas. Ich habe das Gefühl, dass tendenziell in 
kleineren Firmen eher C++ programmiert wird. Wahrscheinlich, weil es in 
großen Firmen häufig zu viele Personen gibt, die sich dagegen sträuben - 
mit dem unausgesprochenen Hauptargument, dass sie die Sprache, so hart 
es klingt, einfach nicht beherschen.

Natürlich kann es sinnvoll sein, kleine Projekte in C durchzuführen, 
weil man weniger qualifizierte Arbeitskräfte einsetzen kann. Wenn man 
allerdings schon eine entsprechende Codebasis durch andere Projekte in 
C++ hat, dann zieht das auch nicht mehr. Mit Klassen lässt sich 
Peripherie wunderbar abstrahieren, und das ohne Overhead, vorausgesetzt 
man macht es richtig (nicht wie bei Arduino).

[Wilhelm M. (wimalopaan)]

AVRler schrieb im Beitrag #5039410:
> avr schrieb:
>> mit dem unausgesprochenen Hauptargument, dass sie die Sprache, so hart
>> es klingt, einfach nicht beherschen
>
> Weil die Sprache eben doch lernintensiver ist?

Selbstverständlich!

> Weil viele Entwickler darin für ihre Arbeit keinen Vorteil sehen?

Das mag sein - geschieht m.E. aber einfach aus Unkenntnis bzw. dem 
mangelnden Willen oder der mangelnden Zeit, sich da einzuarbeiten (s. 
Posts weiter oben).

> avr schrieb:
>> Mit Klassen lässt sich
>> Peripherie wunderbar abstrahieren, und das ohne Overhead,
>
> Das ist doch ein Märchen.

Eben nicht (s.o.: Unkenntnis).

[Torsten R. (Firma: Torrox.de) (torstenrobitzki)]

AVRler schrieb im Beitrag #5039410:

> Das ist doch ein Märchen. Die periphere Hardware ist dazu viel zu
> unterschiedlich. Davon abgesehen benötigt die einfache Peripherie eines
> AVRs keine solchen Kopfstände.

Naja, wenn ich auf jeder Plattform schon mal das gleiche Interface zu 
GPIOs und Timern hätte, wäre doch schon viel gewonnen.

Ich denke, soetwas kann sehr gut funktionieren, wenn ich meine 
Bedürfnisse an die Hardware möglichst konkret definieren kann. Wenn ich 
also eine effektive PWM haben möchte, dann müsste ich das meiner Library 
so mitteilen. Wenn die Plattform dann peripherals für PWM hat, dann wird 
das direkt darauf abgebildet. Wenn nicht, wird das halt mit einem Timer 
umgesetzt.

Soetwas kann man mit C++ mit Zero-Overhead Abstraction machen, das ist 
aber viel Arbeit. Und nein, sagt nicht wieder, dass es nicht geht, wenn 
ihr C++ nicht kennt.

[Einer K. (Gast)]

Hi!

Darf ich auch mal?
(Öl ins Feuer gießen?)


Ich bin nicht nur Arduino Fan, sondern auch noch OOP Fan obendrauf.
Damit ist schon mal ganz klar, welche, c oder C++, ich bevorzuge.

Davon ab, sind beide Turing vollständig.
Also in letzter Instanz gleichwertig.

Es ist also eher ein Geschmacksfrage.
Und das ist dann der Nährboden für Grabenkriege.


In der beruflichen Praxis stellt sich die Frage nur selten.
Ein Hobby Programmierer mag sich daran aufgeilen, aber in der Firma/Team 
wird meist die Firmenlinie verfolgt.
Ohne Not davon abweichen?
Nö!
Mit Recht!

[Jörg W. (dl8dtl) (Moderator)]

Arduino F. schrieb:
> aber in der Firma/Team wird meist die Firmenlinie verfolgt

Die muss aber auch mal jemand festlegen.  Gelegentlich dürfte sie
sich auch ändern, ansonsten würden wohl heute einige große Firmen
noch immer alles in FORTRAN programmieren. :)

Wie oben schon festgestellt worden ist: in kleinen Firmen dürften
solche Änderungen weniger „politischen Wirbel“ verursachen als in
großen.  Da macht man's einfach, wenn man sich Vorteile davon
verspricht.

[Einer K. (Gast)]

[ot]

Jörg W. schrieb:
> Die muss aber auch mal jemand festlegen.

Hier mal was zum Thema:
"Konservativ" vs." jeden Scheiß mit machen"
https://www.youtube.com/watch?v=VdTXdGf4WQQ


[/ot]

[Karl Käfer (Gast)]

Da gibt sich aber jemand Mühe, die Diskussion zu stören. ;-)

[Chris F. (chfreund)]

Karl Käfer schrieb:
> Da gibt sich aber jemand Mühe, die Diskussion zu stören. ;-)

Wie "stören"? Das sieht hier aus wie das Internet nach dem 
Netzwerkdurchdringungsgesetz ... :-D

[W.S. (Gast)]

Torsten R. schrieb:
> Naja, wenn ich auf jeder Plattform schon mal das gleiche Interface zu
> GPIOs und Timern hätte, wäre doch schon viel gewonnen.

Ach wo.

Gleiche Interfaces sind genau dort von Vorteil, wo man es mit immer 
wieder gleichartigen Datenströmen zu tun hat, also serielle Interfaces 
aller Art, SDIO, Grafik-Aufbau in einen Bildspeicher für 
Display-Aufgaben und dergleichen.

Aber schon bei den Timern und noch viel mehr bei den schieren GPIO's 
hört das komplett auf. Das, was dort stattfindet, ist eigentlich immer 
derart projektabhängig, daß es absolut kontraproduktiv wäre, dort deinen 
Gedanken in die Tat umzusetzen. Stattdessen braucht es Treiber, die das 
jeweilige Problem direkt in eine höhere Ebene umsetzen.

Also mal ganz vulgär:
nicht "SetzePin(Port,Nummer,Zustand);"
sondern "SchalteMotorEin();"

Kurzum, der Versuch, auf niedrigster Ebene zu vereinheitlichen, ist 
unproduktiv. Sowas muß man auf einer angemessenen höheren Ebene machen.

W.S.

[Nop (Gast)]

Torsten R. schrieb:

> Naja, wenn ich auf jeder Plattform schon mal das gleiche Interface zu
> GPIOs und Timern hätte, wäre doch schon viel gewonnen.

STs HAL ist ein Versuch in diese Richtung, zumindest auf STM32. Das 
reale Ergebnis ist dann, daß man erstens das Datenblatt immer noch lesen 
muß, um zu verstehen, welche Optionen man genau hat, und sich zweitens 
auch noch mit der HAL rumschlagen muß. Nicht nur, wie man das benutzen 
soll, sondern schlimmer noch, wenn man das dann auch noch debuggen muß.

Und wehe, man will das dann auch noch plattformübergreifend erweitern. 
Das wird dann in der Praxis schnell fragmentieren, weil man immer 
irgendwelche Sachen hat, die mit der Architektur so genau aber gerade 
nicht gehen.

Das erreicht den Punkt, an dem man das wegwerfen kann und schneller mit 
ein paar Registerzugriffen am Ziel ist.

Die Kehrseite von Abstraktion ist Obfuscation. Mir scheint eh, daß es da 
grundlegend unterschiedliche Denkansätze gibt.

Der eine sagt, je mehr Abstraktion, desto besser, und möchte 
idealerweise reine Mathematik machen. Die grundsätzliche Denkweise ist 
abstrakt und wird bei Bedarf konkretisiert. Scheint mir typisch für 
Informatiker zu sein.

Der andere möchte das Modell so einfach wie möglich halten, so daß es 
gerade noch den vorliegenden Fall ausreichend genau annähert. Die 
grundsätzliche Denkweise ist konkret, und die Modellierung ist nicht 
Abstraktion, sondern Vereinfachung. Typisch für Ingenieure.

Und dann gibt's noch die Physiker, die in jeder Sprache Fortran 
schreiben.

[Sheeva P. (sheevaplug)]

avr schrieb:
> Dass C++ nur langsam in der Embedded-Welt ankommt, hängt mMn eher damit
> zusammen, dass die C++ Compiler, verglichen mit den C-Compilern, eher
> jung sind. Bis sich das dann in einer schon älteren Firma durchsetzt,
> dauert das eben etwas. Ich habe das Gefühl, dass tendenziell in
> kleineren Firmen eher C++ programmiert wird. Wahrscheinlich, weil es in
> großen Firmen häufig zu viele Personen gibt, die sich dagegen sträuben -
> mit dem unausgesprochenen Hauptargument, dass sie die Sprache, so hart
> es klingt, einfach nicht beherschen.

Na, wer würde schon zu seinem Chef so etwas sagen wie "jetzt nochmal 
nicht nur eine ganz neue Sprache, sondern sogar ein ganz neues Paradigma 
lernen, och nö, lieber nicht". Also mein Vorgesetzer würde mich dann 
nicht ganz zu Unrecht fragen, ob ich wohl noch alle Tässchen im 
Schränkchen habe.

Deswegen wird dann lieber ausgewichen auf "ach nö, Chef, das kostet 
enorme Ressourcen, dafür brauchen wir größere und teurere Controller und 
müßten außerdem unsere ganze bewährte Codebasis umbauen". Im 
Zweifelsfall kann man sogar schnell ein Beispielchen mit Exceptions, 
dynamischer Polymorphie und ähnlichen Schmankerln bauen, und seine 
Aussagen damit "beweisen".

Was höre ich da, das klänge jetzt arg konstruiert? Ja, ist es, aber 
leider habe ich solche Vermeidungs- und Verweigerungsstrategien schon 
erlebt, bei Kollege und auch bei Vorgesetzten. "Das hamwer immer schon 
so jemacht" ist doch immer wieder ein starkes Argument.

[Vincent H. (vinci)]

Nop schrieb:
> Torsten R. schrieb:
>
>> Naja, wenn ich auf jeder Plattform schon mal das gleiche Interface zu
>> GPIOs und Timern hätte, wäre doch schon viel gewonnen.
>
> STs HAL ist ein Versuch in diese Richtung, zumindest auf STM32. Das
> reale Ergebnis ist dann, daß man erstens das Datenblatt immer noch lesen
> muß, um zu verstehen, welche Optionen man genau hat, und sich zweitens
> auch noch mit der HAL rumschlagen muß. Nicht nur, wie man das benutzen
> soll, sondern schlimmer noch, wenn man das dann auch noch debuggen muß.
>
> Und wehe, man will das dann auch noch plattformübergreifend erweitern.
> Das wird dann in der Praxis schnell fragmentieren, weil man immer
> irgendwelche Sachen hat, die mit der Architektur so genau aber gerade
> nicht gehen.
>
> Das erreicht den Punkt, an dem man das wegwerfen kann und schneller mit
> ein paar Registerzugriffen am Ziel ist.
>
> Die Kehrseite von Abstraktion ist Obfuscation. Mir scheint eh, daß es da
> grundlegend unterschiedliche Denkansätze gibt.

Eigentlich ist kein einziger Chiphersteller daran interessiert 
vernünftige Bibliotheken anzubieten. Bibliotheken bringen kein Geld und 
verkaufen keine Hardware. Umso flexibler so eine Bibliothek wäre, umso 
einfacher wäre ein Port zu einem Fremdprozessor. Eine quasi 
platformübergreifende Lösung entspräche einem Supergau, da man plötzlich 
an Konkurrenten, die 0.0001c billiger verkaufen können bereits Kunden 
verliert...

Es ist ja nicht so als wäre ARM nicht bemüht dem entgegenzuwirken. Man 
versucht mit Dingen wie CMSIS und mbed zu kontern wo es nur geht. Es 
gibt das SVD Format zur Hardware Beschreibung und sogar Code-Gen Tools 
für zig-tausende Zeilen lange Header. Die Realität sieht dann so aus, 
dass etwa ST nicht einmal innerhalb von winzigen Prozessorfamilien (z.B. 
L4) jene SVD Files und Header konstant hält. Da wird gepfutscht und 
gepatzt wo es nur geht, mit Sicherheit mangels Interesse und vielleicht 
sogar aus schlichtem Kalkül. Obwohl mbed zugegebenermaßen eher die IoT 
Seite anspricht und nicht die "Hardcore"-Embedded Seite, so ist alles 
über dem setzen eines GPIO Pins ein Krampf... da bekommt man dann 
ungefähr ein Gefühl dafür, wie ernst es Chiphersteller mit 
Software-Unterstützung sehn.

[Gesichtshaarloser (Gast)]

Kenuino F. schrieb:
> Hi!
>
> Darf ich auch mal?
> (Öl ins Feuer gießen?)

<cite>
:
Everybody I know, whether it’s personal or corporate, selects a subset 
and these subsets are different. So it’s not a good language to 
transport an algorithm—to say, “I wrote it; here, take it.” It’s way too 
big, way too complex.
:
– Ken Thompson, interviewed about C++ for the book Peter Seibel, Coders 
at work , Apress, 2009
</cite>

Trotz des Zitats bin ich nicht vorbehaltslos nur pro-C; aber wo er Recht 
hat, hat der alte Bartträger ins Schwarze getroffen.

[Gesichtshaarloser (Gast)]

>> Da gibt sich aber jemand Mühe, die Diskussion zu stören. ;-)
>
> Wie "stören"? Das sieht hier aus wie das Internet nach dem
> Netzwerkdurchdringungsgesetz ... :-D

oder die Moderatoren waren wiedermal nicht mit dem selbst gewählten 
Automatismus zufrieden und haben von Hand den GarbageCollector 
angeschubst.

[Sheeva P. (sheevaplug)]

W.S. schrieb:
> Gleiche Interfaces sind genau dort von Vorteil, wo man es mit immer
> wieder gleichartigen Datenströmen zu tun hat, also serielle Interfaces
> aller Art, SDIO, Grafik-Aufbau in einen Bildspeicher für
> Display-Aufgaben und dergleichen.

Das sowieso.

> Aber schon bei den Timern und noch viel mehr bei den schieren GPIO's
> hört das komplett auf. Das, was dort stattfindet, ist eigentlich _immer_
> derart projektabhängig, daß es absolut kontraproduktiv wäre, dort deinen
> Gedanken in die Tat umzusetzen. Stattdessen braucht es Treiber, die das
> jeweilige Problem direkt in eine höhere Ebene umsetzen.
>
> Also mal ganz vulgär:
> nicht "SetzePin(Port,Nummer,Zustand);"
> sondern "SchalteMotorEin();"

...oder eben: "motor.einschalten();". Das läßt sich mit einfacher 
Vererbung ganz einfach, elegant und kostenlos umsetzen. Das bedarf nur 
einer simplen Elternklasse, die einen Pin abstrahiert -- und ist dann 
mit einer anderen Elternklasse, die dasselbe Interface auf einer anderen 
Controllerfamilie implementiert, sogar portabel.

[Nop (Gast)]

Sheeva P. schrieb:

> ...oder eben: "motor.einschalten();". Das läßt sich mit einfacher
> Vererbung ganz einfach, elegant und kostenlos umsetzen.

Es läßt sich auch ohne Vererbung einfach, elegant und kostenlos 
umsetzen. KISS und YAGNI gilt auch für Tools.

[Wilhelm M. (wimalopaan)]

Nop schrieb:
> Sheeva P. schrieb:
>
>> ...oder eben: "motor.einschalten();". Das läßt sich mit einfacher
>> Vererbung ganz einfach, elegant und kostenlos umsetzen.
>
> Es läßt sich auch ohne Vererbung einfach, elegant und kostenlos
> umsetzen. KISS und YAGNI gilt auch für Tools.

Was ist an Vererbung kompliziert?

Naja, es geht ja auch ohne: durch Komposition und generische Typen.

Ist aber wohl auch zu kompliziert ...

[Nop (Gast)]

Wilhelm M. schrieb:

> Was ist an Vererbung kompliziert?

Wieder ein Konzept mehr, das man nicht braucht, also weg damit. Zudem 
baut man sich dann nicht mit Diamant-Hierarchien in die Ecke. 
Hauptnachteil ist, daß man nicht stundenlang beim Käffchen über 
Scheinprobleme wie is-a vs. has-a debattieren kann.

> Naja, es geht ja auch ohne: durch Komposition und generische Typen.

Braucht man auch nicht, um einen Motor einzuschalten.

[avr (Gast)]

Peter Gerlich schrieb im Beitrag #5039861:
> avr schrieb:
>> lässt sich wunderbar abstrahieren
>
> ungleich
>
> Torsten R. schrieb:
>> kann man mit C++ ... machen, das ist aber viel Arbeit

Für dich gibt es auch nur schwarz und weiß? Mit C++ hat man ein 
mächtiges Werkzeug zur Abstraktion, vieles kann man sogar zur 
Compilezeit machen. Natürlich hängt der Arbeitsaufwand mit dem 
Abstraktionsgrad zusammen. Eine einfache Klasse, welche ein 
Peripheriebaustein eines speziellen Controllers abstrahiert ist deshalb 
nicht übermäßig schwer.

Wobei ich mich frage, wie man überhaupt auf diesen Zug kommen kann. 
Abstraktion ist ebenso in C möglich. Und auch dort kann man es 
übertreiben. Da wird es jedoch sehr viel schneller hässlich, wo es in 
C++ noch elegante Möglichkeiten gibt. Unter anderem auch, weil das sehr 
mächtige Templatesystem in C nicht vorhanden ist.

=> Ein Vorteil von C++ ist nicht die Abstraktion, sondern die 
Möglichkeit deutlich besser und eleganter abstrahieren zu können.

Und so lange hier keine widerspricht bleibe ich bei der Behauptung, dass 
die meisten C++-Kritiker hier mit der Sprache Probleme haben. Und zwar 
nicht mit der Syntax, sondern mit den Paradigmen. Denn die Argumente 
hier sind nur noch zu schwer, zu komplex, braucht man nicht oder 
irgendwelche Mythen der Overhead.

@Nop
Du bestätigst mich gerade. Wenn man OOP nicht kennt, dann kann man sie 
auch nicht brauchen. Wenn man sie als sinnvolles Paradigma akzeptiert, 
erkennt man auch einen Mehrwert in C++.

[A. S. (Gast)]

Sheeva P. schrieb:
> oder eben: "motor.einschalten();". Das läßt sich mit einfacher
> Vererbung ganz einfach, elegant und kostenlos umsetzen. Das bedarf nur
> einer simplen Elternklasse, die einen Pin abstrahiert -- und ist dann
> mit einer anderen Elternklasse, die dasselbe Interface auf einer anderen
> Controllerfamilie implementiert, sogar portabel.

Aber genau dass geht in C genauso gut. In C++ gibt es halt nur mehr 
(Austrucks-)Möglichkeiten, die im Zweifel auch performanter sind. Nur 
sind sie halt nicht immer so gut lesbar und jeder favorisiert einen 
anderen Ansatz.

[Wilhelm M. (wimalopaan)]

Nop schrieb:
> Wilhelm M. schrieb:
>

>
>> Naja, es geht ja auch ohne: durch Komposition und generische Typen.
>
> Braucht man auch nicht, um einen Motor einzuschalten.

Klar, geht ja auch mit dem Faustkeil (s.o.).

[Wilhelm M. (wimalopaan)]

Achim S. schrieb:
> Sheeva P. schrieb:
>> oder eben: "motor.einschalten();". Das läßt sich mit einfacher
>> Vererbung ganz einfach, elegant und kostenlos umsetzen. Das bedarf nur
>> einer simplen Elternklasse, die einen Pin abstrahiert -- und ist dann
>> mit einer anderen Elternklasse, die dasselbe Interface auf einer anderen
>> Controllerfamilie implementiert, sogar portabel.
>
> Aber genau dass geht in C genauso gut. In C++ gibt es halt nur mehr
> (Austrucks-)Möglichkeiten, die im Zweifel auch performanter sind.

Woher nimmst Du diese Behauptung???

[Nop (Gast)]

Ach ja, wo OOP wirklich Sinn ergibt, das ist, wenn man nicht 
eingebildete Pseudo-Objekte baut, nur um OOP zu machen, sondern wenn 
tatsächlich dynamisch Objekte erzeugt werden und verschwinden, die auch 
tatsächlich eigenes Benehmen haben.

Simulationen sind da wichtig (da kommt OOP ja her), und damit auch 
heutige Spiele, weil die einzelnen Elemente jedes für sich agieren und 
entstehen sowie verschwinden können. Und natürlich GUIs, wo das genauso 
ist.

Aber Motoren und ihre Pins sind, wo sie sind, und da bleiben sie auch. 
Motoren entstehen nicht dynamisch und verschwinden wieder. Gaspedale und 
Bremsen auch nicht.

[Wilhelm M. (wimalopaan)]

Nop schrieb:
> Ach ja, wo OOP wirklich Sinn ergibt, das ist, wenn man nicht
> eingebildete Pseudo-Objekte baut, nur um OOP zu machen, sondern wenn
> tatsächlich dynamisch Objekte erzeugt werden und verschwinden, die auch
> tatsächlich eigenes Benehmen haben.

Sag mal, liest Du überhaupt die Beiträge hier?
OOP im engeren Sinn ist zwar ein Möglichkeit, ich habe aber oben schon 
zigmal gesagt, dass andere Konzeote viel wichtiger sind. Mittlerweile 
denke, Du weißt gar nicht, was bestimmte Begriffe bedeuten ...

> Aber Motoren und ihre Pins sind, wo sie sind, und da bleiben sie auch.
> Motoren entstehen nicht dynamisch und verschwinden wieder. Gaspedale und
> Bremsen auch nicht.

Genau! Wie gesagt, OOP im engeren Sinn ist nicht das Einzige, was C++ 
beherrscht (s.o, x-te Iteration).

[avr (Gast)]

Nop schrieb:
> sondern wenn
> tatsächlich dynamisch Objekte erzeugt werden und verschwinden, die auch
> tatsächlich eigenes Benehmen haben.

OOP hat erst mal nichts mit dem Erzeugen von Objekten zu tun. Es kann 
auch alles statisch bleiben. Und daher kann man auch einen UART 
wunderbar in eine statische Klasse stecken. Wenn man möchte, kann diesem 
UART durch Vererbung beliebige Features hinzufügen (Puffer, Protokolle) 
und diese Klasse beliebig oft verwenden. Wenn einem das nicht passt, 
kann man auch in C++ ohne OO programmieren und freut sich z.B. über 
Templates, welche Berechnungen zur Compilezeit durchführen oder was auch 
immer.

[Wilhelm M. (wimalopaan)]

avr schrieb:
> Nop schrieb:
>> sondern wenn
>> tatsächlich dynamisch Objekte erzeugt werden und verschwinden, die auch
>> tatsächlich eigenes Benehmen haben.
>
> OOP hat erst mal nichts mit dem Erzeugen von Objekten zu tun. Es kann
> auch alles statisch bleiben. Und daher kann man auch einen UART
> wunderbar in eine statische Klasse stecken. Wenn man möchte, kann diesem
> UART durch Vererbung beliebige Features hinzufügen (Puffer, Protokolle)
> und diese Klasse beliebig oft verwenden. Wenn einem das nicht passt,
> kann man auch in C++ ohne OO programmieren und freut sich z.B. über
> Templates, welche Berechnungen zur Compilezeit durchführen oder was auch
> immer.

Auch das habe ich schon x-mal hier geschrieben, nur mich beschleicht das 
Gefühl, dass nicht verstanden wird, was z.B. constexpr-lambdas sind ...

[Nop (Gast)]

Wilhelm M. schrieb:

> Genau! Wie gesagt, OOP im engeren Sinn ist nicht das Einzige, was C++
> beherrscht (s.o, x-te Iteration).

Ja, die Modewellen macht C++ alle mit. Vererbung war der Hype in den 
90ern, heute werden dem C++11-beinigen Octopus auch noch funktionale 
Konzepte reingenagelt. Und der Scope wächst, wächst und wächst.

Ich ziehe es vor, wenn ich direkt Zeile für Zeile lesen kann, was genau 
der Code tut, besonders wenn er nicht von mir ist. Das ist bei C++ schon 
wegen der Fragmentierung problematisch.

Außer natürlich für die Profis des Forums, die die C++-Standards von 
1998 bis 2017 zu 100% beherrschen, STL und Boost ebenso, mitsamt den 
Nuancen für diverse FAST identische Wege, dasselbe zu erreichen, aber 
die stets den richtigen nehmen.

Die Realität: MISRA-C wurde geschaffen, weil sogar der C-Standard zu 
komplex ist. Und wieso hat man die Leute nicht einfach alle 
rausgeworfen, C-Programmierer sollte es doch erst recht geben? Weil das 
Domänenwissen das Entscheidende ist und nicht das Programmieren.

[Sheeva P. (sheevaplug)]

Nop schrieb:
> Sheeva P. schrieb:
>
>> ...oder eben: "motor.einschalten();". Das läßt sich mit einfacher
>> Vererbung ganz einfach, elegant und kostenlos umsetzen.
>
> Es läßt sich auch ohne Vererbung einfach, elegant und kostenlos
> umsetzen. KISS und YAGNI gilt auch für Tools.

Kostenlos, Kunststück, wenn C die Kostenreferenz ist, einfach auch, 
solange man nur diese einfache Instruktion betrachtet, aber... elegant? 
Es ist ganz sicher auch eine Frage des persönlichen Empfindens (und der 
Fähigkeiten und Kenntnisse) aber für mich sieht "SchalteMotorEin()" eher 
unelegant aus. Die unnatürlichen Bandwurmworte unterstützen den Lesefluß 
jedenfalls nicht.

Aber, weißt Du, ich glaube wir nähern uns dem Kern der Mißverständnisse 
zwischen uns beiden, den de facto ist die Vererbung extrem einfach, so 
man sie einmal verstanden hat. Daß Du sie als kompliziert ansiehst, läßt 
mich vermuten, daß das bei der -- warum auch immer -- nicht der Fall 
ist. Wenn meine Vermutung zutrifft, dann ist klar, warum wir immer an 
einander vorbei reden: weil ich C++ kenne und seine äußerst positiven 
Effekte in diversen Umgebungen ausnutze, während das bei Dir nicht der 
Fall ist und Du zuerst nur die Lernhürde siehst, die Du zuvor einmal 
überwinden müßtest, um die positiven Effekte kennenzulernen -- und weil 
Du mir nicht glauben willst, daß es diese positiven Effekte gibt und daß 
sie groß genug sind, um die nötige Lerninvestition sehr schnell zu 
amortisieren.

Was ich dann allerdings nicht verstehe, ist, warum Du nicht einfach bei 
Deiner Lieblingssprache bleibst und die C++-Freunde ihr Ding machen 
läßt, sondern explizit gegen C++ und damit gegen etwas argumentierst, 
das Du im Grunde genommen gar nicht beurteilen kannst (und willst). 
Darauf deutet jedenfalls auch hin, daß Du so gar keine eigenen 
Sachargumente in diese Diskussion eingebracht hast, sondern immer wieder 
auf andere verweist und Dich ansonsten auf die Behauptung zurückziehst, 
C++ sei (zu) kompliziert.

Naja, nichts für ungut, vielleicht liege ich ja auch flashc. Dann würden 
mich Deine sachlichen Argumente allerdings umso brennender 
interessieren.

[A. S. (Gast)]

Wilhelm M. schrieb:
> Aber genau dass geht in C genauso gut. In C++ gibt es halt nur mehr
>> (Austrucks-)Möglichkeiten, die im Zweifel auch performanter sind.
>
> Woher nimmst Du diese Behauptung???

welche meinst Du?

Dass die Abstrahierung von motor.einschalten() in C genauso gut geht? 
weil ich es so mache. Kann ich Dir gerne konkrete Beispiele liefern

Dass es mehr Ausdrucksmöglichkeiten in C++ gibt? Das ist doch gerade die 
Quintessenz der Diskussion hier.

Das es in C++ im Zweifel performanter ist? Weil die meisten 
Ausdrucksmöglichkeiten zur Compilezeit in nichts zerfallen. Im Video 
oben von Dan Saks über C++ zeigt er auch genau das. (Da. wo inline in 
beiden Sprachen das Optimum ist).

[Wilhelm M. (wimalopaan)]

Nop schrieb:
> Wilhelm M. schrieb:
>
>> Genau! Wie gesagt, OOP im engeren Sinn ist nicht das Einzige, was C++
>> beherrscht (s.o, x-te Iteration).
>
> Ja, die Modewellen macht C++ alle mit. Vererbung war der Hype in den
> 90ern, heute werden dem C++11-beinigen Octopus auch noch funktionale
> Konzepte reingenagelt. Und der Scope wächst, wächst und wächst.

Wir haben 2017 und OOP gibt es immer noch: 27 Jahre nach Deiner Rechnung 
(eigentlich schon viel älter) - ist das noch ein Hype oder hat das seine 
Gründe. Aber: OOP im engeren Sinn (etwas anderes scheinst Du nicht zu 
kennen) ist nicht das Mittel der Wahl für µC (aus ganz verschiedenen 
Gründen).

> Ich ziehe es vor, wenn ich direkt Zeile für Zeile lesen kann, was genau
> der Code tut, besonders wenn er nicht von mir ist.

Ok, das spricht eigentlich für Assembler, oder?

> Das ist bei C++ schon
> wegen der Fragmentierung problematisch.

Was bezeichnest Du als Fragmentierung?

[Sheeva P. (sheevaplug)]

Nop schrieb:
> Wilhelm M. schrieb:
>
>> Was ist an Vererbung kompliziert?
>
> Wieder ein Konzept mehr, das man nicht braucht, also weg damit.

Du hast Recht: man braucht das Konzept nicht, genauso, wie man keine 
Spül- und keine Wachmaschine braucht. Diese Dinge machen das Leben zwar 
in vielen Bereichen wesentlich einfacher und müheloser, aber Du kannst 
natürlich gern auf diese Annehmlichkeiten verzichten. Warum Du dann 
allerdings andere dazu bringen willst, ebenfalls zu verzichten, bleibt 
wohl Dein Geheimnis.

> Zudem baut man sich dann nicht mit Diamant-Hierarchien in die Ecke.
> Hauptnachteil ist, daß man nicht stundenlang beim Käffchen über
> Scheinprobleme wie is-a vs. has-a debattieren kann.

Schon wieder diese konstruierten Probleme -- beides ist mir in > 20 
Jahren objektorientierter Softwareentwicklung noch nie passiert.

[Wilhelm M. (wimalopaan)]

Achim S. schrieb:
> Wilhelm M. schrieb:
>> Aber genau dass geht in C genauso gut. In C++ gibt es halt nur mehr
>>> (Austrucks-)Möglichkeiten, die im Zweifel auch performanter sind.
>>
>> Woher nimmst Du diese Behauptung???
>
> welche meinst Du?

Ups, hatte Dich so verstanden, das Du C im Vorteil siehst. Mein Fehler 
...

[Nop (Gast)]

Sheeva P. schrieb:

> Kostenlos, Kunststück, wenn C die Kostenreferenz ist, einfach auch,
> solange man nur diese einfache Instruktion betrachtet, aber... elegant?

Geschmackssache, wie Du schon sagst. Ich finde es elegant, wenn die 
Anforderungen möglichst einfach umgesetzt werden, und die Forderung 
lautet normalerweise bloß, daß bei dem und dem Ereignis der Pin sowieso 
innerhalb einer bestimmten Zeit gesetzt werden muß.

Wenn man zusätzlich zu dem Pinsetzen noch haufenweise Abstraktionen 
draufsetzt, hat das für mich keinen Mehrwert. KISS und YAGNI.

> Die unnatürlichen Bandwurmworte unterstützen den Lesefluß
> jedenfalls nicht.

Man kann auch Unterstriche reinmachen, das ist kein wesentlicher 
optischer (!) Unterschied zu einem Punkt.

> Daß Du sie als kompliziert ansiehst, läßt
> mich vermuten, daß das bei der -- warum auch immer -- nicht der Fall
> ist.

Ich habe das oben schon erklärt. Das ständige Beharren von 
C++-Programmierern, daß Leute, die unter "einfach" etwas anderes 
verstehen, eben blöd sein müssen, macht diese Sichtweise nicht wahrer.

Ich verstehe unter "einfach" nicht, daß man am Ende zwei Zeilen Code 
schreibt, hinter denen Tonnen an compiler magic stehen. Ich finde das im 
Gegenteil umständlich, weil das Hinschreiben zwar leicht ist, aber das 
Nachvollziehen, was exakt an Binärcode rausfällt, ist umso schwieriger.

Das wird in C++-Kreisen übrigens gerne als "C hacker syndrome" 
diskreditiert.

(Ach ja, und wieso ich nicht gleich Assembler nehme: weil man den Code 
nicht portieren kann, und weil es nervig wird, wenn man mehrere 
Architekturen gleichzeitig bearbeitet.)

> Was ich dann allerdings nicht verstehe, ist, warum Du nicht einfach bei
> Deiner Lieblingssprache bleibst und die C++-Freunde ihr Ding machen
> läßt

Auf gut deutsch: "halt einfach die Klappe". Ja, so kann man natürlich in 
Threads versuchen, Leuten einzureden, C++ sei mehr oder weniger 
alternativlos heutzutage.

Du wirst damit klarkommen müssen, daß Leute in entsprechenden Threads 
sagen, daß 90% dessen, worauf Du stehst, in ihren Augen überflüssig ist, 
weil nicht notwendig zum Lösen typischer embedded-Aufgaben.

> C++ sei (zu) kompliziert.

Das ist es auch, und mit der Meinung stehe ich auch beileibe nicht 
alleine.

Selbstverständlich gehst Du auch beharrlich nicht darauf ein, daß in 
einer Branche, wo MISRA-C nötig ist, weil schon C zu komplex ist, C++ 
der reine Wahnsinn wäre.

[Wilhelm M. (wimalopaan)]

Da hatte doch gerade jemand gefragt, wozu man diesen Unsinn wie 
constexpr-lambdas braucht ... eigentlich eine gute Frage, für jemanden, 
der offensichtlich nur den Präprozessor kennt. Leider ist der Beitrag 
jetzt weg, und ich weiß nicht mehr genau, was gefragt wurde ...

[Nop (Gast)]

Wilhelm M. schrieb:

> Ok, das spricht eigentlich für Assembler, oder?

Nein, siehe Posting vor diesem.

> Was bezeichnest Du als Fragmentierung?

Daß außerhalb dieses Forums die meisten C++-Programmierer nicht die 
Standards von 1998 bis 2017 alle zu 100% kennen mitsamt allen Feinheiten 
von STL und Boost. Siehe der Kommentar von Thompson.

In der Realität zerfällt das in Dialekte, wegen Subsetting, die aber 
zueinander inkompatibel sind. Das ist dann toll, wenn Du neue Leute in 
die Firma kriegst, die einen anderen Dialekt sprechen. Die verstehen 
zunächst einmal nichtmal den Code auf sprachlicher Ebene, geschweige 
denn auf inhaltlicher. Längere Einarbeitung heißt höhere Kosten.

Noch viel besser wird das, wenn eine Firma von einer anderen aufgekauft 
wird, da kommt dann Freude auf.

[Vincent H. (vinci)]

@Wilhelm M. &  Sheeva Plug

You argue, you lose.

[Oliver J. (skriptkiddy)]

@Nop:
Hast du denn schon mal ernsthaft mit C++ gearbeitet?

[Wilhelm M. (wimalopaan)]

Vincent H. schrieb:
> @Wilhelm M. &  Sheeva Plug
>
> You argue, you lose.

... loose. Macht nix, ich bin ein guter Verlierer ;-)

[Johannes S. (Gast)]

Oliver J. schrieb:
> @Nop:
> Hast du denn schon mal ernsthaft mit C++ gearbeitet?

Das war doch wohl eine rhetorische Frage, bei den praxisfernen 
Argumenten und Beispielen die von ihm kommen.

[Oliver J. (skriptkiddy)]

@nop:
Hast du schon mal ernsthaft mit C++ gearbeitet?

Johannes S. schrieb:
> Oliver J. schrieb:
>> @Nop:
>> Hast du denn schon mal ernsthaft mit C++ gearbeitet?
>
> Das war doch wohl eine rhetorische Frage, bei den praxisfernen
> Argumenten und Beispielen die von ihm kommen.

Ich wollte nur auf Nummer-Sicher gehen ;-)

[Nop (Gast)]

Ach ja, und vermissen tue ich in C ganz andere Sachen:

- das inline-Keyword ist völlig nutzlos, weil es ein unverbindlicher 
Vorschlag an den Compiler ist. Um wirklich inline zu kriegen, muß man 
mit proprietären Erweiterungs-Hacks arbeiten.

- das Gegenteil, ein Verbot des Inlinens für eine spezifische Funktion, 
gibt es nur mit Erweiterungshacks.

- Auch das Markieren einer Funktion als Interruptroutine oder als "used" 
gibt's nicht standardmäßig.

- computed goto ebenfalls nicht.

- die ursprünglichen Standardfunktionen wie strcpy, scanf & Co sind 
schlampige Hacks und auch bei korrekter Verwendung ein 
Sicherheitsrisiko. Immerhin gibt's da neue.

- es gibt keine portable Methode, wie man auf PC-Systemen feststellen 
kann, ob eine Taste gedrückt wurde, ohne sie auszulesen, also sowas wie 
kbhit().

- die Operatorreihenfolge ist z.T. sehr ungeschickt, beispielsweise mit 
== und binären Logik-Operatoren, welche sich da völlig anders als die 
logisch gesehen ähnlichen arithmetischen verhalten.

[Nop (Gast)]

Oliver J. schrieb:
> @Nop:
> Hast du denn schon mal ernsthaft mit C++ gearbeitet?

Hat sich für kleinere Geschichten auf minimalstes C mit Klassen 
begrenzt, und das fand ich schon daneben. Ist zum Glück auch schon ne 
ganze Weile her.

Ansonsten reicht es mir, wenn ich alle paar Jahre wieder lese, was für 
abgefahrene Sachen jetzt schon wieder eingebaut werden, schon verstärkt 
sich meine Abneigung.

Less is more, und etwas ist nicht perfekt, wenn man nichts mehr 
hinzufügen kann, sondern wenn man nichts mehr wegnehmen kann, ohne daß 
es zerbricht. Das ist aber so ziemlich das Gegenteil von C++.

[Oliver J. (skriptkiddy)]

Hier herrscht ja ein brutal rauer Ton. Ich fände es besser wenn wir 
wieder zurückkehren könnten zu einer sachlichen Diskussion.

[Wilhelm M. (wimalopaan)]

Nop schrieb:
> Ach ja, und vermissen tue ich in C ganz andere Sachen:
>
> - das inline-Keyword ist völlig nutzlos, weil es ein unverbindlicher
> Vorschlag an den Compiler ist. Um wirklich inline zu kriegen, muß man
> mit proprietären Erweiterungs-Hacks arbeiten.

Naja, der Sinn des inline-Keywords ist ja entgegen seinem Namen auch ein 
anderer  - auch in C!

[Nop (Gast)]

Wilhelm M. schrieb:

> Naja, der Sinn des inline-Keywords ist ja entgegen seinem Namen auch ein
> anderer

Das beschreibt das Problem ganz gut, und sowas ist einfach vom Grundsatz 
her schon daneben.

[Vincent H. (vinci)]

Wir befinden uns im Jahr 35 nach C. Die ganze Welt hat erkannt, dass 
eine gute Programmiersprache prozeduale, funktionale und 
objektorientierte Ansätze unterstützen sollte. Die ganze Welt? Nein, ein 
von unbeugsamen C Jüngern bevölkertes Dorf hört nicht auf dem 
Eindringling Widerstand zu leisten!

[Sheeva P. (sheevaplug)]

Nop schrieb:
> Wilhelm M. schrieb:
>
>> Genau! Wie gesagt, OOP im engeren Sinn ist nicht das Einzige, was C++
>> beherrscht (s.o, x-te Iteration).
>
> Ja, die Modewellen macht C++ alle mit. Vererbung war der Hype in den
> 90ern, heute werden dem C++11-beinigen Octopus auch noch funktionale
> Konzepte reingenagelt.

Die gab es schon in C, in C++ wurden sie lediglich noch einmal ein wenig 
vereinfacht und verfeinert.

> Ich ziehe es vor, wenn ich direkt Zeile für Zeile lesen kann, was genau
> der Code tut, besonders wenn er nicht von mir ist.

Das kann ich auch bei C++-Code.

> Das ist bei C++ schon wegen der Fragmentierung problematisch.

Wenn man nicht aufpaßt, ist die bei C wesentlich größer als bei C++.

[Sheeva P. (sheevaplug)]

Achim S. schrieb:
> Dass die Abstrahierung von motor.einschalten() in C genauso gut geht?
> weil ich es so mache. Kann ich Dir gerne konkrete Beispiele liefern

Du baust Dir ein Struct mit einem Funktionszeiger?

[Nop (Gast)]

Sheeva P. schrieb:

> Wenn man nicht aufpaßt, ist die bei C wesentlich größer als bei C++.

Nein, denn die Sprache ist klein genug. Zudem gibt's obendrein, um das 
noch kleiner zu machen, ja auch noch MISRA-C. Ein Problem kann man 
natürlich anderweitig haben, wie in jeder Programmiersprache, wenn man 
sich Spaghetti baut. Das ist dann aber keine Fragmentierung bereits auf 
sprachlicher Ebene.

C garantiert einem schließlich nicht, daß man sein Programm sinnvoll 
aufbaut. Das tut C++ aber auch nicht. Das tut überhaupt keine Sprache. 
Allenfalls garantiert einem Brainf*ck umgedreht, daß man es nicht 
sinnvoll aufbauen KANN. ;-)

[ereader (Gast)]

Ach du Schande das Thema wird ja immer noch diskutiert :)

[Sprachenlerner (Gast)]

Hmmm..., wenn man immer die "ideale" Sprache nutzen will, dann kann man 
wohl für jedes wechselnde Projekt auch immer die Programmiersprache 
wechseln um ein Quäntchen an Perfomance, Leistungsfähigkeit, Funktionen, 
Ressourcenverbrauch, etc... zu gewinnen. Ob es sinnvoll ist, alle 
x-Sprachen zu kennen, das halte ich eventuell übertrieben und finde es 
besser wenn man 1-2-3 Sprachen beherrscht, da aber umso besser. Oder?

Für kleine Programme (z.B. auf einem STM32) habe ich schon C genommen.

Ich frage mich, ob und für welchen Zweck C++ oder C# für einen STM32 
besser wäre?
(Ich frage nicht um C++ oder C# schlecht zu machen, sondern weil ich 
mich nicht damit auskenne).

Gern möchte ich lernen/können einen STM32 mit Touch-Display zu 
programmieren (z.B. für eine Haussteuerung). Welche Sprache ist da 
empfehlenswert?
Ebenso einen Raspberry mit Touch-Display und kleiner Visualisierung oder 
größeren Aufgaben (Linux/Windows Betriebssystem?). Was nimmt man da für 
eine Sprache?
Wie sieht es auf Windows-PC aus, welche ist da die geeigneteste Sprache 
um grfische Oberflächen zu programmieren?

Nun es ist nicht leicht, eventuell werden mir nun 10 Sprachen empfhlen, 
aber so viele möchte ich nicht lernen. 2 oder max. 3 Sprachen, mehr 
nicht, damit sollte sich alles unter einen Hut bringen lassen.

[Torsten R. (Firma: Torrox.de) (torstenrobitzki)]

W.S. schrieb:
> Torsten R. schrieb:
>> Naja, wenn ich auf jeder Plattform schon mal das gleiche Interface zu
>> GPIOs und Timern hätte, wäre doch schon viel gewonnen.
>
> Ach wo.
>
> Gleiche Interfaces sind genau dort von Vorteil, wo man es mit immer
> wieder gleichartigen Datenströmen zu tun hat, also serielle Interfaces
> aller Art, SDIO, Grafik-Aufbau in einen Bildspeicher für
> Display-Aufgaben und dergleichen.

Ja, da bin ich doch total bei Dir. Das habe ich doch sogar im nächsten 
Satz geschrieben:

> Ich denke, soetwas kann sehr gut funktionieren, wenn ich meine
Bedürfnisse an die Hardware möglichst konkret definieren kann.

Mein Beispiel war eine PWM. Dein Beispiel ist ein Motor.

Wenn ich eine effektive Abstraktion von der Hardware haben möchte, dann 
kann ich bei der Abstraktion der Hardware halt nicht bei Timer und GPIO 
aufhören und mir eine Library bauen, die auf der GPIO und Timer 
Abstraktion aufbauend eine PWM implementiert, weil es Controller gibt, 
die eine PWM in Hardware implementieren.

Aber: Die trotzdem wäre für mich eine Abstraktion von so häufig 
genutzten Peripherals wie GPIO und Timer schon ein Fortschritt, weil ein 
GPIO-Pin halt häufig direkt auf diesem niedrigen Level genutzt wird: 
Lampe An, Lampe Aus.

> Stattdessen braucht es Treiber, die das
> jeweilige Problem direkt in eine höhere Ebene umsetzen.

Genau! Ich möchte angeben können, dass ich eine UART benutzen möchte, 
dass die an folgende Pins angeschlossen ist, das die Konfiguration 
9600,8N1 ist, etc.. (Mir völlig egal, ob der Controller eine UART hat, 
oder die Library das mit Bitbanging machen muss. Ich möchte nicht 
stundenlang debuggen, um raus zu finden, dass irgend ein Clock-Enable 
Bit gesetzt werden muss usw.)

Ich möchte einen GATT Server mit folgenden Satz an Funktionen, die 
aufgerufen werden, wenn ein Client auf die Characteristiken zugreift. 
(Ich möchte nicht 250 Zeilen C-Code schreiben müssen, um damit den 
Inhalt einer im RAM liegenden Tabelle zu füllen, die nach der 
Initialisierung und wärend der ganzen Laufzeit konstant bleibt [soetwas 
gehört ins ROM]).

> Kurzum, der Versuch, auf niedrigster Ebene zu vereinheitlichen, ist
> unproduktiv. Sowas muß man auf einer angemessenen höheren Ebene machen.

Jein. Abstraktion auf unterster Ebene macht Sinn, wenn es Anwendungen 
auf der Ebene gibt (Lämpchen an, Lämpchen aus).

Ansonsten bin ich ganz bei Dir und meine mit C++ das passende Werkzeug 
dafür gefunden zu haben (Beispiel: 
https://github.com/TorstenRobitzki/bluetoe).

[Oliver J. (skriptkiddy)]

Ich für meinen Teil finde es jetzt nicht wirlich viel schwieriger mich 
in C++-Code einzuarbeiten. Es ist erfahrungsgemäß bei gleicher 
Codequalität ähnlich schwer, wenn man die Sprache und eventuell 
verwendete Pattern kennt. Da gilt denke ich für jede Sprache. Das lässt 
sich glaube ich auch gut auf die menschliche Sprache anwenden: Wenn man 
eine Fremdsprache nicht so gut beherrscht wie seine Muttersprache, dann 
tut man sich da natürlich schwerer ;).

Wenn also jemend C++ beherrscht, kann er es denke ich auch hernehmen. 
Besonders, wenn man eine objektorientierte Lösung designt hat. Das in C 
umzusetzen ist nicht schön. Haben wir beruflich mal für ein 
Kommunikationsframework (> 2 Mannjahre) gemacht, da ein konsumierendes 
Projekt in C war.

Bei uns im Team hat ganz ehrlich niemand Lust die Problemlösungen in C 
abzubilden. Das liegt aber wahrscheinlich auch daran, dass wir 
mittlerweile architekturgetrieben die Software hochziehen.

[Nop (Gast)]

Sprachenlerner schrieb:

> Gern möchte ich lernen/können einen STM32 mit Touch-Display zu
> programmieren

GUI und C ist ein ziemlicher Horror, also jedenfalls C ist für den Zweck 
draußen.

[Oliver J. (skriptkiddy)]

Sprachenlerner schrieb:
> Wie sieht es auf Windows-PC aus, welche ist da die geeigneteste Sprache
> um grfische Oberflächen zu programmieren?
Da ist C# mit WPF oder WinForms denke ich durchaus einen Blick wert.
C++ mit qt könnte man eventuell auch in Betracht ziehen.

Grüße Oliver

[Nop (Gast)]

Torsten R. schrieb:

> (Ich möchte nicht 250 Zeilen C-Code schreiben müssen, um damit den
> Inhalt einer im RAM liegenden Tabelle zu füllen, die nach der
> Initialisierung und wärend der ganzen Laufzeit konstant bleibt [soetwas
> gehört ins ROM]).

Ich hab in so einem Fall diesen Prozeß beim Build auf dem Host gemacht 
und dann mit xxd ein C-File erzeugt, was ich einfach ins Projekt 
reincompiliert habe. Dadrin ist dann ein Array mit den nötigen 
Binärdaten, das man ins ROM verfrachten kann.

[Gerhard O. (gerhard_)]

Also, ehrlich!

Eure Diskussion in Ehren. Trotzdem würde ich es aber toll finden wenn 
wir alle vielleicht diese Diskussion in den Rahmen eines Workshops 
hinbiegen könnten. Damit ließe sich viel Positives erreichen. Z.B. wurde 
einige Beiträge zurück bemerkt wie grottig die Arduino Bibliotheken zum 
Teil wären. Könnte man nicht ein paar Beispiele von guten und 
schlechteren Ansätzen aussuchen und dann hier durch gehen wie man es 
eben besser machen könnte? Die meisten kennen sich ja mit AVR aus und 
wäre wegen der relativen Leistungsschwachheit eine gute Platform 
effiziente Codebeispiele zu testen. Viele würden das bestimmt sehr 
lehrreich finden.

Was wirklich gut wäre, kollektiv ein kleines Handbuch zu erstellen über 
die Do's und Don't's von C++ auf kleineren uC und GCC mit Beispielen als 
gemeinsame Platform die allen zugänglich ist.

Ich bin der Meinung, daß praktischer Einsatz von C++ weit lehrreicher 
für viele nicht-professionelle Programmierer wäre anstatt sich durch zum 
Teil schwer verständliche C++ Literatur und Handbücher durchquälen zu 
müssen. Erst durch Probieren verschiedenster Ansätze gewinnt man ein 
intuitives Gefühl dafür was empfehlenswert ist und was nicht. Nicht alle 
haben Informatik studiert und viele Fachliteratur ist für 
Nicht-Informatiker nur schwer in allen Konsequenzen und Feinheiten 
verständlich

Gerade hier im Forum könnte man diesbezüglich (trotz viel Zweifels) viel 
erreichen.

Zerreisst mich jetzt aber nicht gleich in der Luft, bitte;-)

Schönen Abend noch,
Gerhard

[ereader (Gast)]

Meiner Meinung nach kann man C++ ruhig bis zu den Klassen hin nutzen, 
man kann schön alle Funktionen und Variablen in einer Klasse 
unterbringen, das geht in C nicht mehr so komfortabel. Wenn man also C++ 
bis zu den Klassen hin anwendet ohne Vererbung und Mehrfachverrbung und 
was es sonst noch alles gibt, dann ist C++ vom Sprachumfang her nicht 
größer als C, so sehe ich das zumindest.
Im Grunde genommen spielt es bei kleinen Hobbyprojekten keine Rolle ob C 
oder C++, diese Sprachen sind erst im industriellen Einsatz interessant, 
weil dort kein wildes Sammelsurium sondern eine Einheitlichkeit 
vorhanden sein muss. Man kann also um schnelle Erfolge zu erzielen auch 
ruhig Arduino nehmen, man muss es sich nicht unnötig schwer machen, 
wobei C oder C++ (bis zur genannten Grenze) wirklich nicht kompliziert 
sind, man muss sich nur die Zeit nehmen es zu lernen.

[Carl D. (jcw2)]

Ich freu mich schon auf den nächsten Thread, in dem jemand versucht mit 
dem C-Preprozessor zu rechnen. Dabei gibt es in C++ constexpr, das ab 
C++14 im fast normalen Sprachumfang die Programmierung zur Compilezeit 
erledigt.
Und dann wird versucht

#define PORT   D
#if PORT==D
#elif PORT==A
#endif

ohne zu ahnen, wie minimal der Funktionsumfang dieser Sprache ist.
Und dabei gäbe es "conditional compiling" via "constexpr if", wenn man 
es wissen wollte. Hauptsache scheiß OOP.

[Sheeva P. (sheevaplug)]

Nop schrieb:
> Sheeva P. schrieb:
>> Kostenlos, Kunststück, wenn C die Kostenreferenz ist, einfach auch,
>> solange man nur diese einfache Instruktion betrachtet, aber... elegant?
>
> Geschmackssache, wie Du schon sagst. Ich finde es elegant, wenn die
> Anforderungen möglichst einfach umgesetzt werden, und die Forderung
> lautet normalerweise bloß, daß bei dem und dem Ereignis der Pin sowieso
> innerhalb einer bestimmten Zeit gesetzt werden muß.

Ja, wenn man nur das Ereignis und das Pinwackeln betrachtet. Aber wenn 
man auch Lesbarkeit, Wartbarkeit und Kompaktheit des Codes in die 
Betrachtung einbezieht, dann, ganz eindeutig: nein. Denn die 
Anforderungen lassen sich mit C++ ganz genauso einfach umsetzen, dafür 
aber viel kompakter und daher mit einer höheren Les- und Wartbarkeit 
sowie einer besseren Unterstützung durch die gängigen 
Programmerwerkzeuge.

> Wenn man zusätzlich zu dem Pinsetzen noch haufenweise Abstraktionen
> draufsetzt, hat das für mich keinen Mehrwert. KISS und YAGNI.

Fällt Dir was auf? Mir schon: der Einzige, der hier von "haufenweiser 
Abstraktion" redet, bist Du. Entschuldige, aber Du scheinst seltsame 
Vorstellungen von C++ auf uCs zu haben. Da gibt es meist zu wenig zu 
abstrahieren, als das von "haufenweise" die Rede sein könnte. So ein 
GPIO-Pin ist ein GPIO-Pin, und die Anzahl von Operationen, die damit 
ausgeführt werden können, ist prinzipbedingt recht eng begrenzt. Was 
stellst Du Dir unter einer "haufenweisen Abstraktion" denn vor?

> Man kann auch Unterstriche reinmachen, das ist kein wesentlicher
> optischer (!) Unterschied zu einem Punkt.

Ja, und dazu darf man dann x-mal denselben Boilerplate schreiben.

>> Daß Du sie als kompliziert ansiehst, läßt
>> mich vermuten, daß das bei der -- warum auch immer -- nicht der Fall
>> ist.
>
> Ich habe das oben schon erklärt. Das ständige Beharren von
> C++-Programmierern, daß Leute, die unter "einfach" etwas anderes
> verstehen, eben blöd sein müssen, macht diese Sichtweise nicht wahrer.

Du verwechselst Blödheit mit Unkenntnis. Es ist ja gar nicht schlimm, 
C++ nicht zu kennen und nicht kennenlernen zu wollen. Aber es nicht zu 
kennen und nicht kennenlernen zu wollen, sondern stattdessen Unsinn 
darüber zu reden, das erschließt sich mir einfach nicht.

> Ich verstehe unter "einfach" nicht, daß man am Ende zwei Zeilen Code
> schreibt, hinter denen Tonnen an compiler magic stehen.

Sieh an, da sind wir sogar einig. Aber ich verstehe unter einfach auch, 
daß sich das, was der Code tut, nicht hinter Tonnen winziger, breit über 
meinen Quellcode verstreuter Fragmente verteilt, der sich nur mit 
weiteren Tonnen von Kommentaren verstehen und zueinander in Bezug setzen 
läßt.

> Ich finde das im
> Gegenteil umständlich, weil das Hinschreiben zwar leicht ist, aber das
> Nachvollziehen, was exakt an Binärcode rausfällt, ist umso schwieriger.

Ab einer gewissen Komplexität kannst Du das auch in C vergessen, weil 
dann der Optimizer des Compilers zuschlägt. Genau das macht er übrigens 
auch mit den meisten syntaktischen Helferlein von C++, die das Leben um 
so Vieles einfacher und komfortabler machen können.

> Selbstverständlich gehst Du auch beharrlich nicht darauf ein, daß in
> einer Branche, wo MISRA-C nötig ist, weil schon C zu komplex ist, C++
> der reine Wahnsinn wäre.

Während Du mindestens ebenso beharrlich ignorierst, daß die Existenz von 
Misra-C++ beweist, daß offensichtlich ein Bedarf dafür besteht. 
Abgesehen davon sehe ich jedoch keine Notwendigkeit, der Aussage zu 
widersprechen. Schließlich sage ich selbst, daß C komplexer ist, als 
seine Befürworter behaupten,  und (nicht nur für Anfänger) einige böse 
Klippen bereithält. Darüber hinaus sage ich aber auch, daß C++ eine 
große Hilfe dabei sein kann, viele dieser Klippen sicher zu umschiffen.

Um uns die nächsten beiden Schritte zu ersparen, greife ich kurz vor: Du 
wirst jetzt korrekterweise behaupten, daß man Komplexität nicht durch 
das Hinzufügen von noch mehr Komplexität beherrschen kann, woraufhin ich 
Dir antworte, daß C++ keineswegs komplexer, sondern nur anders ist. ;-)

[Jörg W. (dl8dtl) (Moderator)]

Carl D. schrieb:
> ohne zu ahnen, wie minimal der Funktionsumfang dieser Sprache ist.

Sorry, das hat relativ wenig damit zu tun.  In diesem Falle waren
die Buchstaben nämlich wirklich reiner Präprozessorsalat, weil
daraus dann eigentlich Namen wie PORTA oder PIND gebaut werden
sollten.  Die "A" und "D" haben dabei selbst aber keinerlei eigenen
Wert, den man hätte überhaupt irgendwie testen können – da hilft dir
auch dein constexpr nichts.

Das Ganze ist der in dieser Hinsicht letztlich doch etwas verkorksten
AVR-Architektur geschuldet, bei der man nicht sowas wie PORTA->DIR
oder PORTA.DIR schreiben kann, sondern eben einen eigenen Namen DDRA
stattdessen benutzen muss.  Einen solchen Namen zurecht zu zimmern,
das kann wirklich nur der Präprozessor (und auch der schon eher mit
Tricks).

[Sheeva P. (sheevaplug)]

Vincent H. schrieb:
> You argue, you lose.

No need to argue. ;-)

[Sheeva P. (sheevaplug)]

Wilhelm M. schrieb:
> Vincent H. schrieb:
>> @Wilhelm M. &  Sheeva Plug
>>
>> You argue, you lose.
>
> ... loose. Macht nix, ich bin ein guter Verlierer ;-)

Nee, "to lose" wäre schon richtig. Aber wir streiten ja nicht, oder?

[Sheeva P. (sheevaplug)]

Nop schrieb:
> Nein, denn die Sprache ist klein genug.

Ja, und C++ auch.

> Zudem gibt's obendrein, um das noch kleiner zu machen, ja auch noch
> MISRA-C.

... und Misra-C++. ;-)

> Ein Problem kann man
> natürlich anderweitig haben, wie in jeder Programmiersprache, wenn man
> sich Spaghetti baut. Das ist dann aber keine Fragmentierung bereits auf
> sprachlicher Ebene.

Auf die Gefahr hin, mich zu wiederholen: schlechten Code kann man in 
jeder Sprache schreiben.

> C garantiert einem schließlich nicht, daß man sein Programm sinnvoll
> aufbaut. Das tut C++ aber auch nicht. Das tut überhaupt keine Sprache.
> Allenfalls garantiert einem Brainf*ck umgedreht, daß man es nicht
> sinnvoll aufbauen KANN. ;-)

Das ist allerdings richtig. Allerdings ist die Wahrscheinlichkeit, daß 
ein fehler- und warnungsfrei übersetztes C++-Programm tut, was es soll, 
größer als bei einem fehler- und warnungsfrei übersetzten C-Programm.

[Torsten R. (Firma: Torrox.de) (torstenrobitzki)]

Nop schrieb:
> Daß außerhalb dieses Forums die meisten C++-Programmierer nicht die
> Standards von 1998 bis 2017 alle zu 100% kennen mitsamt allen Feinheiten
> von STL und Boost. Siehe der Kommentar von Thompson.

Das ist eigentlich überhaupt kein Problem, wenn man das Hauptberuflich 
macht. Die Standards flattern jetzt auch nicht jährlich ins Haus und die 
Änderungen nach C++11 sind auch recht überschaubar. Die Standards sind 
auch weitgehend rückwärtkompatibel, man kann also sehr gut inkrementel 
vorgehen. Man muss auch nicht alles wissen und wenn man über etwas 
stolpert, dass man noch nicht kennt, dann schlägt man es kurz nach und 
hat wieder was gelernt.

Wenn jemand nur ab und zu mal etwas Code für seine Hardware schreiben 
muss und in Regel eher HW-Entwickelt und sich auch noch perfekt mit VHDL 
auskennen muss, ja der hat halt andere Werkzeuge um die er sich kümmern 
muss und nimmt dann verständlicher Weise eine einfachere (kleinere) 
Sprache oder überläßt es Anderen.

> In der Realität zerfällt das in Dialekte, wegen Subsetting, die aber
> zueinander inkompatibel sind.

Das würde ich nicht so sehen. Leute, die am gleichen Projekt arbeiten 
(sollten) auch den selben Compiler verwenden und damit wären Subsets der 
Sprach per se kompatibel zueinander, da es immer Schnittmengen gibt. Ich 
würde das eher persönlichen Stil nennen.

Die Zeiten, in denen es mehr Bücher über richtiges C++ als konforme C++ 
Compiler gab, sind aber lange vorbei (das war so Ende der 90er).

> Das ist dann toll, wenn Du neue Leute in
> die Firma kriegst, die einen anderen Dialekt sprechen. Die verstehen
> zunächst einmal nichtmal den Code auf sprachlicher Ebene, geschweige
> denn auf inhaltlicher. Längere Einarbeitung heißt höhere Kosten.

Das hast Du Dir doch jetzt ausgedacht! ;-) Als freelancer sehe ich ja 
das eine oder andere. Was Code unlesbar macht, sind flasche Namen, 
flasche Abstraktionen, Redundanz etc. schlechtes Handwerk, aber nur 
selten die Verwendung eines bestimmten Subsets (Dialekte gibt es von C++ 
eigentlich nicht) von Sprachkonstrukten.

Wenn Du einen eher progressiven Kollegen hast, der C99 verwendet und 
ausgibig Gebrauch von `const`, `restricted`, designated initializers, 
etc. macht, dann wird der etwas konservativere C89 Kollege doch kein 
Problem deswegen haben, den Code zu verstehen. Wenn der das 
entsprechende Konstrukt nicht kennt, dann kennt er es danach und weiter 
gehts...

> Noch viel besser wird das, wenn eine Firma von einer anderen aufgekauft
> wird, da kommt dann Freude auf.

Ach, dass hast Du Dir doch auch wieder ausgedacht! ;-) Oder wie viele 
Übernahmen einer C++ Bude durch eine andere C++ Bude hast Du schon 
mitgemacht?

mfg Torsten

[Torsten R. (Firma: Torrox.de) (torstenrobitzki)]

Nop schrieb:
> Torsten R. schrieb:
>
>> (Ich möchte nicht 250 Zeilen C-Code schreiben müssen, um damit den
>> Inhalt einer im RAM liegenden Tabelle zu füllen, die nach der
>> Initialisierung und wärend der ganzen Laufzeit konstant bleibt [soetwas
>> gehört ins ROM]).
>
> Ich hab in so einem Fall diesen Prozeß beim Build auf dem Host gemacht
> und dann mit xxd ein C-File erzeugt, was ich einfach ins Projekt
> reincompiliert habe. Dadrin ist dann ein Array mit den nötigen
> Binärdaten, das man ins ROM verfrachten kann.

Ja, in C wäre der richtige Ansatz, eine domain specific language zu 
definieren und ein Tool zu schreiben, dass aus dieser DSL dann wieder 
C-Code erzeugt. Deswegen sind Tools wie Lex und Yacc ja auch so beliebt.

Kann man aber auch in C++ ohne externe Tools machen.

[Torsten R. (Firma: Torrox.de) (torstenrobitzki)]

Gerhard O. schrieb:
> Was wirklich gut wäre, kollektiv ein kleines Handbuch zu erstellen über
> die Do's und Don't's von C++ auf kleineren uC und GCC mit Beispielen als
> gemeinsame Platform die allen zugänglich ist.

Guckst Du hier: 
https://www.gitbook.com/book/arobenko/bare_metal_cpp/details

[Sheeva P. (sheevaplug)]

Sprachenlerner schrieb:
> Hmmm..., wenn man immer die "ideale" Sprache nutzen will, dann kann man
> wohl für jedes wechselnde Projekt auch immer die Programmiersprache
> wechseln um ein Quäntchen an Perfomance, Leistungsfähigkeit, Funktionen,
> Ressourcenverbrauch, etc... zu gewinnen. Ob es sinnvoll ist, alle
> x-Sprachen zu kennen, das halte ich eventuell übertrieben und finde es
> besser wenn man 1-2-3 Sprachen beherrscht, da aber umso besser. Oder?

Ja -- wobei die betreffenden Sprachen sich durchaus auch einmal ändern 
können. Bisher habe ich in meinem Leben jedenfalls schon mehr Sprachen 
vergessen, als ich aktuell noch flüssig beherrsche. Dabei habe ich mit 
jeder neuen Sprache was Neues gelernt, über die Sprache hinaus.

> Gern möchte ich lernen/können einen STM32 mit Touch-Display zu
> programmieren (z.B. für eine Haussteuerung). Welche Sprache ist da
> empfehlenswert?

C, wenn Du das Erlernte weiterverwenden willst, oder C++, wenn Dir der 
Sinn nach ein bisschen Lernen steht.

> Ebenso einen Raspberry mit Touch-Display und kleiner Visualisierung oder
> größeren Aufgaben (Linux/Windows Betriebssystem?). Was nimmt man da für
> eine Sprache?

Entweder eine Skriptsprache wie Python, Ruby oder Perl, oder aber eine 
kompilierte wie C oder C++, oder ein Zwischending mit Bytecode wie Java 
oder C#. Meine persönliche Wahl wäre Python, für performancekritisches 
erweitert mit C++ und Boost.Python, für schnelle GUIs mit Tkinter/Tix 
beziehungsweise für hübsche GUIs wahlweise mit Qt oder über eine nette 
Webanwendung mit Flask, jQuery und jqWidgets oä. YMMV.

> Wie sieht es auf Windows-PC aus, welche ist da die geeigneteste Sprache
> um grfische Oberflächen zu programmieren?

Die .NET-Sprachen wie C# und Visual Basic.NET sind die Platzhirsche, 
aber sie führen schnell in eine Plattformabhängigkeit. Ansonsten kannst 
Du für Windows mit jeder der obengenannten Sprachen eine GUI entwickeln 
-- YMMV.

> Nun es ist nicht leicht, eventuell werden mir nun 10 Sprachen empfhlen,
> aber so viele möchte ich nicht lernen. 2 oder max. 3 Sprachen, mehr
> nicht, damit sollte sich alles unter einen Hut bringen lassen.

Naja, C, C++, Java und C# sind wohl die Platzhirsche in der Industrie, 
bei dem von Dir gefragten Anwendungsspektrum (Windows und Linux, mit und 
ohne GUI) dürften C++ oder Java die am breitesten verwendbaren 
Kandidaten sein. Obendrein empfiehlt es sich, eine moderne Skriptsprache 
dabei zu haben, da ist Python nach meiner Wahrnehmung im Moment 
besonders weit vorne -- vor allem bezüglich der Unterstützung durch 
Bibliotheken und andere Tools.

[Gerhard O. (gerhard_)]

Torsten R. schrieb:
> Gerhard O. schrieb:
>> Was wirklich gut wäre, kollektiv ein kleines Handbuch zu erstellen über
>> die Do's und Don't's von C++ auf kleineren uC und GCC mit Beispielen als
>> gemeinsame Platform die allen zugänglich ist.
>
> Guckst Du hier:
> https://www.gitbook.com/book/arobenko/bare_metal_cpp/details

Vielen Dank, Torsten!

Das ist mir als C++ Beginner sehr nützlich.

Gruß,
Gerhard

[Wilhelm M. (wimalopaan)]

Gerhard O. schrieb:
> Torsten R. schrieb:
>> Gerhard O. schrieb:
>>> Was wirklich gut wäre, kollektiv ein kleines Handbuch zu erstellen über
>>> die Do's und Don't's von C++ auf kleineren uC und GCC mit Beispielen als
>>> gemeinsame Platform die allen zugänglich ist.
>>
>> Guckst Du hier:
>> https://www.gitbook.com/book/arobenko/bare_metal_cpp/details
>
> Vielen Dank, Torsten!
>
> Das ist mir als C++ Beginner sehr nützlich.

Genau dafür hatte ich diesen Thread mal begonnen:

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

Da könnte man mal was nachlesen ...

[Gerhard O. (gerhard_)]

Wilhelm M. schrieb:
> Da könnte man mal was nachlesen ...

Vielen Dank auch Dir, Wilhelm. Den Thread kannte ich noch gar nicht.

Gruß,
Gerhard

[X4U (Gast)]

Torsten R. schrieb:
> Das ist eigentlich überhaupt kein Problem, wenn man das Hauptberuflich
> macht.

Naja, wenn da das hauptberuflich nutzt dann stellt sich doch die Frage 
des Threadthemas nicht,  oder?

> Guckst Du hier:
> https://www.gitbook.com/book/arobenko/bare_metal_cpp/details

Danke für das Buch, interessante Einleitung (mehr würde ich eh nicht 
verstehen) da auf mich ich Seite 6 Absatz 2 zutrifft:

>> "...is that software in significant number (if not majority)
>> of projects gets written by hardware developers" ...
>> "The “C” programming language is a natural choice for them"


Wenn ich aber ne Frage stellen dürfte (so aus den Tal der Ahnungslosen)

Da ist auf den ersten Seiten davon die Rede
>> "that templates are   dangerous because of executable code bloating"

Was dann auch nicht bestritten sondern bestenfalls relativiert wird und 
weiter unten steht dann dass eben genau diese Templates ja der 
wichtigste Grund für µC-C++ wären "because of code reuse"


Wie gesagt ich hab null Ahnung von C++ aber ist das nicht 
widersprüchlich?

Zum Thema  code reuse hab ich noch ne Frage: Bei "C" "reuse" ich u.a. 
USB mass storage oder TFT driver etc ständig da es schlicht libs sind. 
Was ist da in C++ groß anders?

[Einer K. (Gast)]

X4U schrieb:
> Wie gesagt ich hab null Ahnung von C++ aber ist das nicht
> widersprüchlich?

Nein!
Das ist die ReineWahrheit.

z.B. eine Funktion, soll irgendeinen Datentype über die Serielle raus 
schicken.

Der C Programmierer schreibt für jeden Datentype eine eigene Funktion.
Alle den gleichen Namen, aber unterschiedliche Signaturen.

Der C++ Programmierer schreibt eine Template-Funktion.

Der Compiler macht in beiden Fällen das gleiche draus.

In C werden überflüssige Funktionen (in der Regel) weg optimiert
In C++ erzeugt der Compiler automatisch die benötigten Varianten.

Templates können also den Code aufblähen, ohne dass es unmittelbar im 
Code ersichtlich ist.

[Wilhelm M. (wimalopaan)]

Arduino F. schrieb:
> X4U schrieb:
>> Wie gesagt ich hab null Ahnung von C++ aber ist das nicht
>> widersprüchlich?
>
> Nein!
> Das ist die ReineWahrheit.
>
> z.B. eine Funktion, soll irgendeinen Datentype über die Serielle raus
> schicken.
>
> Der C Programmierer schreibt für jeden Datentype eine eigene Funktion.
> Alle den gleichen Namen, aber unterschiedliche Signaturen.

Nein, da C keine Funktionsüberladung besitzt.

[Wilhelm M. (wimalopaan)]

Arduino F. schrieb:

> Der C++ Programmierer schreibt eine Template-Funktion.
> Der Compiler macht in beiden Fällen das gleiche draus.

Das könnte sein ...

> In C werden überflüssige Funktionen (in der Regel) weg optimiert

Falls sie in einer Bibliothek sind, werden sie erst gar nicht dazu 
gebunden.

> In C++ erzeugt der Compiler automatisch die benötigten Varianten.

Ja, und nur die.

> Templates können also den Code aufblähen, ohne dass es unmittelbar im
> Code ersichtlich ist.

Das sehe ich einem Stück Code aus einer Bibliothek auch nicht an.

[X4U (Gast)]

Arduino F. schrieb:
> Der C Programmierer schreibt für jeden Datentype eine eigene Funktion.
> Alle den gleichen Namen, aber unterschiedliche Signaturen.

Also meine Wenigkeit nutzt in C sprintf und schiebt den String raus.
Da braucht es gar keine eigene Funktion. Wenn man selbsterklärende 
Variablennamen hat wird auch sofort klar was da passiert.

Insofern hinkt das Beispiel etwas, aber das mit den Templates verstehe 
ich.
Danke für die Erklärung

[Pandur S. (jetztnicht)]

> Vincent Hamp (vinci)
> Eigentlich ist kein einziger Chiphersteller daran interessiert
vernünftige Bibliotheken anzubieten. Bibliotheken bringen kein Geld und
verkaufen keine Hardware.

Was fuer eine Bibliothek denn ? Die Peripherien sind nun mal verschieden 
und bieten verschiedene Moeglichkeiten. Es gibt Leute, die sind mit 
einem PWM zufrieden, Andere, die wollen waehrend des 0-Zustandes schnell 
den ADC anwerfen und auslesen. Andere wollen ein PWM dithering haben.

Deswegen schreibt man sich die gewuenschte Funktion einmal und verwendet 
sie wieder.

[Einer K. (Gast)]

Wilhelm M. schrieb:
> Nein, da C keine Funktionsüberladung besitzt.

OK, dann behaupte ich ab jetzt das Gegenteil.

[Vincent H. (vinci)]

Arduino F. schrieb:
> X4U schrieb:
>> Wie gesagt ich hab null Ahnung von C++ aber ist das nicht
>> widersprüchlich?
>
> Nein!
> Das ist die ReineWahrheit.

Die Wahrheit liegt wie so oft irgendwo dazwischen.

"Templates erzeugen code bloat."
[X] falsch

"Tamples erzeugen keinen code bloat."
[X] falsch

"Falsch angewandt erzeugen Templates code bloat."
[X] richtig

"Richtig angewandt erzeugen Templates keinen code bloat."
[X] richtig


Folgendes simple Beispiel erzeugt unter gcc-7.1.0 den selben Code:

// Template print
template<size_t I>
static void template_print(const char (&str)[I])
{
  printf("%s\n", str);
}

// Non template print
static void non_template_print(const char* str)
{
  printf("%s\n", str);
}

// Print different versions...
  template_print("SzKL4yLe791xmL31XA");
  template_print("SzKL4yLe791xmL31XA,");
  template_print("SzKL4yLe791xmL31XA,0");
  non_template_print("SzKL4yLe791xmL31XA");
  non_template_print("SzKL4yLe791xmL31XA,");
  non_template_print("SzKL4yLe791xmL31XA,0");

Das mag jetzt ein dummes Beispiel sein, zeigt aber zumindest, dass 
Templates nicht automatisch Unmengen an Flash fressen.

[Torsten R. (Firma: Torrox.de) (torstenrobitzki)]

X4U schrieb:

> Naja, wenn da das hauptberuflich nutzt dann stellt sich doch die Frage
> des Threadthemas nicht,  oder?

Äh, ich habe beim OP keine Einschränlung auf Nebenberuflichkeit gesehen. 
Für mich ist C++ die beste Wahl wenn es um die Entwicklung von Firmware 
geht (solange es für den Controlller einen C++ Compiler gibt).

> Danke für das Buch, interessante Einleitung (mehr würde ich eh nicht
> verstehen) da auf mich ich Seite 6 Absatz 2 zutrifft:
>
>>> "...is that software in significant number (if not majority)
>>> of projects gets written by hardware developers" ...
>>> "The “C” programming language is a natural choice for them"

Hatte ich weiter oben sinngemß, ähnlich geschrieben. Ich bin aber auch 
der Meinung, dass Hardware-Entwickler Hardware entwickeln sollten und 
SW-Entwickler SW. Sicher, dass geht nicht immer, aber es ist sinnvoll.

> Wenn ich aber ne Frage stellen dürfte (so aus den Tal der Ahnungslosen)
>
> Da ist auf den ersten Seiten davon die Rede
>>> "that templates are   dangerous because of executable code bloating"
>
> Was dann auch nicht bestritten sondern bestenfalls relativiert wird und
> weiter unten steht dann dass eben genau diese Templates ja der
> wichtigste Grund für µC-C++ wären "because of code reuse"

Templates haben mehrere Anwendungen:
Eine Anwendung ist dem von Makros in C recht ähnlich. Typsicherer und 
kann bei entsprechend häufiger Instanziierung mit verschiedenen Typen 
dazu führen, dass identischer Code mehrfach im Binary landet (z.B. wenn 
die Typen sehr ähnlich sind, wie Zeiger). Das Problem kann man auch mit 
Makros haben, oder mit Copy/Paste.

Das muss aber nicht immer ein Problem sein: bevor ich den gleichen Code 
für unterschiedliche Datentypen in der Codebasis habe, habe ich Ihn 
lieber einmal als template, auch wenn ich dann mehrer unterschiedliche 
Instanziierungen im Binary habe.

Wenn es ein Problem ist, dann ist die Lösung häufig die, die auch in C 
verwendet wird. Sprich void*

Siehe auch Diskusion std::sort() / qsort() hier im thread.

> Wie gesagt ich hab null Ahnung von C++ aber ist das nicht
> widersprüchlich?

Nein, ist es nicht. Bei jedem Werkzeug muss man die Vor- und Nachteile 
abwägen. Um die Wahl bei den Werkzeugen zu haben, muss ich sie kennen. 
Immer dieses: Ich hatte damit (Diamant, Code-Bloat, Memory Leak...) mal 
ein Problem, also ist es böse und gehört verbant ist doch 
kontraproduktiv. Aus Fehlern sollte man einfach lernen.

> Zum Thema  code reuse hab ich noch ne Frage: Bei "C" "reuse" ich u.a.
> USB mass storage oder TFT driver etc ständig da es schlicht libs sind.
> Was ist da in C++ groß anders?

C++ hat einfach ein paar mehr Möglichkeiten vorgefertigte Lösungen 
anzubieten:

Wenn ich in C eine Library habe und ich möchte ohne overhead callbacks 
des Benutzers von der Library heraus aurufen, dann passiert das in C in 
der Regel mit weak symbols. Das sind aber globale Namen, sprich sobald 
ich mehr als einen USB Anschluss implementieren möchte, müssen diese 
Namen unterschiedlich sein. Wenn ich einen Satz an Funktionen 
implementieren muss, dann hat die Library auch keine Möglichkeit, mir 
eine Fehlermeldung zu geben, wenn ich als Nutzer eine Funktion vergessen 
habe. In C++ verwendet man an der Stelle compile time polymorphism 
(https://en.wikipedia.org/wiki/Curiously_recurring_template_pattern).

In C++ kann man Libraries auch besser Konfigurieren, sodass ungenutzter 
Code und Daten nicht im finalen Binary auftauchen. Das wesentliche 
Mittel in C dazu sind Makros.

Mit C++ kann man deutlich einfacher interne Domain Specific Languages 
bauen. Dann beschreibst Du als Nutzer einer Libray nur noch das zu 
lösende Problem und Library implementiert eine Lösung.

[Wilhelm M. (wimalopaan)]

Arduino F. schrieb:

> Templates können also den Code aufblähen, ohne dass es unmittelbar im
> Code ersichtlich ist.

Templates können den Code aber auch oft kleiner und schneller machen, 
weil man nicht mehr (s.a. oben qsort()) eine Funktion hat, die mit allen 
DT oder z.B. Array-Längen umgehen können muss, sondern man kann mit 
Hilfe von z.B. traits den Code eben besser anpassen.

[X4U (Gast)]

Vincent Hamp (vinci)
> Eigentlich ist kein einziger Chiphersteller daran interessiert
> vernünftige Bibliotheken anzubieten. Bibliotheken bringen kein Geld und
> verkaufen keine Hardware.

Natürlich nicht, ein Chiphersteller stellt Chips her. Es gibt aber 
Firmen wie Keil, IAR etc die sehr produktive Toolchains haben, mit sehr 
guten libs. Nur kosten die halt Geld.

Torsten R. schrieb:
> sobald ich mehr als einen USB Anschluss implementieren möchte, müssen
> diese Namen unterschiedlich sein.

Sind Sie ja auch, was imho Sinn macht.
Wo ist der unterschied zwischen (mal ganz einfach)

write_uart_3(SomeStuff);

und Tabellen?

> In C++ verwendet man an der Stelle compile time polymorphism

Das mag ja sein, aber irgendjemand muss dem wie auch immer gearteten 
Compiler erzählt werden wo a.) die Schnittstellen sind (macht bei C die 
Lib) und b.) welche du gerade Nutzen willst (muss man leider selber 
machen).


> Mit C++ kann man deutlich einfacher interne Domain Specific Languages
> bauen. Dann beschreibst Du als Nutzer einer Libray nur noch das zu
> lösende Problem und Library implementiert eine Lösung.

Danke für die ausführliche Erklärung. Aber sowas ist ehrlich gesagt das 
letzte was ich persönlich möchte. Das ist aber sicher sinnvoll wenn man 
nur Firmware für einen bestimmten Produktbereich macht.

Für mich gilt so wenig Abstraktionslayer wie möglich, aber das ist 
natürlich sehr spezifisch.

[X4U (Gast)]

Wilhelm M. schrieb:
>> Templates können also den Code aufblähen, ohne dass es unmittelbar im
>> Code ersichtlich ist.
>
> Das sehe ich einem Stück Code aus einer Bibliothek auch nicht an.

Ein Bild sagt mehr als 1000 Worte

[Chris F. (chfreund)]

Torsten R. schrieb:
> Äh, ich habe beim OP keine Einschränlung auf Nebenberuflichkeit gesehen.
> Für mich ist C++ die beste Wahl wenn es um die Entwicklung von Firmware
> geht (solange es für den Controlller einen C++ Compiler gibt).
> [...]
> Mit C++ kann man deutlich einfacher interne Domain Specific Languages
> bauen. Dann beschreibst Du als Nutzer einer Libray nur noch das zu
> lösende Problem und Library implementiert eine Lösung.

Genau darum geht es doch auch. Ich stimme dem Torsten hier zu. Wenn ich 
eine Plattform verwende auf der ich besser wartbaren und 
weiterverwendbaren Code schreiben kann, der dann obendrein auch noch 
angenehmer zu entwickeln ist, dann mache ich das auch so.

Wenn ich mich auf etwas anderes einlassen muss, weil es so günstiger 
ist, dann mache ich das natürlich auch. Also nur um die 
Lieblingsentwicklungsumgebung zu verwenden wäre es z.B. doof wenn ein 
viel teurerer und energiehungrigerer Controller eingesetzt wird. Wobei 
ich das wiederum für private Projekte auf jeden Fall so machen würde 
;-)).

[Wilhelm M. (wimalopaan)]

X4U schrieb:
> Wilhelm M. schrieb:
>>> Templates können also den Code aufblähen, ohne dass es unmittelbar im
>>> Code ersichtlich ist.
>>
>> Das sehe ich einem Stück Code aus einer Bibliothek auch nicht an.
>
> Ein Bild sagt mehr als 1000 Worte

Und?
Das kannste für templates doch auch machen ...

[X4U (Gast)]

Wilhelm M. schrieb:
> Und?
> Das kannste für templates doch auch machen ...

Eben, müßige Diskussion

[Der Mond (Gast)]

Zurück zum Kern der eigentlichen Frage:

Unbedingt auch mal LunaAVR anschauen !

http://avr.myluna.de
http://avr.myluna.de/doku.php?id=de:luna-commands

[Torsten R. (Firma: Torrox.de) (torstenrobitzki)]

X4U schrieb:
> Torsten R. schrieb:
>> sobald ich mehr als einen USB Anschluss implementieren möchte, müssen
>> diese Namen unterschiedlich sein.
>
> Sind Sie ja auch, was imho Sinn macht.
> Wo ist der unterschied zwischen (mal ganz einfach)
>
> write_uart_3(SomeStuff);
>
> und Tabellen?

Ich sehe keine Tabellen. Der Unterschied sind global eindeutige Symbole 
in C und recht lokale Symbole in C++:

void HAL_UART4_ReadHandler(void* input)
{
  handle_uart_input(input, first_compass);
}

void HAL_UART4_ErrorHandler()
{
  handle_uart_error(first_compass);
}

void HAL_UART3_ReadHandler()
{
  handle_uart_input(input, second_compass);
}

void HAL_UART3_ErrorHandler()
{
  handle_uart_error(second_compass);
}

vs.

compass< UART3 > first_compass;
compass< UART4 > second_compass;

> Für mich gilt so wenig Abstraktionslayer wie möglich, aber das ist
> natürlich sehr spezifisch.

Dann nimm Assembler!

[Johann L. (gjlayde)]

Wilhelm M. schrieb:
> Was C ggf. interessant machen könnte, sind nicht-standardisierte
> Erweiterungen wie memory-sections __flash oder auch saturierende arith.
> Typen und FixedPoint.
>
> Aber: das ist eigentlich wieder ein Argument für C++, denn die o.g.
> Dinge hat man schnell in C++ realisiert bzw. nimmt eine entsprechende
> Bibliothek und hat damit wieder vollständig konformen Code.

Also der Nachteil, dass C++ kein __flash Unterstützt, ist ein Vorteil 
von C++?

Tolles Argument.

Bis jetzt hab ich auch keine Überzeugende Implementierung von __flash in 
C++ gesehen, alles was C++ machen kann ist nicht-standard 
Erweiterungen wie Attribut progmem und Inline-Assembler (via 
pgm_read_xxx) irgendwie zu verstecken.

Und ja, irgendwann hab ich mal 100+ Zeilen C++ von dir gesehen, die das 
alles "ganz einfach" machen.  Irgendwie hab ich den Eindruck, du hast 
ein bissl den Realitätsbezug und die Bodenhaftung verloren.

Ich kann leidlich C++, aber ein Framework, das __flash abbildet und mit 
Strings, Array, eigenen Typen etc. arbeitet würd ich ehrlich gesagt 
nicht hinbekommen mit all den variadischen Templates (die man im 
Gegensatz zu Makros noch nichtmal debuggen kann) und wer weiß was alles. 
Und gleiche Performance ist nochmal ein ganz anderes Thema.

99.99% verwenden wohl einfach progmem + pgm_read_xxx und das war's. 
Oder gleich µC wo man solche Hacks nicht braucht.

Aber alleine, dass C++ nicht in der Lage ist, einen Qualifier zu 
modellieren oder zu implementieren, Lässt für mich schon Zweifel an der 
"Mächtigkeit" der Sprache aufkommen.  Gerade im Embedded-Bereich sind 
Qualifier wie __flash, __near, oder __far ja nicht unüblich, aber C++ 
ist auf dem Auge blind...

[X4U (Gast)]

Torsten R. schrieb:
> Ich sehe keine Tabellen. Der Unterschied sind global eindeutige Symbole
> in C und recht lokale Symbole in C++:

...

Danke für die Erklärung. Zum Verständnis meinerseits:

> compass< UART3 > first_compass;

wo ist da die Fehlerbehandlung.

> void HAL_UART4_ReadHandler(void* input)
> {
>  handle_uart_input(input, first_compass);
> }
> ...
> void HAL_UART3_ErrorHandler()
> {
>  handle_uart_error(second_compass);
> }

Bei mir wäre der ErrorHandler Teil der Funktion.

if (HAL_UART4_ReadHandler == 0) { MachWas} 
else { Handle the Fu**ingError} ** = no PointerToPointer

Da kann man jetzt noch einen weiteren layer rüberpacken damit das zu 
einer function wird.

Bitte nicht in falschen Hals kriegen, wenn C++ was für mich ist bin ich 
ab morgen am lernen, ich möchte das nur verstehen.

> Dann nimm Assembler!
;-)

[Torsten R. (Firma: Torrox.de) (torstenrobitzki)]

X4U schrieb:
> Danke für die Erklärung. Zum Verständnis meinerseits:
>
>> compass< UART3 > first_compass;
>
> wo ist da die Fehlerbehandlung.

template < typename Uart >
void compass< Uart >::error_handler()
{
   set_error_flag(); // or what ever, same code for every compass connect
}

> Bei mir wäre der ErrorHandler Teil der Funktion.
>
>

if (HAL_UART4_ReadHandler == 0) { MachWas}
> else { Handle the Fu**ingError} ** = no PointerToPointer

Deine Ausgangs-Frage drehte sich um Code-Reuse und was C++ für uns tun 
kann. Dass dein Code so nicht ein zweites mal genutzt werden kann, 
sollte klar sein.

> Da kann man jetzt noch einen weiteren layer rüberpacken damit das zu
> einer function wird.

Dass wollte ich mit meinem C-Skelett von oben so andeuten und aufzeigen, 
dass man in C++ als Nutzer eine Library deutlich einfacher SW-Teile mit 
einander verbinden kann.

>> Dann nimm Assembler!
> ;-)

Das war ernst gemeint. Entweder Du möchtest "so wenig Abstraktionslayer 
wie möglich", dann ist Assembler oder sogar Maschinencode das 
konkreteste, was Du haben kannst, oder die Aussage degeneriert zu einem: 
"Ich bin mit den Abstraktionen, die mir C bietet zufrieden". Was auch 
nicht schlimm ist, dann sollte man aber auch nichts anderes behaupten.

[Wilhelm M. (wimalopaan)]

Johann L. schrieb:

> Und ja, irgendwann hab ich mal 100+ Zeilen C++ von dir gesehen, die das
> alles "ganz einfach" machen.  Irgendwie hab ich den Eindruck, du hast
> ein bissl den Realitätsbezug und die Bodenhaftung verloren.

Die 100+ Zeilen sind 23 Zeilen ...

> Ich kann leidlich C++, aber ein Framework, das __flash abbildet und mit
> Strings, Array, eigenen Typen etc. arbeitet würd ich ehrlich gesagt
> nicht hinbekommen mit all den variadischen Templates (die man im
> Gegensatz zu Makros noch nichtmal debuggen kann) und wer weiß was alles.

Gut, wenn Du es nicht weißt, ist das natürlich erstmal nicht schlimm, 
solange Du nicht versuchst mit zu reden ...

> Und gleiche Performance ist nochmal ein ganz anderes Thema.

Und schon wieder dieses Un-Argument.

> Aber alleine, dass C++ nicht in der Lage ist, einen Qualifier zu
> modellieren oder zu implementieren,

Manche Dinge sind eben anders, weil sie anders sein müssen. Siehe auch 
die Behandlungs von unions (active member).

> Lässt für mich schon Zweifel an der
> "Mächtigkeit" der Sprache aufkommen.  Gerade im Embedded-Bereich sind
> Qualifier wie __flash, __near, oder __far ja nicht unüblich, aber C++
> ist auf dem Auge blind...

Wie Du ja gesehen hast, geht es trotzdem ...

[PeterPan (Gast)]

Johann L. schrieb:
> Bis jetzt hab ich auch keine Überzeugende Implementierung von __flash in
> C++ gesehen, alles was C++ machen kann ist nicht-standard
> Erweiterungen wie Attribut progmem und Inline-Assembler (via
> pgm_read_xxx) irgendwie zu verstecken.

Nur zur Info __flash ist nicht Bestandteil von C sondern nur eine 
compilerspezifische Erweiterung des GCCs. Eigentor.

Johann L. schrieb:
> Aber alleine, dass C++ nicht in der Lage ist, einen Qualifier zu
> modellieren oder zu implementieren, Lässt für mich schon Zweifel an der
> "Mächtigkeit" der Sprache aufkommen.  Gerade im Embedded-Bereich sind
> Qualifier wie __flash, __near, oder __far ja nicht unüblich, aber C++
> ist auf dem Auge blind...

Ich frage mich wie du dann überhaupt C in Betracht ziehen kannst, eine 
Sprache die nicht mal sowas wie echte Konstanten kennt (const wohl eher 
nicht...).

[X4U (Gast)]

Torsten R. schrieb:

>> Bei mir wäre der ErrorHandler Teil der Funktion.
>>
>>if (HAL_UART4_ReadHandler == 0) { MachWas}
>> else { Handle the Fu**ingError} ** = no PointerToPointer
> Deine Ausgangs-Frage drehte sich um Code-Reuse und was C++ für uns tun
> kann. Dass dein Code so nicht ein zweites mal genutzt werden kann,
> sollte klar sein.

Sorry für die naive Frage im voraus, warum nicht? Den kann ich doch 
genauso einfach cut and pasten.



>>> Dann nimm Assembler!
>> ;-)
>
> Das war ernst gemeint. Entweder Du möchtest "so wenig Abstraktionslayer
> wie möglich", dann ist Assembler oder sogar Maschinencode das
> konkreteste, was Du haben kannst,

Ist es eben nicht da Assembler und Maschinencode auch abstrakte sind.

Mit DIL Schaltern die Patterns auf die Datenleitungen legen wäre noch 
weniger abstrakt.

> "Ich bin mit den Abstraktionen, die mir C bietet zufrieden".
Bei C von zufrieden zu reden ist schon schwierig. Es ist halt ein 
Kompromiss. Man ist dicht genug auf der Hardware, hat aber eine Art 
Hochsprache besser evtl. mit "universeller Makroassembler" definiert.

[Torsten R. (Firma: Torrox.de) (torstenrobitzki)]

X4U schrieb:
> Torsten R. schrieb:

>> Deine Ausgangs-Frage drehte sich um Code-Reuse und was C++ für uns tun
>> kann. Dass dein Code so nicht ein zweites mal genutzt werden kann,
>> sollte klar sein.
>
> Sorry für die naive Frage im voraus, warum nicht? Den kann ich doch
> genauso einfach cut and pasten.

Weil Du selbst bei "Copy & Past"-Reuse (wobei meine Definition von 
Code-Reuse etwas anders wäre), die "4" ändern müsstest.

[Christopher J. (christopher_j23)]

Da hier ja schon mehrfach über den Einsatz von C++ in der Industrie 
diskutiert wurde wollte ich nochmal (ganz wertfrei) die 
Compilerunterstützung als Argument einwerfen, warum C++ derzeit noch 
nicht so weit verbreitet ist.

Klar gibt es den GCC und Clang und ich bin der Meinung das dies beides 
sehr gute Compiler sind aber wenn ich mich bei den "professionellen" 
Tools wie Keil oder IAR umschaue, so gibt es da derzeit maximal C++03, 
womit einige (mMn überaus nützliche) Features wie etwa constexpr unter 
den Tisch fallen. Ich weiß nicht genau wie die Lage bei Microchip oder 
anderen Compilerherstellern wie z.B. GreenHill ist aber ich vermute sie 
ist ähnlich. Natürlich steht die Welt nicht still, sondern dreht sich 
weiter und Keil hat daher ja auch seine künftigen Compiler komplett auf 
Clang-Basis umgestellt und wird damit künftig auch C++14 unterstützen. 
Bisher gibt es das aber nur für Cortex-A und der für Cortex-M befindet 
sich noch in der Beta-Phase und selbst wenn der dann mal endgültig 
released wird, wird einige Zeit ins Land gehen, bis die neuen Features 
von der großen Masse angenommen werden.

[Jörg W. (dl8dtl) (Moderator)]

PeterPan schrieb:
> __flash ist nicht Bestandteil von C sondern nur eine compilerspezifische
> Erweiterung des GCCs. Eigentor.

Namend memory spaces sind Bestandteil eines Standardvorschlags für
Embedded C.  Johann wollte darauf hinaus, dass dieser Vorschlag jedoch
auf einem standardmäßig bei C vorhandenen Feature basiert, den type
qualifiers, die es bei C++ nicht gibt.

[Achim.S (Gast)]

Torsten R. schrieb:
>>> Dann nimm Assembler!
>> ;-)
>
> Das war ernst gemeint. Entweder Du möchtest "so wenig Abstraktionslayer
> wie möglich", dann ist Assembler oder sogar Maschinencode das
> konkreteste, was Du haben kannst

Ich finde es nicht fair, C in die Nähe von Assembler zu rücken.

C abstrahiert den Befehlssatz des Prozessors. Auch wenn beide ähnlich 
performant sind, und bei der Beschreibung der Register ähnlich aussehen, 
so ist der Unterschied von C zu Assembler ein Quantensprung. Noch 
weitaus größer als der zu C++.

C++ ist eigentlich (überspitzt gesagt) das, was es zu Anfang war: Eine 
Metaprogrammiersprache für C, die alle guten Sprachkonzepte früher oder 
später in sich vereint. Nur das die C-Code Generierung heute nicht mehr 
benötigt wird.

[Torsten R. (Firma: Torrox.de) (torstenrobitzki)]

Achim.S schrieb:
> Ich finde es nicht fair, C in die Nähe von Assembler zu rücken.

Ach Meno! Gewöhnt euch doch mal an, Sätze im Kontext zu lesen und nicht 
immer irgend welche Halbsätze zu lesen und dann darauf frei von jedem 
Kontext zu antworten!!!

Hier geht es los:

>> Für mich gilt so wenig Abstraktionslayer wie möglich, aber das ist
>> natürlich sehr spezifisch.

> Dann nimm Assembler!

Wo habe ich jetzt C in die Nähe von Assembler gerückt? X4U möchte so 
wenig Abstraktion, wie möglich. Also habe ich ihm Assembler nahe gelegt.

Wie Du selbst schreibst:

> C abstrahiert den Befehlssatz des Prozessors.

Weniger abstrakt wäre dann direkt mit dem Befehlsatz des Prozessors zu 
arbeiten. Das wäre dann Assembler oder Maschinencode.

Ich verabschiede mich jetzt aus der Diskusion, die dreht sich doch nur 
noch im Kreis.

[christopher robin (Gast)]

Ich wette es gibt nicht genug Argumente gegen C++ um auf 1000 postings 
zu kommen. Denn niemand kennt die Sprache so gut, als dass er so viel 
dazu schreiben könnte, auch nicht die Community hier. Vielleicht sollten 
wir mal Bjarne Stroustrup einladen.

[PeterPan (Gast)]

Jörg W. schrieb:
> PeterPan schrieb:
>> __flash ist nicht Bestandteil von C sondern nur eine compilerspezifische
>> Erweiterung des GCCs. Eigentor.
>
> Namend memory spaces sind Bestandteil eines Standardvorschlags für
> Embedded C.  Johann wollte darauf hinaus, dass dieser Vorschlag jedoch
> auf einem standardmäßig bei C vorhandenen Feature basiert, den type
> qualifiers, die es bei C++ nicht gibt.

Ah ich verstehe, wusste ich noch gar nicht. Dann nehm ichs Eigentor 
zurück. Auf dem AVR mach kaum noch was und auf nem ARM Cortex muss man 
sich sowas nicht antun, da ist der ROM im gleichen Adressraum.

[Chris F. (chfreund)]

Ich hab damals von meinen Amigakumpels vorgeworfen bekommen ich sei ein 
"lamer skripter" weil ich auf einmal auch einen PC hatte auf dem ich mit 
Turbo-C gecodet hatte wo ich doch so gut den 68k-asm konnte.

Ist irgendwie beruhigend das 25 Jahre später noch die gleiche Art von 
Diskussion gepflegt wird. :-D

[Wilhelm M. (wimalopaan)]

Jörg W. schrieb:
>> PeterPan schrieb:
>>> __flash ist nicht Bestandteil von C sondern nur eine compilerspezifische
>>> Erweiterung des GCCs. Eigentor.
>>
>> Namend memory spaces sind Bestandteil eines Standardvorschlags für
>> Embedded C.  Johann wollte darauf hinaus, dass dieser Vorschlag jedoch
>> auf einem standardmäßig bei C vorhandenen Feature basiert, den type
>> qualifiers, die es bei C++ nicht gibt.


Natürlich gibt es type-qualifier in C++: const, volatile, mutable. Nur 
__flash, __flash1, ... als spezieller qualifier für named-address-spaces 
eben nicht, weil das eben non-standard Erweiterungen sind (erster TR aus 
2003).

[X4U (Gast)]

Torsten R. schrieb:
> X4U möchte so
> wenig Abstraktion, wie möglich. Also habe ich ihm Assembler nahe gelegt.

Danke für den Tipp, aber Assembler ist nun mal maschinenspezifisch. 
Dadurch wird die Abstraktion wieder größer da du mit mehreren Sprachen 
und Architekturen hantierst.

Davon ab gibt es keine Libs in Assembler.

> Ich verabschiede mich jetzt aus der Diskusion, die dreht sich doch nur
> noch im Kreis.

Dito, ist eh sinnlos weil jeder so oder so macht was er will.

Torsten R. schrieb:
> Weil Du selbst bei "Copy & Past"-Reuse (wobei meine Definition von
> Code-Reuse etwas anders wäre)

klar, es geht für mich darum das zu versehen also daher der simple 
Kontext

> , die "4" ändern müsstest.

Bitte nicht falsch verstehen, ich wechsle sofort zu C++ wenn ich das 
verstehe und für mich sinnvoll ist. So toll C ist, produktiv ist dieses 
Assemblersteno wirklich nicht.

Nun die Frage: Woher weiß denn dein C++ das die Schnittstelle 4 jetzt 
eine andere ist?

Also etwas das über

#define compass1 = IrgendNeSerielle

hinausgeht?

[Jörg W. (dl8dtl) (Moderator)]

Wilhelm M. schrieb:
> Nur __flash, __flash1, ... als spezieller qualifier für
> named-address-spaces eben nicht, weil das eben non-standard
> Erweiterungen sind

… die man dort offenbar aber nicht haben will.  Ansonsten hätte ja
nichts dagegen gesprochen, dass Johann sie auch für C++ aktiviert.
Ist ja nicht so, dass sie einfach so von sich aus im C-Compiler
aufgetaucht wären.

[Nop (Gast)]

X4U schrieb:

> Bei C von zufrieden zu reden ist schon schwierig. Es ist halt ein
> Kompromiss. Man ist dicht genug auf der Hardware, hat aber eine Art
> Hochsprache besser evtl. mit "universeller Makroassembler" definiert.

Exakt. Die Dosis macht das Gift.

Und außerdem ist einer der Vorteile von C, daß es einen Haufen 
Abstraktionen nicht bietet und man, wie Torvalds schon anmerkte, damit 
auch Leute draußen hält, die sich mehr daran hochziehen als an der 
eigentlichen Aufgabe. Ich finde, dieser Thread bestätigt Torvalds' Rant 
recht beeindruckend.


PeterPan schrieb:
> auf nem ARM Cortex muss man
> sich sowas nicht antun, da ist der ROM im gleichen Adressraum.

Es kann aber verschiedene Sorten disjunktes RAM geben. SRAM, CCM, 
Backup-RAM. Da muß man schon entscheiden, welche Variablen wohin gehen 
sollen.