mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Welche Programmiersprache auf µC


Autor: Schorsch (Gast)
Datum:

Bewertung
-30 lesenswert
nicht lesenswert
Hallo

Welche Programmiersprache sollte man heutzutage auf Mikrocontrollern mit 
viel Flash und RAM verwenden?


Ich kenne nur C, C++ und C#.

Ich denke, auf dem PC sollte man mit C# oder Java am schnellsten und 
einfachsten seine GUI Applikationen umsetzen können. Wer hier, in Zeiten 
der Rechner Kraftpakete mit hoher Taktung, zu C++ oder C greift, der 
sollte sich fragen, ob er zu viel Freizeit hat. Machbar ist alles auch 
mit Assembler.


Wie sieht es auf der Mikrocontroller Ebene aus?

Welche Gründe gibt es hier für den Einsatz von C oder C++.

C ist im Vergleich zu C++ eine Untermenge von C++ und im Vergleich dazu 
relativ einfach und schnell gelernt und beherrscht. Meiner Meinung nach.

C++ ist in Anwendung all seiner Möglichkeiten doch recht schwer zu 
verstehen.
Dennoch finde ich ein, von den sprachlichen Möglichkeiten, einfach 
gehaltenes C++ Programm für Mikrocontroller vorteilhaft gegenüber der 
Entwicklung mit C. Wenn jedoch sämtliche sprachlichen Stilmittel von C++ 
genutzt werden, so finde ich, verschwindet dieser Vorteil wieder, da 
diese nur wenige C++ Programmierer ohne Probleme verstehen.

Was denkt ihr über den Einsatz von C++ auf Mikrocontrollern?

Autor: Curby23523 N. (nils_h494)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Kann man machen.

Autor: Oliver S. (oliverso)
Datum:

Bewertung
5 lesenswert
nicht lesenswert
Schorsch schrieb:
> Wenn jedoch sämtliche sprachlichen Stilmittel von C++
> genutzt werden, so finde ich, verschwindet dieser Vorteil wieder, da
> diese nur wenige C++ Programmierer ohne Probleme verstehen.

C++ - Programmierer verstehen die allermeisten sprachlichen Stilmittel 
von C++, sonst wären es keine C++ Programmierer.

Insofern wäre es für dich sinnvoll, zunächst mal C++ zu lernen, bevor du 
über dessen Einsatz sinnierst.

Oliver

Autor: Manfred (Gast)
Datum:

Bewertung
8 lesenswert
nicht lesenswert
Schorsch schrieb:
> Ich denke, auf dem PC sollte man mit C# oder Java am schnellsten und
> einfachsten seine GUI Applikationen umsetzen können. Wer hier, in Zeiten
> der Rechner Kraftpakete mit hoher Taktung, zu C++ oder C greift, der
> sollte sich fragen, ob er zu viel Freizeit hat.

Wer hier von Kraftpaketen und Java spricht, muß sich fragen lassen, 
weshalb er Ressourcen und Zeit seiner Kunden vergeudet.

Der Programmierer ist zu faul, anständig zu programmieren und hunderte 
oder tausende seiner Kunden oder nee, Opfer brauchen mehr Speicher und 
warten unnötig lange auf das Rechenergebnis.

Wenn ich Alternativen habe, fliegt Javascheiß direkt wieder raus.

Autor: Skyper (Gast)
Datum:

Bewertung
5 lesenswert
nicht lesenswert
Schorsch schrieb:
> Ich denke, auf dem PC sollte man mit C# oder Java am schnellsten und
> einfachsten seine GUI Applikationen umsetzen können. Wer hier, in Zeiten
> der Rechner Kraftpakete mit hoher Taktung, zu C++ oder C greift, der
> sollte sich fragen, ob er zu viel Freizeit hat.

Also ich empfinde C# als reine Monokultur (Mono unter Linux ist nicht so 
der Hit....)... und bei Java musst Du immer die VM mit rumschleppen, 
aktuell halten usw...

Für C++ gibt es viele nette GUI-Frameworks, große und kleine... und 
einige bieten den Vorteil dabei auch noch unter SEHR vielen Plattformen 
zu laufen, die Anwendung muss dann einmalige für die Zielplattform 
kompiliert werden und fertig....

Beitrag #5033526 wurde von einem Moderator gelöscht.
Autor: ccc (Gast)
Datum:

Bewertung
5 lesenswert
nicht lesenswert
Schorsch schrieb:
>
> Was denkt ihr über den Einsatz von C++ auf Mikrocontrollern?

Ja. Freitag.

Autor: Sheeva P. (sheevaplug)
Datum:

Bewertung
11 lesenswert
nicht lesenswert
Schorsch schrieb:
> Ich denke, auf dem PC sollte man mit C# oder Java am schnellsten und
> einfachsten seine GUI Applikationen umsetzen können. Wer hier, in Zeiten
> der Rechner Kraftpakete mit hoher Taktung, zu C++ oder C greift, der
> sollte sich fragen, ob er zu viel Freizeit hat.

Das ist, mit Verlaub, ziemlicher Unsinn. Viele, wenn nicht gar die 
meisten modernen GUI-Programme sind in C++ implementiert. Die 
Entwicklereffizienz von Programmiersprachen mit automatischer 
Speicherverwaltung / Garbage Collection wie Java oder eben C# ist nicht 
wesentlich höher als die von C++, schon vor vielen Jahren -- lange vor 
C++11ff, als die STL noch in ihren Kinderschuhen steckte und RAII noch 
eher selten verwendet wurde -- lag die Entwicklereffizienz von 
Java-Entwicklern in einer Untersuchung des renommierten Dr.Dobb's 
Magazine gerade einmal etwa 12% höher als jene von C++-Entwicklern.

Obendrein ist die automatische Speicherverwaltung gerade in Programmen, 
die größere Datenmengen mit engen zeitlichen Vorgaben verarbeiten 
müssen, ein ziemlich zweischneidiges Schwert, wie ich aus eigener 
leidvoller Erfahrung weiß. Häufig muß man in die Optimierung des Garbage 
Collectors dieselbe, in manchen Fällen sogar ein Vielfaches der in der 
Entwicklung gesparten Zeit investieren.

Insofern ist die Entwicklereffizienz von C++ wesentlich besser, als Du 
zu glauben scheinst. Dank moderner C-Frameworks wie GTK kann man auch in 
C sehr schnell und effizient GUI-Applikationen entwickeln, und die 
größten Aufwände bei der Entwicklung von GUI-Software sind eh nicht im 
Coding -- ok, vielleicht bei Hobbyisten, aber nicht im professionellen 
Umfeld.

> Wie sieht es auf der Mikrocontroller Ebene aus?
>
> Welche Gründe gibt es hier für den Einsatz von C oder C++.
>
> C ist im Vergleich zu C++ eine Untermenge von C++ und im Vergleich dazu
> relativ einfach und schnell gelernt und beherrscht. Meiner Meinung nach.

Meiner Meinung nach nicht. C hat viele subtile Fein- und Eigenheiten, 
die Anfänger regelmäßig überfordern. "Relativ einfach und schnell 
gelernt und beherrscht" trifft heute am Ehesten auf moderne 
Skriptsprachen wie Python, Ruby, Lua oder Perl zu, aber bislang 
jedenfalls auf keine kompilierte und typsichere Programmiersprache -- 
jedenfalls keine, die mir bekannt ist.

> C++ ist in Anwendung all seiner Möglichkeiten doch recht schwer zu
> verstehen.
> Dennoch finde ich ein, von den sprachlichen Möglichkeiten, einfach
> gehaltenes C++ Programm für Mikrocontroller vorteilhaft gegenüber der
> Entwicklung mit C. Wenn jedoch sämtliche sprachlichen Stilmittel von C++
> genutzt werden, so finde ich, verschwindet dieser Vorteil wieder, da
> diese nur wenige C++ Programmierer ohne Probleme verstehen.
>
> Was denkt ihr über den Einsatz von C++ auf Mikrocontrollern?

Naja, die meisten Möglichkeiten von C++ sind in so begrenzten Umgebungen 
wie Mikrocontrollern ohnehin nicht besonders sinnvoll. Zum Beispiel eine 
dynamische Speicherallokation ist auf Mikrocontrollern eher selten, auch 
dynamisches Binden wird dort nicht oft verwendet.

Aber der Clou ist: auch ein Programm, das nur ein einziges C++-Features 
nutzt, ist damit ein valides C++-Programm. Datenkapselung und Vererbung 
zum Beispiel können auch auf kleinsten 8-Bittern sinnvoll und ohne 
irgendwelche Nachteile verwendet werden. Schon vermeintliche 
Kleinigkeiten wie Scoped Enums sind ein guter und ausreichender Grund 
für C++ statt C.

Dein "Argument" gegen C++, daß nur wenige C++-Entwickler "sämtliche 
sprachlichen Stilmittel ohne Probleme verstehen" halte ich im Übrigen 
für unsinnig. Modernes C++ ist ziemlich einfach, in vielerlei Hinsicht 
sogar wesentlich einfacher als C; schon auf PCs verwendet kaum ein 
Entwickler "sämtliche sprachlichen Stilmittel" von C++. Dies gilt erst 
Recht auf Mikrocontrollern, wo es wesentlich wichtiger ist zu wissen, 
welche der Sprachmittel dort sinnvoll und ohne übermäßige Belastung der 
meistens knappen Ressourcen angewendet werden können.

Aber auch abseits dessen ist es ein unsinniges Argument, daß nur wenige 
C++-Entwickler "sämtliche sprachlichen Stilmittel" verstünden. Das ist 
höchstens ein Argument gegen die betreffenden Entwickler, jedoch keines 
gegen eine Programmiersprachen -- schon gar nicht, wenn es um eine der 
am Weitesten verwendeten Programmiersprachen geht. Vielleicht gilt es ja 
für Dich, daß Du nicht "sämtliche sprachlichen Stilmittel" beherrschst, 
aber von sich auf andere zu schließen, ist erstens stillos und zweitens 
ganz sicher kein valides Sachargument. ;-)

Autor: Sven B. (scummos)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Oliver S. schrieb:
> Schorsch schrieb:
>> Wenn jedoch sämtliche sprachlichen Stilmittel von C++
>> genutzt werden, so finde ich, verschwindet dieser Vorteil wieder, da
>> diese nur wenige C++ Programmierer ohne Probleme verstehen.
>
> C++ - Programmierer verstehen die allermeisten sprachlichen Stilmittel
> von C++, sonst wären es keine C++ Programmierer.

Ich melde mal Zweifel an :D

Autor: Der Nuller (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich verwende der besseren Selbstdokumentation wegen gerne ein Pascal auf 
Controllern. Bisher ein E-Lab Pascal auf AVR, nun ein Mikroe Pascal auf 
PIC32.
Die Dialekte sind hinreichend aehnlich, dass ein Protokol schnell 
uebertragen ist. Sonst ist portabilitaet kein Thema. Etwas, was auf 
einem PC laeuft, wird nie auf einem controller laufen, was ich auf einem 
PIC32 laufen lassen wird weder auf PC noch auf AVR portiert.

Aeh ja. auf dem PC lass ich Delphi laufen.

Autor: avr (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Der Nuller schrieb:
> Etwas, was auf einem PC laeuft, wird nie auf einem controller laufen,
> was ich auf einem PIC32 laufen lassen wird weder auf PC noch auf AVR
> portiert.

Meinst du. Aber nur solange die Plattform nicht gewechselt werden muss. 
Mikrocontroller Software kann man übrigens auch auf dem PC testen und 
Debuggen, wenn entsprechende abstrahiert wurde. Es gibt auch 
Anwendungen, in denen die gleiche software auf Mikrocontroller und PC 
verwendet wird (ti nspire).

Autor: A. S. (achs)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der Nuller schrieb:
> der besseren Selbstdokumentation

Was meinst Du damit?

Und warum den uC-Code nicht am PC testen und laufen lassen?

Autor: MaWin (Gast)
Datum:

Bewertung
-4 lesenswert
nicht lesenswert
Mit C# kann man fehlerfreiere, mit C schnellere Programme schreiben als 
mit C++ aber man schreibt ungern alles alleine und die meisten 
Bibliotheken gibt es derzeit für C++.

Autor: Wilhelm M. (wimalopaan)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Man kann C nicht als Untermenge von C++ bezeichnen, denn es gibt bei 
manchen Konstrukten subtile Unterschiede ...

Meine (persönliche) Antwort: nur C++!

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.

Natürlich muss man die richtigen Werkzeuge aus dem großen Werkzeugkasten 
C++ auswählen und die nicht angebrachten drin liegen lassen, etwa 
Heap-Alloc, RTTI, Exceptions, RT-Polymorphie, ...

Aber gerade die modernen features von C++ wie etwa variadic-templates, 
fold-expressions, constexpr, lambdas, etc., etc. machen das Leben auch 
auf einem µC sehr sehr angenehm (natürlich auch die normalen: templates, 
sichere Container, ...)

Für mich ist die Entscheidung klar!

Autor: Clemens W. (daxmus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
C# und Java sind einfacher zu lernen und verstehen, ja. C und C++ haben 
viele Eigenheiten, aber auch viele Vorteile, gerade im Umgang mit 
Ressourcen. Bei C++ war der Sprung von 98 auf 11 recht gravierend und 
hat viele Annehmlichkeiten mit sich gebracht.
Auf uC verwende ich C, einfach weil ich bereits C++ behersche und auf 
dem PC überwiegend C++ mit dem Qt Framework. Klar man muß auf mehr 
achten, aber dennoch hat es bisher sehr wenige Situationen gegeben, in 
denen ich gerne auf C# umgestiegen wäre.

Autor: Zitronen F. (jetztnicht)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Welche Programme soll man denn auf dem PC UND auf einem Controller 
laufen lassen ? Ich finde leider exakt gar keins.

Auf einem Controller habe ich auch immer etwas mit Kommunikation, 
Steuerung, Regelung, Timing, Messung.

: Bearbeitet durch User
Autor: Μαtthias W. (matthias) Benutzerseite
Datum:

Bewertung
4 lesenswert
nicht lesenswert
Sapperlot W. schrieb:
> Welche Programme soll man denn auf dem PC UND auf einem Controller
> laufen lassen ? Ich finde leider exakt gar keins.

Protokolle (z.B. CANOpen) lassen sich am PC viel schöner debuggen als 
auf dem späteren Zielsystem. Oder auch grafische Oberflächen. Wir lassen 
auch UnitTests für hardwareunabhängige Module auf dem PC laufen. 
Grundsätzlich läuft alles oberhalb der Hardwareschicht auch auf dem PC 
um es eben schneller /besser testen und debuggen zu können.

> Auf einem Controller habe ich auch immer etwas mit Kommunikation,
> Steuerung, Regelung, Timing, Messung.

Der hardwareabhängige Teil wird auf dem PC dann entsprechend simuliert.

Matthias

Autor: Adapter (Gast)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
Schorsch schrieb:
> Hallo
>
> Welche Programmiersprache sollte man heutzutage auf Mikrocontrollern mit
> viel Flash und RAM verwenden?
>
> Ich kenne nur C, C++ und C#.
>

Die Fragestellung ist falsch. Mikrocontroller (im Gegensatz zu "All 
Purpose Computern") werden so für ihre Anwendungsfälle ausgesucht, dass 
ihre Ressourcen (Flash, RAM, Prozessorgeschwindigkeit, Peripherie) 
ausreichen, um die Aufgabe zu lösen. Überdimensionierte Controller 
machen im Embedded Bereich (noch) keinen Sinn, und das wird sich erst 
dann ändern, wenn die Preisunterschiede zwischen kleinen und grossen 
Chips so gering sind, dass man sich auch bei grossen Stückzahlen eine x 
fache Überdimensionierung leisten kann.

Das Laufzeitsystem von C#, Java & Co ist dermassen Ressourcenhungrig, 
dass die Laufzeitunterstützung selbst im Minimalfall um ein Vielfaches 
grösser ist als der Code, der die eigentliche Aufgabe löst. Von der 
fehlenden Echtzeitfähigkeit mal ganz abgesehen. Also wirst Du 
"Mikrocontroller mit viel Flash und RAM" auch nur dort finden, wo das 
viel Flash und RAM zur Lösung der Aufgabenstellung benötigt wird, und 
damit sind Java und Konsorten out.

C++ ist Anders, solange Du eine Minimaluntermenge benutzt (z.B. auf SEH 
verzichtest). Da ist der Unterschied zu C kaum messbar, das steht aber 
an sehr vielen Stellen im Internet zu lesen (s.u.)

>
> Was denkt ihr über den Einsatz von C++ auf Mikrocontrollern?

Wenn Du das wirklich wissen willst, brauchst Du nur die Suchfunktion im 
Forum zu benutzen. Kaum ein Thema, das breiter und leidenschaftlicher 
diskutiert worden ist und wird. Aber scheinbar ist noch nicht von Alles 
Alles geschrieben worden.

Autor: Stm M. (stmfresser)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Schorsch schrieb:
> Hallo
>
> Welche Programmiersprache sollte man heutzutage auf Mikrocontrollern mit
> viel Flash und RAM verwenden?

Haskell ist geeignet für µC mit viel Flash und RAM ^^

Autor: Oliver S. (oliverso)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sven B. schrieb:
>> C++ - Programmierer verstehen die allermeisten sprachlichen Stilmittel
>> von C++, sonst wären es keine C++ Programmierer.
>
> Ich melde mal Zweifel an :D

;)

Ursprünglich schrub ich da "alle", aber das hat mich dann selbst nicht 
überzeugt ;)

Oliver

Autor: Stefanus F. (stefanus)
Datum:

Bewertung
4 lesenswert
nicht lesenswert
Die Diskussion hatten wir schon oft genug.
Ich erwarte nicht, dass dieser Thread irgend eine neue Erkenntnis zutage 
bringt. Lasst das Thema ruhen, bevor es wieder mit persönlichen 
Beleidgungen los geht - denn so endet das Thema immer.

: Bearbeitet durch User
Autor: Crazy H. (crazy_h)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der Nuller schrieb:
> Bisher ein E-Lab Pascal auf AVR,
brav :-)

Autor: Schreiber (Gast)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
Schorsch schrieb:
> Wie sieht es auf der Mikrocontroller Ebene aus?

Ganz einfach:
Speicher ist teuer, Ram ist teur, Taktfrequenz kostet ebenfalls. 
Dementsprechend wird man damit, zumindest bei Großserienprodukten, 
möglichst sparsam umgehen. Java, C++ u.dgl. ist dementsprechend out, C 
ist in...

Bei normaler PC-Software wird halt eine CD oder DVD, in hartnäckigen 
Fällen eine BlueRay, ausgeliefert, da kostet Speicherplatz fast nichts. 
Für den eigentlichen Computer, inklusive Hardwareupgrades, ist dann der 
Kunde zuständig.

Autor: Wilhelm M. (wimalopaan)
Datum:

Bewertung
5 lesenswert
nicht lesenswert
Schreiber schrieb:
> Schorsch schrieb:
>> Wie sieht es auf der Mikrocontroller Ebene aus?
>
> Ganz einfach:
> Speicher ist teuer, Ram ist teur, Taktfrequenz kostet ebenfalls.
> Dementsprechend wird man damit, zumindest bei Großserienprodukten,
> möglichst sparsam umgehen. Java, C++ u.dgl. ist dementsprechend out, C
> ist in...

Widerspruch: C++ ist keinesfalls laufzeitmäßig "teurer" als C. Das sind 
alte Mythen, die eigentlich noch nie gestimmt haben, und jetzt erst 
recht nicht mehr stimmen ...

Autor: Ruediger A. (Firma: keine) (rac)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Wilhelm M. schrieb:
> Schreiber schrieb:
>> Schorsch schrieb:
>>> Wie sieht es auf der Mikrocontroller Ebene aus?
>>
>> Ganz einfach:
>> Speicher ist teuer, Ram ist teur, Taktfrequenz kostet ebenfalls.
>> Dementsprechend wird man damit, zumindest bei Großserienprodukten,
>> möglichst sparsam umgehen. Java, C++ u.dgl. ist dementsprechend out, C
>> ist in...
>
> Widerspruch: C++ ist keinesfalls laufzeitmäßig "teurer" als C. Das sind
> alte Mythen, die eigentlich noch nie gestimmt haben, und jetzt erst
> recht nicht mehr stimmen ...

ACK. Ich vermute mal, dass "Schreiber" statt C++ C# schreiben wollte. 
Dann würde auch die Nebeneinanderstellung mit Java Sinn machen.

Wie schon mehrfach geschrieben wurde, kann man C++ so nutzen, dass der 
Footprintunterschied zu C gen 0 geht.

Beitrag #5034468 wurde von einem Moderator gelöscht.
Beitrag #5034558 wurde von einem Moderator gelöscht.
Beitrag #5034574 wurde von einem Moderator gelöscht.
Autor: Sheeva P. (sheevaplug)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Das macht aber nicht die Sprache, sondern nur die Compiler interessant, 
die diese nicht-standardisierten Erweiterungen anbieten. ;-)

Autor: Sheeva P. (sheevaplug)
Datum:

Bewertung
5 lesenswert
nicht lesenswert
Schreiber schrieb:
> Speicher ist teuer, Ram ist teur, Taktfrequenz kostet ebenfalls.
> Dementsprechend wird man damit, zumindest bei Großserienprodukten,
> möglichst sparsam umgehen. Java, C++ u.dgl. ist dementsprechend out, C
> ist in...

Eigentlich ist C++ "in", einige Menschen haben es nur noch nicht 
gemerkt. C++ kostet nichts, verbraucht keinen zusätzlichen Speicher, 
keinen RAM, und keine CPU-Takte im Vergleich zu C, und ist also genauso 
sparsam wie C -- aber C++ bietet viele Möglichkeiten, um die 
Organisation und die Wiederverwendbarkeit des Code teilweise erheblich 
zu verbessern. Das erkennt man aber erst, wenn man über den Schatten der 
bekannten Vorurteile springt, und C++ einfach mal lernt und praktisch 
einsetzt.

Autor: Vincent H. (vinci)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sheeva P. schrieb:
> Schreiber schrieb:
>> Speicher ist teuer, Ram ist teur, Taktfrequenz kostet ebenfalls.
>> Dementsprechend wird man damit, zumindest bei Großserienprodukten,
>> möglichst sparsam umgehen. Java, C++ u.dgl. ist dementsprechend out, C
>> ist in...
>
> Eigentlich ist C++ "in", einige Menschen haben es nur noch nicht
> gemerkt. C++ kostet nichts, verbraucht keinen zusätzlichen Speicher,
> keinen RAM, und keine CPU-Takte im Vergleich zu C, und ist also genauso
> sparsam wie C -- aber C++ bietet viele Möglichkeiten, um die
> Organisation und die Wiederverwendbarkeit des Code teilweise erheblich
> zu verbessern. Das erkennt man aber erst, wenn man über den Schatten der
> bekannten Vorurteile springt, und C++ einfach mal lernt und praktisch
> einsetzt.

Leider nein. Laut Dan Saks sinkt die Trendlinie von embedded C++ 
software, während die von C steigt.

Siehe hier:
Youtube-Video "CppCon 2016: Dan Saks “extern c: Talking to C Programmers about C++”"

Autor: PeterPan (Gast)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
Sheeva P. schrieb:
> Eigentlich ist C++ "in", einige Menschen haben es nur noch nicht
> gemerkt. C++ kostet nichts, verbraucht keinen zusätzlichen Speicher,
> keinen RAM, und keine CPU-Takte im Vergleich zu C, und ist also genauso
> sparsam wie C -- aber C++ bietet viele Möglichkeiten, um die
> Organisation und die Wiederverwendbarkeit des Code teilweise erheblich
> zu verbessern. Das erkennt man aber erst, wenn man über den Schatten der
> bekannten Vorurteile springt, und C++ einfach mal lernt und praktisch
> einsetzt.

Richtig, diese Vorurteile kommen meiner Erfahrung nach von Anfängern, 
die irgendwann mal irgendwelche C++ Features unnötig ohne Sinn und 
Verstand genutzt haben und sich nicht bewusst waren, dass diese an 
bestimmten Stellen ordentlich Performance kosten können (manche, nicht 
alle!). Da wird dann z.B. am laufenden Band eine verkettete Liste 
(std::list) kopiert, d.h. eine neue Liste angelegt, mehrmals Speicher 
vom Heap angefordert und der Inhalt kopiert. Oder anderes Beispiel: 
Stringverkettung mit std::string. Und am Ende heult man im Internet rum, 
dass C++ so viel langsamer ist als C. Der Rest nimmts ungeprüft auf und 
verbreitet es weiter...

Autor: Carl D. (jcw2)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Vincent H. schrieb:
>
> Leider nein. Laut Dan Saks sinkt die Trendlinie von embedded C++
> software, während die von C steigt.
>
> Siehe hier:
> Youtube-Video "CppCon 2016: Dan Saks “extern c: Talking to C Programmers about C++”"

Sehr guter Vortrag, übrigens nicht der einzige aus der Reihe. Dan Saks 
sieht aber das Problem, daß Fakten nichts an Überzeugungen ändern 
können, nicht nur im Enbeded-Entwicklungsbereich. Womit er leider recht 
behielt.
Schön ist auch der Vortrag, der zeigt, wie man mit C++14 Videospiele für 
dem C64 schreibt.
Youtube-Video "CppCon 2016: Jason Turner “Rich Code for Tiny Computers: A Simple Commodore 64 Game in C++17”"
Wie man z.B. mit constexpr RGB-Farbewerte in C64-Farbwerte wandeln kann. 
Genauso kann man bei einem AVR bei gegebener Zeit die optimale 
Kombination aus Prescaler und CompareA-Registerwert ermitteln. Zur 
Compilezeit. Alternativ frickelt der Moby die Bits von Hand zusammen.

: Bearbeitet durch User
Autor: Wilhelm M. (wimalopaan)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Sheeva P. schrieb:
> 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.
>
> Das macht aber nicht die Sprache, sondern nur die Compiler interessant,
> die diese nicht-standardisierten Erweiterungen anbieten. ;-)

Genau. Und wie ich weiter schrieb, ist das ja wieder ein Argument für 
C++ ...

Autor: Wilhelm M. (wimalopaan)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Carl D. schrieb:
> Vincent H. schrieb:
>>
>> Leider nein. Laut Dan Saks sinkt die Trendlinie von embedded C++
>> software, während die von C steigt.
>>
>> Siehe hier:
>> Youtube-Video "CppCon 2016: Dan Saks “extern c: Talking to C Programmers about C++”"
>
> Sehr guter Vortrag, übrigens nicht der einzige aus der Reihe. Dan Saks
> sieht aber das Problem, daß Fakten nichts an Überzeugungen ändern
> können, nicht nur im Enbeded-Entwicklungsbereich. Womit er leider recht
> behielt.
> Schön ist auch der Vortrag, der zeigt, wie man mit C++14 Videospiele für
> dem C64 schreibt.
> Youtube-Video "CppCon 2016: Jason Turner “Rich Code for Tiny Computers: A Simple Commodore 64 Game in C++17”"

In einem anderen Beitrag hatte ich einfach mal angefangen, solche 
interessanten Vorträge, o.ä zu sammeln, damit sich dort jeder 
informieren kann. Und das nicht ständig diese alten, längst überholten 
und auch falschen Mythen zitiert werden.

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

> Wie man z.B. mit constexpr RGB-Farbewerte in C64-Farbwerte wandeln kann.
> Genauso kann man bei einem AVR bei gegebener Zeit die optimale
> Kombination aus Prescaler und CompareA-Registerwert ermitteln. Zur
> Compilezeit. Alternativ frickelt der Moby die Bits von Hand zusammen.

Ja, man kann sehr viel schöne Dinge zur Compilezeit machen: suchen, 
sortieren, optimieren, ... Dazu habe ich auch schon etliches mal 
gepostet, aber ich glaube, das hat eigentlich niemand bemerkt. Meistens 
kommt dann die CPP/C-Fraktion um die Ecke mit irgendwelche grausligen 
Macros ...

: Bearbeitet durch User
Autor: Nop (Gast)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
Vincent H. schrieb:

> Leider nein. Laut Dan Saks sinkt die Trendlinie von embedded C++
> software, während die von C steigt.

Was auch kein Wunder ist, denn das Hauptproblem von C++ wird mit jedem 
neuen Standard schlimmer: Der Sprachumfang. Zwar werden neue Sachen 
eingeführt, die mehr Annehmlichkeiten bringen, aber da in der realen 
Welt die überwiegende Zahl der Projekte die Erweiterung bestehender 
Software ist, muß man dann immer mehr Standards beherrschen.

Das mag vielleicht noch für reine Coder leistbar sein. Aber embedded ist 
das Coding vielfach nicht das Entscheidende, sondern Domänenwissen. 
Deswegen auch z.B. die ganzen E-Ings als SW-Entwickler mit HW-Wissen, 
und mehr als C geht da einfach nicht.

Es sei denn, man macht eine völlige Trennung auf, aber dann hat man im 
Troubleshooting wieder ein Problem, weil der Systemfachmann dann den 
Code nicht versteht, während der Coder das Domänenwissen nicht hat.

Es wird noch schlimmer, weil C++ so ziemlich alles ermöglicht. Das heißt 
im Umkehrschluß aber auch, daß es nicht ausreicht, wenn man weiß, welche 
Dinge man wozu gebrauchen kann, sondern man muß für embedded auch noch 
wissen, was exakt unter der Haube abläuft. Das ist keine Abstraktion, 
das ist obfuscation.

Sicher, die Experten, die das draufhaben, die haben da kein Problem. 
Aufgrund der größeren Schwierigkeit, dieses Level mit C++ hinzukriegen 
im Vergleich zu C, sind diese Leute dann aber auch einfach teurer, ganz 
besonders wenn sie außerdem auch noch Domänen-Fachleute sind. Das ist 
kein technisches Problem, sondern ein wirtschaftliches.

Selbst Stroustrup gibt das ja zu - mit C schießt man sich in den Fuß 
(was aber leicht zu beheben ist). Mit C++ schießt man sich seltener, 
aber dann das ganze Bein ab, und das ist viel schwieriger zu beheben. 
Was Stroustrup nicht sagt, ist, daß die mäßigen C++-Programmierer sich 
ähnlich oft ins Bein schießen wie mäßige C-Programmierer sich in den 
Fuß.

Und wieso wird das nicht groß diskutiert? Weil keiner sich traut 
zuzugeben, ein mäßiger Programmierer zu sein. Besonders dann nicht, wenn 
die wirklich guten Programmierer den Mund aufmachen. Auch das ist kein 
technisches Problem, sondern ein soziales.

Ja, sicher, wenn man verlinkte Listen in C++ einfach aus dem Regal 
greifen kann, anstatt die fehlerträchtig und wahrscheinlich auch 
langsamer selber in C hinzufrickeln, ist das cool. Ich habe aber in 20 
Jahren embedded nie eine verlinkte Liste gebraucht, die man nicht 
genausogut auch mit einem statischen Array hätte machen können.

Überhaupt kommt meiner Erfahrung nach die Komplexität embedded, anders 
als auf dem PC, nicht durch riesige einzelne Software zustande. Sondern 
die Modularisierung geschieht auf Hardware-Ebene, indem das Systemdesign 
schon die Blöcke auf unterschiedliche Teilsysteme runterbricht, die dann 
über geeignete Interfaces kommunizieren. Das wird schon durch 
Anforderungen an Segregation sowie durch Reaktionszeiten erzwungen.

Die Alternative ist natürlich, und auch das sehe ich in der Praxis, daß 
man 95% von C++ ignoriert und C mit Klassen macht - und statischen 
Objekten, weil dynamische Speicherverwaltung das System sowieso 
untestbar macht. Das ist noch ganz übersichtlich nutzbar.

Wenn man aber 95% von C++ nicht nutzt, schrumpfen genau dadurch auch die 
potentiellen Vorteile zusammen, und man muß dauernd aufpassen, daß die 
Leute nicht mit "oh wir können hier aber dieses und da das Feature noch 
nutzen" nach und nach eine wilde Migration zu vollem C++ hinlegen.

Gab ja mal die Initiative "Embedded C++", die das hätte adressieren 
sollen, aber die ist irgendwie auch in sich zusammengesackt.

Und ja, man kann natürlich bequem z.B. einen UART als Objekt 
instanzieren, und man kann auch leicht unterschiedliche Klassen für 
prinzipiell ähnliche Interfaces einfach handhaben. Eleganter als in C 
jedenfalls. Das sind aber letztlich völlig irrelevante 
Implementationsdetails.

Deswegen sind auch Saks' technische Argumente für C++ nett, aber genauso 
irrelevant. Und nein, "die sind eben alle komplett doof" ist nicht die 
Antwort, auch wenn da technisch gesehen was dran ist. Wenn man sachlich 
korrekte Argumente hat, die trotzdem nicht überzeugen, könnte es aber 
auch daran liegen, daß man das falsche Problem diskutiert.

Wo es allerdings echt aufhört, das ist überall da, wo man eine GUI 
braucht. Das ist in C der Horror (BTDT), weil die OOP-Unterstützung sehr 
bescheiden ist.

Autor: Axel S. (a-za-z0-9)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nop schrieb:
> Vincent H. schrieb:
>
>> Laut Dan Saks sinkt die Trendlinie von embedded C++
>> software, während die von C steigt.
>
> Was auch kein Wunder ist, denn das Hauptproblem von C++ wird mit jedem
> neuen Standard schlimmer: Der Sprachumfang. Zwar werden neue Sachen
> eingeführt, die mehr Annehmlichkeiten bringen, aber da in der realen
> Welt die überwiegende Zahl der Projekte die Erweiterung bestehender
> Software ist, muß man dann immer mehr Standards beherrschen.

Nein.

Nur weil man mehr Dinge darf, muß man man nicht mehr Dinge müssen. 
Mehr Auswahl zu haben ist ein Privileg, kein Hemmnis.

Es wurde breits vorher gesagt: jedes Programm, das nur ein einziges C++ 
Feature benutzt (sei es ein neuer Typ wie bool oder Namespaces oder 
Überladung eines Funktionsnamens per unterschiedlicher Signatur) ist am 
Ende ein C++ Programm (auch wenn es sonst zu 99.5% reines C ist) und 
gehört auf der Waage auf die "C++" Seite.

Bis auf ein paar wenige verbohrte C Extremisten dürfte jeder 
Programmierer derart niedrig hängende Früchte vom C++ Baum mit Vergnügen 
annehmen, zumal wenn der C++ Compiler in Form des g++ frei Haus kommt. 
Auf den (beklagenswerten, IMHO) Architekturen, die zwar einen C- aber 
keinen C++ Compiler haben, mag das natürlich anders aussehen.

Autor: Sven B. (scummos)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Axel S. schrieb:
>> Was auch kein Wunder ist, denn das Hauptproblem von C++ wird mit jedem
>> neuen Standard schlimmer: Der Sprachumfang. Zwar werden neue Sachen
>> eingeführt, die mehr Annehmlichkeiten bringen, aber da in der realen
>> Welt die überwiegende Zahl der Projekte die Erweiterung bestehender
>> Software ist, muß man dann immer mehr Standards beherrschen.
>
> Nein.
>
> Nur weil man mehr Dinge darf, muß man man nicht mehr Dinge müssen.
> Mehr Auswahl zu haben ist ein Privileg, kein Hemmnis.

Ich bin ein Anhänger von C++, aber die immense Komplexität der Sprache 
muss man schon als Argument gelten lassen.
Wobei es stimmt: die neuen Standards machen vieles sehr viel einfacher 
und führen vor allem dazu, dass man kein wahnsinnig tiefgreifendes 
Verständis der alten Features braucht, weil es mit den neuen oft sehr 
intuitiv anders geht. Insgesamt ist es von Anwenderseite leichter mit 
C++17 ein bestimmtes Ziel zu erreichen als mit C++03, und darauf kommt 
es an.


> Es wurde breits vorher gesagt: jedes Programm, das nur ein einziges C++
> Feature benutzt (sei es ein neuer Typ wie bool oder Namespaces oder
> Überladung eines Funktionsnamens per unterschiedlicher Signatur) ist am
> Ende ein C++ Programm (auch wenn es sonst zu 99.5% reines C ist) und
> gehört auf der Waage auf die "C++" Seite.

Naja. Ein Programm ist ein C++-Programm wenn es gegen die C++ Runtime 
linkt. Das ist eigentlich zumindest auf Desktop-Systemen relativ 
einfach.

: Bearbeitet durch User
Autor: Nop (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Axel S. schrieb:

> Nur weil man mehr Dinge darf, muß man man nicht mehr Dinge müssen.
> Mehr Auswahl zu haben ist ein Privileg, kein Hemmnis.

Siehe Vorposting, darauf bin ich eingegangen.

> Es wurde breits vorher gesagt: jedes Programm, das nur ein einziges C++
> Feature benutzt

Das ist formal C++, ja, aber ich finde es albern, ein C-Programm mit 
"bool" als C++ zu werten. Das kann man machen, wenn man Statistiken 
frisieren will.

> zumal wenn der C++ Compiler in Form des g++ frei Haus kommt.

http://embeddedgurus.com/stack-overflow/2010/02/is-gcc-a-good-compiler/

Autor: Nop (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Dan Saks: "I'm giving C++ talks to an embedded audience and the curious 
thing, it is a confession, is I've never built an industrial strength 
embedded system out of C++."

WTF?

Autor: olaf (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
> Deswegen auch z.B. die ganzen E-Ings als SW-Entwickler mit HW-Wissen,
> und mehr als C geht da einfach nicht.

Das ist SEHR richtig. Will nur leider kaum einer verstehen. Dazu kommt 
noch was anderes. Gerade die Leute in einer Firma die bei komplexen 
Themen die unabdingbare Erfahrung haben, sind auch bereits alte Saecke. 
Die wollen einfach keine weitere Programmiersprache lernen und erst 
recht nicht sowas abstraktes.
Dazu kommt noch das im Embedded bereich auch SEHR viel alter Code in C 
weiter verwendet werden muss. Es ist dann einfacher man macht den Bubis 
frisch von der Uni klar das sie entweder C lernen und verwenden oder 
sich nach einen anderen Job umkucken sollten.

> Es wird noch schlimmer, weil C++ so ziemlich alles ermöglicht. Das heißt
> im Umkehrschluß aber auch, daß es nicht ausreicht, wenn man weiß, welche
> Dinge man wozu gebrauchen kann, sondern man muß für embedded auch noch
> wissen, was exakt unter der Haube abläuft. Das ist keine Abstraktion,
> das ist obfuscation.

Auch dem kann ich nur zustimmen. Hilfreich waere vielleicht ein C-- oder 
einen Compilerswitch der C++ alles verbietet was im Embeddedbereich 
alles nicht sinnvoll ist. Aehnlich diesen Misra Tools die normalen C ja 
bereits verschiedenes abgewoehnen.

> Und wieso wird das nicht groß diskutiert? Weil keiner sich traut
> zuzugeben, ein mäßiger Programmierer zu sein.

Oh ja! Da ist sehr richtig. Hinzu kommt noch das es gerade im 
Programmierbereich viele alte Quereinsteiger gibt die bereits oben in 
der Nahrungskette angekommen sind. Dem tritt man nicht einfach so 
gegegen sein virtuelles Schienbein. :-)

>  Gab ja mal die Initiative "Embedded C++", die das hätte adressieren
> sollen, aber die ist irgendwie auch in sich zusammengesackt.

Wusste ich noch garnicht das es soetwas gibt. Schade wenn daraus nichts 
wird. Kannst du mal einen Link liefern?

Ich denke auch das es dringend an der Zeit ist C durch was besseres 
abzuloesen. Aber die normative Kraft des Faktischen verhindert das noch 
sehr erfolgreich und das wird sicher auch noch 5-10Jahre so bleiben.

Olaf

Autor: Wilhelm M. (wimalopaan)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
olaf schrieb:
>> Deswegen auch z.B. die ganzen E-Ings als SW-Entwickler mit HW-Wissen,
>> und mehr als C geht da einfach nicht.
>
> Das ist SEHR richtig. Will nur leider kaum einer verstehen. Dazu kommt
> noch was anderes. Gerade die Leute in einer Firma die bei komplexen
> Themen die unabdingbare Erfahrung haben, sind auch bereits alte Saecke.
> Die wollen einfach keine weitere Programmiersprache lernen und erst
> recht nicht sowas abstraktes.

Das ist dann ja eine Bankrott-Erklärung der Embedded-Branche!!!

> Dazu kommt noch das im Embedded bereich auch SEHR viel alter Code in C
> weiter verwendet werden muss. Es ist dann einfacher man macht den Bubis
> frisch von der Uni klar das sie entweder C lernen und verwenden oder
> sich nach einen anderen Job umkucken sollten.

Auch das halte ich für eine fatale Strategie: man gibt ja auch nicht die 
Devise aus, nur noch alte µC einzusetzen: 8-Bit ist so schön einfach, 
man kann den Leuten keine 32-Bit zumuten.

>> Und wieso wird das nicht groß diskutiert? Weil keiner sich traut
>> zuzugeben, ein mäßiger Programmierer zu sein.

Und das wäre dann in einem Unternehmen eine Frage der 
Personalentwicklung.

> Oh ja! Da ist sehr richtig. Hinzu kommt noch das es gerade im
> Programmierbereich viele alte Quereinsteiger gibt die bereits oben in
> der Nahrungskette angekommen sind. Dem tritt man nicht einfach so
> gegegen sein virtuelles Schienbein. :-)

Da fällt mir der Handwerkerspruch ein: soll es vernünftig werden oder 
solls der Chef machen ;-)

>>  Gab ja mal die Initiative "Embedded C++", die das hätte adressieren
>> sollen, aber die ist irgendwie auch in sich zusammengesackt.

Ja, weil sie bei old-school C++ stehen geblieben ist. Aber ich denke, 
dass sich da noch etwas tun wird.

: Bearbeitet durch User
Autor: Stefanus F. (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Das ist dann ja eine Bankrott-Erklärung der Embedded-Branche!!!

Unterschätze nicht, wie schnell junge Leute lernen können. Wenn es 
wirklich nötig ist, kommen die auch ganz schnell auf die Grundlagen.

Für uns (jetzt 40 Jährige) war es damal noch sehr mühsam, Programmieren 
zu lernen. Man hatte nur sehr begrenzten Zugang zu Literatur und 
Hardware. Doch heute haben wir das Internet. Vergesst das nicht.

> denn das Hauptproblem von C++ wird mit jedem
> neuen Standard schlimmer: Der Sprachumfang

Dann müsste Java längst tot sein. Es wächst sehr viel schneller, als 
C++, und ist dennoch eine sehr häufig angewendete Programmiersprache im 
Enterprise Umfeld.

Auch ich meine: man muss ja nicht alles benutzen, was geht.

Autor: chris (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Schorsch schrieb:
> Wie sieht es auf der Mikrocontroller Ebene aus?
>
> Welche Gründe gibt es hier für den Einsatz von C oder C++.

Erstmal das Datenblatt lesen und verstehen!!!!!

Denn das würde hier 90% der sinnlosen Fragen der Fragenden selbst 
beantworten.

Viele glauben das man einfach ein paar Bibliotheken zusammen verknüft 
das man dann programmmieren kann aber spätestens wenn es um 
Timerfunktionen, Interrupt,ADC's oder einfach nur berechnen geht, fehlts 
den meisten an Grundlagen. Da hilft auch die Beste Bibliothek nichts!!!!

Die Sprache hängt davon ab was du willst und kannst und wieviel Flash 
man zur Verfügung hat.

Autor: H.J.Gebhardt (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Sheeva P. schrieb:
> C++ einfach mal lernt

Ein Widerspruch in sich.
Der Umfang gängiger Lehrbücher spricht Bände.

Sven B. schrieb:
> aber die immense Komplexität der Sprache
> muss man schon als Argument gelten lassen.

Im Grunde stranguliert sich die Sprache mit ihrem ausufernden Umfang als 
Empfehlung für einfache MCs selbst. Die pure Zahl der Möglichkeiten 
macht es immer schwerer, die optimale = sparsame und performanteste 
Umsetzung zu finden. Flexibel hat als Kehrseite leider Gottes komplex. 
Allein die Vorgabe des TO, MCs mit viel Flash und RAM zu betrachten, 
mildert die Notwendigkeit sparsamer Codierung hier etwas. Da man mit dem 
32Bit MC aber gleichzeitig selbst mehr Hardware-Komplexität geliefert 
bekommt verbietet sich hier, was bei einfachen 8Bittern immer noch und 
weiter naheliegt: Asm ohne viel administrativen Aufwand in Sprache und 
Programmiermittel-Setup.

Autor: Wilhelm M. (wimalopaan)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stefan U. schrieb:
>> Das ist dann ja eine Bankrott-Erklärung der Embedded-Branche!!!
>
> Unterschätze nicht, wie schnell junge Leute lernen können. Wenn es
> wirklich nötig ist, kommen die auch ganz schnell auf die Grundlagen.

Ich glaube, da hast Du mich falsch verstanden.

Ich glaube eher, dass diejenigen, die hier manchmal so gegen C++ 
wettern, nicht die Zeit oder den Willen haben, über den Tellerrand 
hinaus zu sehen.

Beides ist gleichermaßen schlecht. Eine Firma, die ihren MA nicht die 
Zeit, etc. gibt, neue Technologien (was auch immer) zu erlernen, ist 
schlecht beraten. Und MA die nicht den Willen dazu haben, sich weiter zu 
entwicklen (gerade in einem Unternehmen dieser Branche) sollten ihre 
Position wechseln.

Insgesamt wäre das eine Argumentation nach dem Motto: das haben wir 
schon immer so gemacht. Und deswegen bleibt es so. Dies ist aber 
kurzsichtig.

Und ich hoffe, dass das dann doch in den meisten Firmen nicht so ist ;-)

: Bearbeitet durch User
Autor: Wilhelm M. (wimalopaan)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
H.J.Gebhardt schrieb:
> Sheeva P. schrieb:
>> C++ einfach mal lernt
>
> Ein Widerspruch in sich.
> Der Umfang gängiger Lehrbücher spricht Bände.

Das Problem vieler Lehrbücher (vor allem aus dem europäischem Raum) ist, 
das es den Autoren meistens nicht darum geht, dem Lernenden zu helfen, 
sondern darzustellen, was für ein toller Hecht der Autor ist! Das ist im 
angloamerikanischen Bereich oft anders (leider sind die Bücher von 
Bjarne da eine Ausnahme: aber er hatte auch nicht das Ziel, ein Lehrbuch 
zuschreiben, sondern sein Baby darzustellen).

Autor: olaf (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
> Für uns (jetzt 40 Jährige) war es damal noch sehr mühsam, Programmieren
> zu lernen. Man hatte nur sehr begrenzten Zugang zu Literatur und
> Hardware. Doch heute haben wir das Internet. Vergesst das nicht.

Interessanterweise sehe ich den Nachwuchs eher im Nachteil. Das Internet 
liefert zuviel Ablenkung vom wesentlichen und gleichzeitig ist die 
Hardware und die Projekte so komplex geworden das sie ein einzelner 
nicht mehr so eben komplett durchschauen kann. Von Leuten die glauben 
dann Libaries zusammenzuklauben zu koennen damit alles einfach wird 
garnicht zu reden.
Es fehlt dann oft an Grundlagen um sich im komplexen sicher zu bewegen.

> Die Sprache hängt davon ab was du willst und kannst und wieviel Flash
> man zur Verfügung hat.

Was vielen nicht so klar ist, Effizienz ist bei Embedded sehr viel 
entscheidender als in anderen Bereichen. Wenn mein Produkt mit Batterie 
nur halb so lange laeuft wie bei der Konkurrenz bin ich tod. Und wenn 
man einen Prozessor verwenden muss der eine Nummer leistungsfaehiger ist 
als notwendig ist dann happert es dieses Jahr an den Bonuszahlungen. .-)

Olaf

Autor: Hans (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
olaf schrieb:
>> Die Sprache hängt davon ab was du willst und kannst und wieviel Flash
>> man zur Verfügung hat.
>
> Was vielen nicht so klar ist, Effizienz ist bei Embedded sehr viel
> entscheidender als in anderen Bereichen.

Ja, schon, aber...

Effizient ist zu 99% davon abhängig ob man geeignete Algorithmen 
verwendet hat. Was hilft ein Speedup von 3 wenn man alles statt in Java, 
in ASM geschrieben hat, wenn man mit geeigneteren Algorithmen einen 
Faktor 20 haben könnte.


73

Autor: Nop (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Wilhelm M. schrieb:

> Das ist dann ja eine Bankrott-Erklärung der Embedded-Branche!!!

Nein, sondern es ist die Einsicht, daß das Coding gegenüber dem 
Domänenwissen zweitrangig ist.

> Auch das halte ich für eine fatale Strategie: man gibt ja auch nicht die
> Devise aus, nur noch alte µC einzusetzen: 8-Bit ist so schön einfach,
> man kann den Leuten keine 32-Bit zumuten.

Mit C(++) besteht da, abgesehen von ein paar Datentypen, kein 
wesentlicher Unterschied.

> Und das wäre dann in einem Unternehmen eine Frage der
> Personalentwicklung.

Auf gut deutsch: Geld bezahlen, ohne dafür einen entsprechenden 
Gegenwert zu bekommen. Mal abgesehen davon, daß OOP-Code anderer Leute 
auch deutlich schwerer nachzuvollziehen ist. Prozeduralen Code kann man 
einfach sequentiell lesen. Man muß in C++ nicht OOP machen, aber das ist 
eines der Hauptfeatures gegenüber C.

> Ja, weil sie bei old-school C++ stehen geblieben ist. Aber ich denke,
> dass sich da noch etwas tun wird.

Nein. Eher wird man die ganze C-Familie hinter sich lassen, und erst 
recht C++. C++ ist deswegen so absurd, weil es abwärtskompatibel zu C 
sein mußte. Das war damals korrekt, weil es sich sonst gar nicht hätte 
etablieren können, aber der Preis war hoch.


Wilhelm M. schrieb:

> Und MA die nicht den Willen dazu haben, sich weiter zu
> entwicklen (gerade in einem Unternehmen dieser Branche) sollten ihre
> Position wechseln.

Man sollte sich lieber überlegen, ob man diese Arbeit wirklich in C++ 
stecken will. Besonders vor dem Hintergrund, daß das reine Coding 
zusehends ausgelagert wird, etwa nach Osteuropa.

Zudem ist auch nicht jede neue Technologie tatsächlich sinnvoll, und nur 
weil sie neu ist, heißt das nicht, daß sie deswegen auch besser wäre.


Und dann haben wir da noch die ganz radikale Argumentation vom Schlage 
Torvalds, daß C allein schon den Vorteil hat, Leute fernzuhalten, die 
lieber C++ wollen. Klingt polemisch, ist es auch, aber die versachlichte 
Aussage ist zumindest bedenkenswert:

Mehr Abstraktion bedeutet nicht automatisch besser. C hat gegenüber 
Assembler wegen der Abstraktion viele Vorteile, aber die Dosis macht das 
Gift. Es ist eine Abwägung. Mit "je mehr Abstraktion, desto besser" holt 
man sich letztlich "architecture astronauts" an Bord, wie Joel Spolsky 
das nennt, und genau DIE fernzuhalten ist durchaus eine Idee, besonders 
embedded.

Wenn Leute es total wesentlich finden, daß man einen UART als Objekt 
instanzieren kann, dann sind das einfach fragwürdige Prioritäten, bzw. 
"l'art pour l'art".

Autor: Peter D. (peda)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Hans schrieb:
> Effizient ist zu 99% davon abhängig ob man geeignete Algorithmen
> verwendet hat.

Das ist auch meine Erfahrung. Die eigentliche Entwicklungsarbeit findet 
vor dem Coden statt.
Microoptimierung eines bestehenden Ablaufes bringt wenig bis gar nichts, 
kostet aber unendlich viel Zeit.

Autor: Wilhelm M. (wimalopaan)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Nop schrieb:

> Und dann haben wir da noch die ganz radikale Argumentation vom Schlage
> Torvalds, daß C allein schon den Vorteil hat, Leute fernzuhalten, die
> lieber C++ wollen. Klingt polemisch, ist es auch, aber die versachlichte
> Aussage ist zumindest bedenkenswert:

Das drehe ich um: C++ hat den Vorteil, Leute fernzuhalten, die lieber C 
wollen ;-)

> Mehr Abstraktion bedeutet nicht automatisch besser.

Es kommt auf die Abstraktionen an, die man gewählt hat.

> C hat gegenüber
> Assembler wegen der Abstraktion viele Vorteile

(s.o.)

>, aber die Dosis macht das
> Gift. Es ist eine Abwägung. Mit "je mehr Abstraktion, desto besser"

es geht nicht um mehr Abstraktion, sondern um bessere Abstraktionen!

Autor: PeterPan (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
H.J.Gebhardt schrieb:
> Ein Widerspruch in sich.
> Der Umfang gängiger Lehrbücher spricht Bände.
>
> Im Grunde stranguliert sich die Sprache mit ihrem ausufernden Umfang als
> Empfehlung für einfache MCs selbst. Die pure Zahl der Möglichkeiten
> macht es immer schwerer, die optimale = sparsame und performanteste
> Umsetzung zu finden. Flexibel hat als Kehrseite leider Gottes komplex.
> Allein die Vorgabe des TO, MCs mit viel Flash und RAM zu betrachten,
> mildert die Notwendigkeit sparsamer Codierung hier etwas. Da man mit dem
> 32Bit MC aber gleichzeitig selbst mehr Hardware-Komplexität geliefert
> bekommt verbietet sich hier, was bei einfachen 8Bittern immer noch und
> weiter naheliegt: Asm ohne viel administrativen Aufwand in Sprache und
> Programmiermittel-Setup.

Haha viel Geschwurbel und alles zu komplex außer 8-Bit und Assembler, 
ein klassischer Moby. Ein Blinder spricht von Farben...

Autor: PeterPan (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Nop schrieb:
> Wilhelm M. schrieb:
>
>> Das ist dann ja eine Bankrott-Erklärung der Embedded-Branche!!!
>
> Nein, sondern es ist die Einsicht, daß das Coding gegenüber dem
> Domänenwissen zweitrangig ist.

Wenn man keine besonderen Anforderungen an die Software hat und die so 
mal nebenbei macht dann ja. Ansonsten nö. Als Softwareentwickler ist man 
Architekt und Handwerker zugleich. Was ist ein Maurer wert, der sein 
Handwerk nicht versteht?

Nop schrieb:
>> Und das wäre dann in einem Unternehmen eine Frage der
>> Personalentwicklung.
>
> Auf gut deutsch: Geld bezahlen, ohne dafür einen entsprechenden
> Gegenwert zu bekommen. Mal abgesehen davon, daß OOP-Code anderer Leute
> auch deutlich schwerer nachzuvollziehen ist. Prozeduralen Code kann man
> einfach sequentiell lesen. Man muß in C++ nicht OOP machen, aber das ist
> eines der Hauptfeatures gegenüber C.

Also mich reizen ja eher so Features wie Typsicherheit, Referenzen, 
Templates (generische Datenstrukturen in C sind ein Krampf), 
constexpr...

Nop schrieb:
>> Ja, weil sie bei old-school C++ stehen geblieben ist. Aber ich denke,
>> dass sich da noch etwas tun wird.
>
> Nein. Eher wird man die ganze C-Familie hinter sich lassen, und erst
> recht C++. C++ ist deswegen so absurd, weil es abwärtskompatibel zu C
> sein mußte. Das war damals korrekt, weil es sich sonst gar nicht hätte
> etablieren können, aber der Preis war hoch.

Ja da hast du allerdings recht, wenn diese ganze C Scheiße nicht noch in 
C++ drin wäre... Vor allem sieht man immer wieder Leute, die ein Mix aus 
C und C++ Erzeugen, C Style casts, raw pointer würg.

Autor: Wilhelm M. (wimalopaan)
Datum:

Bewertung
4 lesenswert
nicht lesenswert
PeterPan schrieb:

> Also mich reizen ja eher so Features wie Typsicherheit, Referenzen,
> Templates (generische Datenstrukturen in C sind ein Krampf),
> constexpr...

Genau!
Um die SW-Entwicklung effizient und sicher zu machen, braucht man ein 
reiches, domänenspezifisches Typsystem - und genau das ist eine der 
Stärken von C++. Plakativ könnte man sagen: entweder compiliert das 
Stück SW und dann ist es auch korrekt, oder es kompiliert erst gar 
nicht. Weniger plakativ: man spart sich eine Menge Debugging.

OOP im engeren Sinn ist eine mögliche Variante, wie ich in C++ 
programmieren kann, aber nicht die einzige. OOP im engeren Sinn möchte 
ich auf µC vielleicht auch gar nicht. Da sind doch eher andere Sachen im 
Spiel wie eben ein reiches Typsystem und Generizität.

> Ja da hast du allerdings recht, wenn diese ganze C Scheiße nicht noch in
> C++ drin wäre... Vor allem sieht man immer wieder Leute, die ein Mix aus
> C und C++ Erzeugen, C Style casts, raw pointer würg.

Ja, leider! Das liegt aber eben auch wieder daran, dass nicht jeder 
wirklich willens ist oder die Zeit bekommt/hat, neue Paradigmen zu 
erlernen.

: Bearbeitet durch User
Autor: Johannes S. (jojos)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
H.J.Gebhardt schrieb:
> Allein die Vorgabe des TO, MCs mit viel Flash und RAM zu betrachten,
> mildert die Notwendigkeit sparsamer Codierung hier etwas.

Was ist den 'viel'? Ich benutze C++ für einen Cortex-M0 mit 16 oder 32 
kB Flash und 8 kB RAM und das läuft wunderbar. Der ist schon wesentlich 
komplexer als ein 8051, aber gerade deshalb möchte ich komplexe 
Peripherie einfach z.B. mit 'spi.frequency = 1e6;' einstellen und nicht 
eine Latte von Registern setzen die auch noch bei jedem µC anders ist.

Das Zerlegen eines Problemes in Objekte und Interaktionen zwischen 
diesen ist allerdings schon ein Schritt den man lernen und verstehen 
muss. Wir (2 Vorreiter) haben auch mal versucht einer Gruppe von knapp 
ein Dutzend C-Programmiern da C++ zu lehren, das ist auch kläglich 
gescheitert bzw. schnell eingeschlafen.

Autor: Carl D. (jcw2)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wilhelm M. schrieb:
> PeterPan schrieb:
>
>> Also mich reizen ja eher so Features wie Typsicherheit, Referenzen,
>> Templates (generische Datenstrukturen in C sind ein Krampf),
>> constexpr...
.
> Genau!
> Um die SW-Entwicklung effizient und sicher zu machen, braucht man ein
> reiches, domänenspezifisches Typsystem - und genau das ist eine der
> Stärken von C++. Plakativ könnte man sagen: entweder compiliert das
> Stück SW und dann ist es auch korrekt, oder es kompiliert erst gar
> nicht. Weniger plakativ: man spart sich eine Menge Debugging.
.
> OOP im engeren Sinn ist eine mögliche Variante, wie ich in C++
> programmieren kann, aber nicht die einzige. OOP im engeren Sinn möchte
> ich auf µC vielleicht auch gar nicht. Da sind doch eher andere Sachen im
> Spiel wie eben ein reiches Typsystem und Generizität.
>
>> Ja da hast du allerdings recht, wenn diese ganze C Scheiße nicht noch in
>> C++ drin wäre... Vor allem sieht man immer wieder Leute, die ein Mix aus
>> C und C++ Erzeugen, C Style casts, raw pointer würg.
>
> Ja, leider! Das liegt aber eben auch wieder daran, dass nicht jeder
> wirklich willens ist oder die Zeit bekommt/hat, neue Paradigmen zu
> erlernen.

Peter/Wilhelm das will doch keiner hier hören. Wie schon Dan Saks sagte: 
"If you argue, you loose".
Ich nutze lieber die Vorteile, die die meisten hier nicht verstehen 
(wollen). Und genieße es von ihren Problemen mit den Programmiersprachen 
für Männer zu lesen.

Autor: Wilhelm M. (wimalopaan)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Carl D. schrieb:

> Peter/Wilhelm das will doch keiner hier hören. Wie schon Dan Saks sagte:
> "If you argue, you loose".
> Ich nutze lieber die Vorteile, die die meisten hier nicht verstehen
> (wollen). Und genieße es von ihren Problemen mit den Programmiersprachen
> für Männer zu lesen.

Ja, das weiß ich ... und gebe es trotzdem nicht auf ;-)
(Und warte auf die Einlassungen von c-hater ...)

Autor: Carl D. (jcw2)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Johannes S. schrieb:
> Peripherie einfach z.B. mit 'spi.frequency = 1e6;' einstellen und nicht

Und wenn dann da noch
spi.frequency = 1e6_HZ;
steht, dann ist das sogar dokumentiert.
Stichwort "User Definded Literals".

Autor: Carl D. (jcw2)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Wilhelm M. schrieb:
> Carl D. schrieb:
>
>> Peter/Wilhelm das will doch keiner hier hören. Wie schon Dan Saks sagte:
>> "If you argue, you loose".
>> Ich nutze lieber die Vorteile, die die meisten hier nicht verstehen
>> (wollen). Und genieße es von ihren Problemen mit den Programmiersprachen
>> für Männer zu lesen.
>
> Ja, das weiß ich ... und gebe es trotzdem nicht auf ;-)
> (Und warte auf die Einlassungen von c-hater ...)

C++ nicht zu hassen, ist ein Vorteil, den man nicht aus der Hand geben 
sollte.

Autor: Sheeva P. (sheevaplug)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vincent H. schrieb:
> Sheeva P. schrieb:
>> Eigentlich ist C++ "in",
>
> Leider nein. Laut Dan Saks sinkt die Trendlinie von embedded C++
> software, während die von C steigt.
>
> Siehe hier:
> Youtube-Video "CppCon 2016: Dan Saks “extern c: Talking to C Programmers about C++”"

Danke für den Link, den ich allerdings schon kannte. Dans Artikel [1] 
zum Thema zeichnet IMHO ein wesentlich differenzierteres Bild; vor allem 
die Tatsache, daß zwischen 2004 und 2005 das Wording der Befragung nur 
recht geringfügig geändert wurde, und diese geringfügigen Änderungen 
offenbar gravierende Auswirkungen auf die Ergebnisse gehabt hat, läßt 
mich an der Aussagekraft dieser Umfragen zweifeln.

Auch sonst halte ich solche Umfragen einzelner Seiten für nicht 
besonders zuverlässig. Webseiten haben üblicherweise ein bestimmtes 
Publikum, und davon antwortet dann wiederum nur jener Teil auf solche 
Umfragen, die sich davon angesprochen fühlen. Daß dieser Einfluß 
vorhanden ist, zeigen die großen Sprünge zwischen 2004 und 2005. Und 
noch ein anderes Beispiel weist in diese Richtung: den der Verbreitung 
von Android geschuldeten Erfolg von Java bilden die Ergebnisse der 
Umfrage überhaupt nicht ab, was vermutlich daran liegt, daß die Seite 
nur wenige Android-Java-Entwickler anzieht. Von den in solchen Umfragen 
immer wieder anzutreffenden Manipulationen, gerade im Umfeld von 
kontroversen Themen wie Programmiersprachen, will ich dabei gar nicht 
erst anfangen... ;-)

Aber dann ist da noch die Frage, wie einzelne Entwickler die Fragen der 
Umfrage im Zusammenhang mit ihrem Code verstehen. Nehmen wir einen Code, 
der nur wenige kleine Features von C++ wie Referenzen und / oder Scoped 
Enums benutzt und ansonsten wie C-Code organisiert und aufgebaut ist: 
ist das dann noch ein C-Code oder bereits ein C++-Code? Ich persönlich 
neige zwar zur zweiten, halte aber beide Antworten für völlig legitim -- 
zumal diese Umfrage ja nach der "primären" Sprache fragt.

Hinzu kommt, daß C++ seine Stärken erst mit zunehmender Projektgröße 
voll entfalten kann. Embedded-Projekte sind ihrer Natur nach aber häufig 
eher kleine Projkte, bei denen viele besonders positive Eigenschaften 
von C++ kaum zum Tragen kommen -- und das ist dann auch der Grund dafür, 
daß sich C++ in diesem Umfeld nicht so schnell durchzusetzen vermag, wie 
es das ja schon in der Anwendungsentwicklung getan hat.

Andererseits weisen diverse Entwicklungen wie "Embedded-C++" und 
Coding-Standards wie Misra-C++ ja eindeutig darauf hin, daß es ein 
Interesse und einen Bedarf für C++ auf Embedded-Geräten gibt. Die 
steigende Verbreitung von ARM-Prozessoren mit ihrer höheren Komplexität, 
die sich mit C++ besser beherrschen läßt, wird sicherlich ihr Übriges 
zur Verbreitung von C++ im Embedded-Umfeld dazu tun. Insofern bin ich 
ausgesprochen zuversichtlich, daß sich C++ auch im Embedded-Umfeld 
durchsetzen wird. Es dauert nur etwas länger -- na und? ;-)

[1] 
http://www.embedded.com/electronics-blogs/programming-pointers/4372180/Unexpected-trends

Autor: Wilhelm M. (wimalopaan)
Datum:

Bewertung
4 lesenswert
nicht lesenswert
Carl D. schrieb:
> Johannes S. schrieb:
>> Peripherie einfach z.B. mit 'spi.frequency = 1e6;' einstellen und nicht
>
> Und wenn dann da noch
>
spi.frequency = 1e6_HZ;
> steht, dann ist das sogar dokumentiert.
> Stichwort "User Definded Literals".

Und mit eine paar templates dazu, kann man sich ein ganze SI-Einheiten 
System bauen ... dann kann man auch:
auto d1 = 10_km
auto d2 = 1_mm
auto d = d1 + d2;

auto s = 1_m;
auto t = 1_sec;

Velocity = s/t;

schreiben, und keine Sonde fliegt mehr am Mars vorbei ;-)

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
4 lesenswert
nicht lesenswert
Wilhelm M. schrieb:
> und keine Sonde fliegt mehr am Mars vorbei ;-)

Dafür schlägt sie wegen einer unhandled exception hart auf der
Oberfläche auf. :-))

<SCNR>

Autor: Wilhelm M. (wimalopaan)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Jörg W. schrieb:
> Wilhelm M. schrieb:
>> und keine Sonde fliegt mehr am Mars vorbei ;-)
>
> Dafür schlägt sie wegen einer unhandled exception hart auf der
> Oberfläche auf. :-))

LOL

Autor: Carl D. (jcw2)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Wilhelm M. schrieb:
>
> auto d1 = 10_km
> auto d2 = 1_mm
> auto d = d1 + d2;
> 
> auto s = 1_m;
> auto t = 1_sec;
> 
> Velocity = s/t;
> 
>
> schreiben, und keine Sonde fliegt mehr am Mars vorbei ;-)

oder gar
>
> auto d1 = 10_km;
> auto d2 = 1_miles;
> auto d = d1 + d2;
> 

falls auch zukünftig noch Forschung zwischen Metric- und 
Imperial-Ländern stattfindet.
(BTW, das Semikolon ist immer noch Pflicht. C++ != JavaScript)

Autor: Carl D. (jcw2)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg W. schrieb:
> Wilhelm M. schrieb:
>> und keine Sonde fliegt mehr am Mars vorbei ;-)
>
> Dafür schlägt sie wegen einer unhandled exception hart auf der
> Oberfläche auf. :-))
>
> <SCNR>

Das geht aber besser in Ada. Da kommt die Sonde gar nicht aus der 
Erdanziehung raus.

Autor: Sheeva P. (sheevaplug)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
H.J.Gebhardt schrieb:
> Sheeva P. schrieb:
>> C++ einfach mal lernt
>
> Ein Widerspruch in sich.
> Der Umfang gängiger Lehrbücher spricht Bände.

Was für ein lahmes Pseudoargument. Es gibt auch sehr schlanke Lehrbücher 
für C++, zum Beispiel diese: [1,2,3]. Alle unter 500 Seiten; wenn man 
bedenkt, daß das Standardwerk für C [4], das ja bekanntlich ein Subset 
von C++ ist, 274 Seiten hat, wird klar, wie niedrig die Schwelle 
tatsächlich ist -- und insbesondere für erfahrene C-Entwickler, die die 
C-bezogenen Teile eines C++-Lehrbuches bereits kennen. Und daß man auch 
über C sehr umfangreiche Bücher schreiben kann, zeigt [5] mit 1190 
Seiten.

Allerdings halte ich es gerade in diesem Bereich für vollkommen 
unsinnig, vom Umfang eines Lehrbuches auf die Komplexität einer Sprache 
zu schließen. Mit mehr Beispielcode läßt sich der Seitenumfang so eines 
Buches wunderbar aufblähen, während die Autoren nach Seitenzahl bezahlt 
werden... ;-)

[1] 
https://www.amazon.de/C-Objektorientiertes-Programmieren-von-Anfang/dp/3499600773

[2] 
https://www.amazon.de/C-eine-Einf%C3%BChrung-Ulrich-Breymann/dp/3446446370

[3] https://www.amazon.de/f%C3%BCr-Dummies-Stephen-R-Davis/dp/3527710981

[4] 
https://www.amazon.de/Programming-Language-Prentice-Hall-Software/dp/0131103628

[5] 
https://www.amazon.de/von-bis-umfassende-Handbuch-Computing/dp/3836214113

Autor: Torsten R. (Firma: robitzki.de) (torstenrobitzki)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Nop schrieb:
> Das ist formal C++, ja, aber ich finde es albern, ein C-Programm mit
> "bool" als C++ zu werten. Das kann man machen, wenn man Statistiken
> frisieren will.

Weil es scheinbar noch niemanden aufgefallen ist: bool ist ein relativ 
schlechtes Beispiel, weil es in C seit fast 20 Jahren einen bool gibt 
(stdbool.h)!

Das man den in fast keiner professionellen Library findet (genau so 
wenig wie `const` oder Variablen mit eingeschränktem Scope) zeigt das 
Dilema sehr schön auf: Im Embedded Bereich, ist die Software nach wie 
vor zweitrangig und wird häufig von Laien geschrieben. Dagegen ist auch 
nichts zu sagen, solange der Umfang und die Komplexität das erlaubt.

Vielleicht müssen wir uns einfach daran gewöhnen, dass sich auch der 
Embedded-Bereich viel weiter auffächert. In Bereichen mit relativ 
geringen SW-Anteil wird die Software vom E-Techniker mitgemacht. Dieser 
legt dann Wert darauf, dass die zu verwendende Werkzeuge leicht zu 
erlernen sind (das wäre dann z.B. C und vor allem eine GUI).

In Bereichen, wo die Software einen sehr hohen Anteil an der Entwicklung 
ausmacht, wird arbeitsteilig gearbeitet. Der E-Techniker macht die 
Hardware und SW-Techniker macht die Software.

Das klingt doch versöhnlich, oder? ;-)

mfg Torsten

Autor: Nop (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Torsten R. schrieb:

> Das man den in fast keiner professionellen Library findet (genau so
> wenig wie `const` oder Variablen mit eingeschränktem Scope)

Also const nehme ich andauernd bei der Übergabe von Pointern an eine 
Funktion, wenn die Funktion nur lesend zugreifen soll. Das ist Teil von 
selbstdokumentierendem Code, weil man dann schon am Prototypen sieht, 
daß die Funktion den Datenbereich nicht ändert, ohne daß man sich erst 
durch den Code wühlen müßte.

Und eingeschränkten Scope nutze ich auch gerne. Globals wenigstens 
file-static (wenn nicht gleich function-static) machen erhöht die 
Übersicht. Ebenso bei Funktionen, die mache ich auch static, wann immer 
es geht. Dann weiß man sofort, daß eine Interface-Änderung nur in 
derselben Datei zu Konsequenzen führen kann.

Lokale Variablen, das ist Geschmackssache; wenn die Funktion so lang 
wird, daß man 1000 Zeilen später nochmal irgendwas mit einer Variablen 
macht, dann ist nicht der Scope das Problem, sondern die Funktion ist zu 
lang. Solche Probleme sieht man aber schnell mit Tools wie 
Sourcemonitor.

> Dagegen ist auch
> nichts zu sagen, solange der Umfang und die Komplexität das erlaubt.

Die Komplexität liegt ja auch weniger in den einzelnen Knoten als 
vielmehr in deren Zusammenspiel. Witzigerweise ist das eigentlich OOP, 
weil die einzelnen Controller SELBER die "Objekte" darstellen. Die 
Methoden sind dann die Firmware, die Getter/Setter sind die Nachrichten 
auf den IO-Schnittstellen. :-)

Autor: Yalu X. (yalu) (Moderator)
Datum:

Bewertung
4 lesenswert
nicht lesenswert
Sheeva P. schrieb:
> H.J.Gebhardt schrieb:
>> Sheeva P. schrieb:
>>> C++ einfach mal lernt
>>
>> Ein Widerspruch in sich.
>> Der Umfang gängiger Lehrbücher spricht Bände.
>
> Was für ein lahmes Pseudoargument. Es gibt auch sehr schlanke Lehrbücher
> für C++, zum Beispiel diese: [1,2,3].

Der Umfang irgendwelcher Bücher liefert kaum eine Aussage über die
Komplexität einer Programmiersprache, da sie oft unvollständig,
ausschweifend oder beides sind. Ein besseres Maß ist IMHO der Umfang der
jeweiligen Normen oder – wo es keine gibt – die Referenzdokumente der
Sprachentwickler), und zwar nur der reinen Sprachbeschreibung ohne die
Bibliotheken.

Ich habe hier einmal ein paar Zahlen zusammengestellt:

Sprache  Umfang/S   Art des Dokuments
———————————————————————————————————————————————
C11        180      ISO-Norm
C++14      411      ISO-Norm
C# 2.0     443      ECMA-Norm
C# 5.0     468      Sprachreferenz
C# 7.1      ?       kein geschlossenes Dokument
Java 8     699      Sprachreferenz
Haskell    153      Sprachreferenz
———————————————————————————————————————————————

Gemessen an der Mächtigkeit von C++ im Vergleich zu C empfinde ich den
Textumfang durchaus noch als akzeptabel. Immerhin scheinen C# und erst
recht Java noch fetter zu sein.

Dass eine überaus mächtige Sprache nicht komplex sein muss, zeigt
Haskell, dessen Dokumentationsumfang sogar C unterbietet. Es gibt
allerdings etliche bereits implementierte und häufig genutzte
Spracherweiterungen, die voraussichtlich im nächsten Referenzdokument
offiziell gemacht werden, so dass dieses evtl. die 200-Seitenmarke
überschreiten wird.

Autor: Eric B. (beric)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Torsten R. schrieb:
> weil es in C seit fast 20 Jahren einen bool gibt
> (stdbool.h)!

Wenn das bool in einer Header-Datei definiert wird / werden muss, dann 
ist es kein Teil der Sprache sondern eine Erweiterung. Die Dateitypen 
char, int usw, die sind in der Sprache definiert.

> Im Embedded Bereich, ist die Software nach wie
> vor zweitrangig und wird häufig von Laien geschrieben.

Wie bitte? Es gibt einen Riesenindustrie für Embedded Software und ich 
würde nicht behaupten wollen das seien alles Laien die da Software 
schreiben!

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Torsten R. schrieb:
> Im Embedded Bereich, ist die Software nach wie vor zweitrangig und wird
> häufig von Laien geschrieben.

Das ist doch Unfug: wenn die Leute dafür bezahlt werden, sind sie
per definitionem erstmal Profis und keine Amateure.

Dass es keine Informatiker sind, ist wiederum normal: Informatiker
sind von der Ausbildung her nicht unbedingt sehr anwendungsnah, dafür
können sie prima Algorithmen und Frameworks bauen.  Das heißt natürlich
nicht, dass nicht auch Informatiker sich in die „niederen Ebenen“
einarbeiten könnten, aber genauso gut darfst du den nicht-SW-Ings
zugestehen, dass sie ausreichend Handwerkszeug für die Programmierung
erlernen können, um darin firm zu sein.

Mit Programmiersprachen hat das alles nicht viel zu tun, dafür in
der Wirtschaft oft umsomehr mit äußeren Randbedingungen: irgendwer muss
das Geld ja bezahlen.  Nicht jedes Projekt entsteht immer von Grund auf
neu, und wenn es erstmal besteht, ist man eben in der Wahl der
Programmiersprache nicht mehr so frei, wie man sich das wünschen würde.
Da kann man noch so gut die Vorzüge von C++ gegenüber C kennen, es wird
einem kein $KUNDE freiwillig die Zeit bezahlen, das völlig neu
aufzusetzen, solange das existierende die gewünschten Ergebnisse bringt
und weniger Aufwand für ihn kostet.

: Bearbeitet durch Moderator
Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Eric B. schrieb:

> Wenn das bool in einer Header-Datei definiert wird / werden muss, dann
> ist es kein Teil der Sprache sondern eine Erweiterung. Die Dateitypen
> char, int usw, die sind in der Sprache definiert.

_Bool ist seit knapp 20 Jahren genauso in der Sprache definiert.

Nur bool konnte man nicht nachträglich reindefinieren, da es eine
Inkompatibilität bestehender Programme bedeutet hätte, denn dieser Name
war zuvor im application name space.  Daher entsteht die Äquivalenz
von _Bool nach bool nur dann, wenn man <stdbool.h> inkludiert.

Autor: Wilhelm M. (wimalopaan)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Jörg W. schrieb:
> Eric B. schrieb:
>
>> Wenn das bool in einer Header-Datei definiert wird / werden muss, dann
>> ist es kein Teil der Sprache sondern eine Erweiterung. Die Dateitypen
>> char, int usw, die sind in der Sprache definiert.
>
> _Bool ist seit knapp 20 Jahren genauso in der Sprache definiert.

Ups, zu spät mit der Antwort:

http://en.cppreference.com/w/c/types/boolean

Autor: Torsten R. (Firma: robitzki.de) (torstenrobitzki)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
Eric B. schrieb:
> Torsten R. schrieb:
>> weil es in C seit fast 20 Jahren einen bool gibt
>> (stdbool.h)!
>
> Wenn das bool in einer Header-Datei definiert wird / werden muss, dann
> ist es kein Teil der Sprache sondern eine Erweiterung. Die Dateitypen
> char, int usw, die sind in der Sprache definiert.

Ja, genau so etwas meine ich: Da schreiben Leute Software, denen nicht 
einmal klar ist, dass zu einer Sprache eben nicht nur eine Menge 
reservierter Wörter gehört, sondern in erheblichen Umfang auch 
Bibliotheken (der C buldin Type lautet übrigens _Bool). Die sind Teil 
der Sprache und werden auch ganz genau in der Definition der Sprache 
beschrieben.

Da schreibt sich jeder seine eigenen header mit typedefs für u8, u16 
usw. statt sich einmal einen Nachmittag hin zu setzen und zu gucken, was 
die Sprache den schon so an Typen definiert und damit, mit jedem 
Compiler frei Haus geliefert wird.

Autor: Torsten R. (Firma: robitzki.de) (torstenrobitzki)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Jörg W. schrieb:
> Torsten R. schrieb:
>> Im Embedded Bereich, ist die Software nach wie vor zweitrangig und wird
>> häufig von Laien geschrieben.
>
> Das ist doch Unfug: wenn die Leute dafür bezahlt werden, sind sie
> per definitionem erstmal Profis und keine Amateure.

Damit hast Du natürlich recht. Ich relativiere das mal:

Im Embedded Bereich, gibt es Projekte in denen bietet die Software nach 
wie vor nicht den Hauptnutzen eines Produkts und wird von Kollegen 
geschrieben, deren Hauptfokus wo anders liegt.

Autor: Chris F. (chfreund) Benutzerseite
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Ich verwende am liebsten C++, auf kleineren µC oder wenn die 
Entwicklungsumgebung/runtime-lib besser ist auch C und inline-ASM. 
Bisher hat das immer gereicht.

Reinen Assembler könnte ich auch verwenden, aber das ist für mich in 
100% der Praxisfälle unnötig und wäre eher etwas sportliches.

Autor: Nop (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ach ja, zum Thema "C nur für kleine Projekte geeignet": Wenn man den 
Linuxkernel mit weit über 20 Mio Codezeilen als "klein" betrachtet, dann 
ja.

Es ist auch nicht so, wie gerne dargestellt, daß Torvalds kein C++ mag, 
daß er zu blöd dazu gewesen wäre und was sonst noch gerne behauptet 
wird. Vielmehr ist das Interessante, daß genau die Vorteile von C++ auch 
als Nachteile gesehen werden können.

Geht ja schon bei Operator-Überladung los, wo jedes Pluszeichen einen 
riesigen Rattenschwanz bedeuten kann, aber das sieht man beim lokalen 
Review halt nicht auf den ersten Blick. Die ganze Compilermagic ist 
nicht nur ein Argument für C++, sondern auch eines dagegen.

"Muß man nicht nutzen?" Ja, in Kleinprojekten, wenn man der Einzige ist. 
Bei Großprojekten ist der garantierte Weg, wie etwas tatsächlich nicht 
genutzt wird, daß die Sprache es nicht kann.

Und wenn Dann Saks mit "wer argumentiert, verliert" ankommt: diese 
Haltung kenne ich ansonsten von religiösen Missionaren, die nicht 
nachvollziehen können, wieso ihre Argumente nicht ankommen. Wenn sowas 
dann auch noch von jemandem kommt, der selber kein einziges embedded 
Industrieprojekt realisiert hat, wird es vollends lächerlich.

Autor: Sheeva P. (sheevaplug)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Nop schrieb:
> Ach ja, zum Thema "C nur für kleine Projekte geeignet": Wenn man den
> Linuxkernel mit weit über 20 Mio Codezeilen als "klein" betrachtet, dann
> ja.

Wobei der Linux-Kernel zum allerallergrößten Teil aus Treibern besteht 
und insofern trotz > 20 Millionen LOC kein typisches "großes Projekt" 
ist.

> Es ist auch nicht so, wie gerne dargestellt, daß Torvalds kein C++ mag,

Doch, genau so ist es.

> daß er zu blöd dazu gewesen wäre

Es ist ihm zu einfach, die STL und die Boost-Libraries sind ihm nicht 
stabil genug (als wäre das ein Argument gegen die Sprache, und nicht 
eines gegen die Stabilität der besagten Bibliotheken und 
Implementierungen), ... er mag C++ einfach nicht und sucht sich daher 
"Argumente" dagegen, damit er seinen Aussagen wenigstens den Anschein 
einer sachlichen Begründung geben kann. Obendrein ist es ja nicht so, 
als ob Linus Torvalds der einzig wahre Programmiergott und seine 
Ansichten die einig wahre Wahrheit seien; viele andere bekannte und 
nicht minder fähige und talentierte Entwickler sehen das vollkommen 
anders als Linus. Insofern ist es nichts weiter als eine ganz besonders 
lächerliche Variante des "argumentum ad populum", sich in diesem Punkt 
ausschließlich auf Linus' Aussagen zu berufen.

> Vielmehr ist das Interessante, daß genau die Vorteile von C++ auch
> als Nachteile gesehen werden können.
>
> Geht ja schon bei Operator- Überladung los, wo jedes Pluszeichen einen
> riesigen Rattenschwanz bedeuten kann

Nein, eigentlich nicht. Bessere Codeorganisation und 
Wiederverwendbarkeit sind schwer meßbar, aber dennoch harte Kriterien 
und eindeutige Vorteile. Richtig ist allerdings auch, daß C++ -- vor 
allem wegen der geforderten Abwärtskompatibilität mit C -- einige 
Altlasten mit sich herumschleppt.

Die Überladung von Operatoren und Operationen ist ein sehr sinnvolles 
und mächtiges Feature, und wie jedes mächtige Feature kann sie auch 
mißbraucht werden. Aber das ist dann kein Argument gegen das Feature, 
sondern erstens eines gegen den, der sie mißbraucht, und zweitens gegen 
seinen Code. Denn schlechten, unlesbaden und unverständlichen Code kann 
man in jeder Sprache schreiben -- die Perlianer haben mit dem 
"Obfuscated Perl Contest" sogar einen Kunstwettbewerb daraus geschaffen.

> Und wenn Dann Saks mit "wer argumentiert, verliert" ankommt: diese
> Haltung kenne ich ansonsten von religiösen Missionaren, die nicht
> nachvollziehen können, wieso ihre Argumente nicht ankommen.

Naja, "jeden Vorteil kann man auch als Nachteil sehen" ist jedenfalls 
auch nicht allzu weit davon entfernt. ;-)

Außerdem sagt Dan nicht: "wer argumentiert, verliert", sondern: "wenn Du 
streitest, verlierst Du". Es ist beliebt, aber trotzdem ein 
Mißverständnis, das englische "to argue" mit dem deutschen 
"argumentieren" gleichzusetzen; korrekterweise wäre die Übersetzung von 
"to argue" eher "streiten". Zudem ignorierst Du den Satz, den Dan davor 
sagt: "when it comes to persuasion", mithin: "wenn wir über Überzeugung 
reden", "wenn es um Überzeugung geht" oder "wenn es darum geht, jemanden 
zu überzeugen". Zusammen heißt das, was Dan sagt, also grob übersetzt: 
"wenn Du jemanden überzeugen willst und mit ihm streitest, dann 
verlierst Du". Und wenn Du diese Aussage als religiöse Missionierung 
verstehst, solltest Du Dir nochmal das kleine Einmaleins der 
Kommunikation zu Gemüte führen. ;-)

> Wenn sowas dann auch noch von jemandem kommt, der selber kein einziges
> embedded Industrieprojekt realisiert hat, wird es vollends lächerlich.

Er hat kein einziges Industrieprojekt mit C++ realisiert -- verstehst Du 
den Unterschied zu Deiner Aussage?

Autor: H.J.Gebhardt (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Wer das große Instrumentarium von C++ bzw. objektorientierte 
Herangehensweisen ohnehin schon (richtig, d.h. ohne Systemressourcen zu 
verschleudern) beherrscht kann sie ja durchaus auch durchgängig für MC 
verwenden. Da spricht doch gar nichts dagegen. Aber: Daß sich Zeit und 
Mühe aber lohnen es sich extra dafür aneignen zu wollen würde ich 
entschieden bestreiten. Einfache Controller sind mit einfachen Sprachen 
besser bedient.

Sheeva P. schrieb:
> und wie jedes mächtige Feature kann sie auch
> mißbraucht werden. Aber das ist dann kein Argument gegen das Feature,
> sondern erstens eines gegen den, der sie mißbraucht, und zweitens gegen
> seinen Code.

Ganz klar, bei soviel technokratischer Sichtweise ist natürlich immer 
der programmierende Mensch "schuld", nie die Programmiersprache. Daß 
Werkzeuge als solche auch ihre Qualitäten haben, daß sie je nach 
Anwendungsfall sinnvoller oder weniger sinnvoll, passend oder 
überdimensioniert sein können kommt Dir wohl nicht in den Sinn?

Sheeva P. schrieb:
> Codeorganisation und
> Wiederverwendbarkeit

bieten mehr oder weniger alle Programmiersprachen. Wenn hier "höheres" 
C++ definitiv noch ausgefeiltere Möglichkeiten bietet dann ist das 
höchstens für große Projekte, große MC und Prozessoren überhaupt von 
Belang.

Autor: Stefanus F. (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Wer das große Instrumentarium von C++ bzw. objektorientierte
> Herangehensweisen ohnehin schon ... beherrscht kann sie ja
> durchaus auch durchgängig für MC verwenden.
> Da spricht doch gar nichts dagegen.

Dagegen spricht, dass µC in der Regel keine so ausgefuchste 
Speicherverwaltung haben, wie die ausgewachsenen Server Betriebssysteme. 
In Kombination mit knapp bemessenem RAM kommst man schnell zu einem 
Out-Of-Memory wegen Heap-Fragmentierung.

Also "durchgängig" ist hier nicht passend. Man kann C++ auf 
Mikrocontrollern verwenden, aber nur eingeschränkt.

: Bearbeitet durch User
Autor: Wilhelm M. (wimalopaan)
Datum:

Bewertung
4 lesenswert
nicht lesenswert
Stefan U. schrieb:
>> Wer das große Instrumentarium von C++ bzw. objektorientierte
>> Herangehensweisen ohnehin schon ... beherrscht kann sie ja
>> durchaus auch durchgängig für MC verwenden.
>> Da spricht doch gar nichts dagegen.
>
> Dagegen spricht, dass µC in der Regel keine so ausgefuchste
> Speicherverwaltung haben, wie die ausgewachsenen Server Betriebssysteme.
> In Kombination mit knapp bemessenem RAM kommst man schnell zu einem
> Out-Of-Memory wegen Heap-Fragmentierung.
>
> Also "durchgängig" ist hier nicht passend. Man kann C++ auf
> Mikrocontrollern verwenden, aber nur eingeschränkt.

Ob man C++ nutzt oder nicht hat aber nur eingeschränkt etwas mit 
Heap-Verwaltung zu tun: Objektorientierung im engeren Sinn (v.a. 
Laufzeitpolymorphie) ist sicher auf µC mit wenig RAM unangebracht.

Aber das ist ja nur ein kleiner Teil: C++ ist eine multi-paradigmen 
Sprache. Ich kann objektorientiert (im weiteren Sinn) programmieren ohne 
dyn. Speicherverwaltung, ich kann generisch programmieren, funktional 
(zu einem gewissen Teil), ein reiches Typsystem verwenden, ...

Autor: Nop (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Sheeva P. schrieb:

> Wobei der Linux-Kernel zum allerallergrößten Teil aus Treibern besteht
> und insofern trotz > 20 Millionen LOC kein typisches "großes Projekt"
> ist.

Sehe ich nicht als relevantes Argument.

> Doch, genau so ist es.

Ja gut, insofern habe ich mich da lax ausgedrückt: es ist nicht so, daß 
er es aus Geschmacksgründen oder emotionalen Befindlichkeiten heraus 
nicht mag, sondern er lehnt es aus guten Gründen ab.

> Insofern ist es nichts weiter als eine ganz besonders
> lächerliche Variante des "argumentum ad populum"

Ach? Wieso kam diese Kritik nicht bereits bei den Videos von Dan Saks? 
Der übrigens seiner eigenen Aussage nach kein einziges embedded 
Industrieprojekt gemacht hat? Während Torvalds mit dem Linuxkernel und 
auch mit Git immerhin relevante Projekte vorzeigen kann?

> Nein, eigentlich nicht.

Doch, weil man Reviews dann nicht mehr lokal machen kann, denn C++ ist 
sehr kontextabhängig. Jedes popelige Pluszeichen kann diverse Additionen 
in Schleifen bedeuten. Jeder elementare Operator ist möglicherweise ein 
Funktionsaufruf, aber man sieht an der Stelle nicht, welche Funktion 
aufgerufen wird. Dazu muß man sich dann erstmal durch weitere Dateien 
wühlen.

Es geht dabei nichtmal darum, den Plus-Operator etwa zum Zwecke einer 
Division mißbräuchlich zu überladen (das tut real niemand), sondern daß 
es bei bestimmungsgemäßem Gebrauch schon problematisch wird.

> Denn schlechten, unlesbaden und unverständlichen Code kann
> man in jeder Sprache schreiben -- die Perlianer haben mit dem
> "Obfuscated Perl Contest" sogar einen Kunstwettbewerb daraus geschaffen.

Den gibt's auch für C. Für C++ nicht, weil obfuscated Code in C++ zu 
schreiben keine Kunst darstellt, man braucht bloß normalen Produktivcode 
zu nehmen. ;-)

> Naja, "jeden Vorteil kann man auch als Nachteil sehen" ist jedenfalls
> auch nicht allzu weit davon entfernt. ;-)

Finde ich nicht. Es ist halt eine völlig andere Sichtweise. Sie erklärt 
auch, wieso das Anpreisen von noch mehr Features nicht überzeugt, im 
Gegenteil.

> "wenn Du jemanden überzeugen willst und mit ihm streitest, dann
> verlierst Du".

Thx, guter Absatz.

> Er hat kein einziges Industrieprojekt mit C++ realisiert -- verstehst Du
> den Unterschied zu Deiner Aussage?

Äh, ja, sorry, das meinte ich auch. Natürlich hat er Industrieprojekte 
realisiert, allerdings in Assembler und C.

Autor: Nop (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Stefan U. schrieb:

> Dagegen spricht, dass µC in der Regel keine so ausgefuchste
> Speicherverwaltung haben, wie die ausgewachsenen Server Betriebssysteme.
> In Kombination mit knapp bemessenem RAM kommst man schnell zu einem
> Out-Of-Memory wegen Heap-Fragmentierung.

Man muß Objekte ja nicht mit new anlegen, man kann sie auch statisch 
anlegen.

Analog dazu muß man in C ja auch keine Speicherbereiche via malloc 
holen, man kann sie auch als Arrays anlegen. Dynamische 
Speicherallozierung von Dingen, die viel Speicher brauchen, aber nie 
zugleich anfallen, löse ich in C über den Stack. Dann fragmentiert das 
nie.

Autor: Wilhelm M. (wimalopaan)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Nop schrieb:

> Doch, weil man Reviews dann nicht mehr lokal machen kann, denn C++ ist
> sehr kontextabhängig. Jedes popelige Pluszeichen kann diverse Additionen
> in Schleifen bedeuten. Jeder elementare Operator ist möglicherweise ein
> Funktionsaufruf, aber man sieht an der Stelle nicht, welche Funktion
> aufgerufen wird. Dazu muß man sich dann erstmal durch weitere Dateien
> wühlen.

Das ist schlicht Unsinn!

Was ist der Unterschied bei einem Review von
list += item;

zu
list_add(list, item);
?

In beiden(!) Fällen muss ich mir ggf. die Operation ansehen, egal wie 
sie syntaktisch geschrieben wurde.

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wilhelm M. schrieb:
> Was ist der Unterschied bei einem Review von
> list += item;
> zu
> list_add(list, item);
> ?

Beim zweiten Fall bin ich mir 100%ig sicher, dass ich mir die Operation 
anschauen muss. Im ersten Fall könnte man bei flüchtigem Blick und in 
der Annahme, dass es sich um eine simple Addition handelt - darüber 
hinwegsehen.

Autor: Wilhelm M. (wimalopaan)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Frank M. schrieb:
> Wilhelm M. schrieb:
>> Was ist der Unterschied bei einem Review von
>> list += item;
>> zu
>> list_add(list, item);
>> ?
>
> Beim zweiten Fall bin ich mir 100%ig sicher, dass ich mir die Operation
> anschauen muss. Im ersten Fall könnte man bei flüchtigem Blick und in
> der Annahme, dass es sich um eine simple Addition handelt - darüber
> hinwegsehen.

Man könnte ... klar.
Aber dann hat man keine Ahnung von C++. Und das gilt für jede Sprache: 
jede hat ihre Eigenheiten, die man kennen muss.
Man könnte auch grundsätzlich "übersehen", dass bestimmte Algorithmen 
aufwändiger sind als andere ...

Autor: Nop (Gast)
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
Wilhelm M. schrieb:

> In beiden(!) Fällen muss ich mir ggf. die Operation ansehen, egal wie
> sie syntaktisch geschrieben wurde.

Nein. In C weißt Du im ersten Fall, daß es eine einfache Addition ist, 
weil es keine Überladung gibt.

Wenn man bedenkt, wie man z.B. im Linuxkernel Patches reviewed, nämlich 
vorzugsweise differentiell und lokal, weil man sonst zu gar nichts mehr 
kommt - dann ist klar, wieso ein expliziter Funktionsaufruf wesentlich 
leserlicher ist. Der heißt nämlich "Achtung, hier könnte eine 
Performance-Falle lauern".

Es geht nicht darum, daß man das bei C++ nicht weiß, sondern daß C++ die 
ausgeführte Operation vor dem Leser versteckt. Abstraktion wird zu 
Obfuscation, und es spart keine Zeit, sondern kostet mehr Zeit, sich da 
durchzuwühlen.

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
Wilhelm M. schrieb:
> Man könnte ... klar. Aber dann hat man keine Ahnung von C++. Und das
> gilt für jede Sprache: jede hat ihre Eigenheiten, die man kennen muss.

Ja, natürlich. Aber theoretisch müsstest Du Dir bei einem Code-Review 
jede theoretisch mögliche Überlagerung eines Operators anschauen, selbst 
wenn es sich um die Addition zweier simpler Integer-Variablen handelt. 
Das macht es "anstrengender". Und damit erhöht sich die Gefahr, dass man 
etwas übersieht. Genau das meinte ich mit "darüber hinwegsehen".

Bei einem expliziten Funktionsaufruf bin ich als Code-Reviewer 
gezwungen, mir diese anzuschauen. Da gibt es keinen Zweifel.

Aber ich will C++ nicht schlechtreden. Es ist schon ein geniales 
Werkzeug. Angesichts der vielen Erweiterungen und potentiellen 
Möglichkeiten, die in den letzten 20 Jahren hinzugekommen sind, kann ich 
mir aber gut vorstellen, dass ein nicht unerheblicher Teil von 
Programmierern damit schlichtweg "überfordert" ist.

P.S.
Ich selbst habe vor 20 Jahren in einem größeren Programmierer-Team für 
ein großes Telekommunikationsunternehmen (jeder kennt die Farbe) 
gearbeitet, wo es um die Rechnungsstellung der Netze zwischen den 
Mobilfunkunternehmen ging. Klare Vorgabe war C++. Aber programmiert 
wurde tatsächlich alles in C. Bis auf das Schlüsselwort "class" wurde da 
nichts weiter von den eigentlichen C++-Mitteln genutzt. Der Grund war 
einfach: Die Leute konnten es nicht besser.

: Bearbeitet durch Moderator
Autor: Chris D. (myfairtux) (Moderator) Benutzerseite
Datum:

Bewertung
3 lesenswert
nicht lesenswert
Wilhelm M. schrieb:
> Man könnte ... klar.
> Aber dann hat man keine Ahnung von C++. Und das gilt für jede Sprache:
> jede hat ihre Eigenheiten, die man kennen muss.
> Man könnte auch grundsätzlich "übersehen", dass bestimmte Algorithmen
> aufwändiger sind als andere ...

Das sehe ich ähnlich.

Das Überladen von Operatoren empfand ich schon damals als wirklich 
hilfreich und einen großen Fortschritt gegenüber C.

Es gestaltet den Code deutlich besser lesbar und entspricht viel mehr 
der menschlichen Intuition.

obstkorb = apfel + birne + orange + zitrone

finde ich viel klarer als ein Wust aus Funktionsaufrufen.

Meiner Meinung nach sinkt dadurch die Fehleranfälligkeit.

Dass man aber natürlich vor dem Betrachten von C++-Code davon gehört 
haben sollte, dass es sowas gibt, sollte selbstverständlich sein.

Im übrigen gab es schon damals Editoren, die solche überladenen 
Operatoren (und nur solche) farblich gekennzeichnet haben, so dass sie 
einem sofort ins Auge fallen. Ich nehme mal an, dass man heute mit einem 
Klick darauf direkt zu der Überladung geführt wird.

"Hab ich nich' gesehen" lasse ich also nicht gelten ;-)

: Bearbeitet durch Moderator
Autor: Wilhelm M. (wimalopaan)
Datum:

Bewertung
4 lesenswert
nicht lesenswert
Chris D. schrieb:

> Es gestaltet den Code deutlich besser lesbar und entspricht viel mehr
> der menschlichen Intuition.
>
> obstkorb = apfel + birne + orange + zitrone
>
> finde ich viel klarer als ein Wust aus Funktionsaufrufen.
>
> Meiner Meinung nach sinkt dadurch die Fehleranfälligkeit.

Diese Betrachtungsweise legt nahe, das das Überladen der Operatoren nur 
"syntaktischer Zucker" sei.
Dem ist aber nicht so. Ein wesentlicher Aspekt bei C++ ist ja die 
weitgehende Gleichbehandlung von primitiven DT und UDT. Daher brauche 
ich die Operatorüberladung bei generischem Code zwingend (das motiviert 
auch, warum ich freie Funktionen brauche).

Autor: Chris D. (myfairtux) (Moderator) Benutzerseite
Datum:

Bewertung
3 lesenswert
nicht lesenswert
Wilhelm M. schrieb:
> Diese Betrachtungsweise legt nahe, das das Überladen der Operatoren nur
> "syntaktischer Zucker" sei.
> Dem ist aber nicht so. Ein wesentlicher Aspekt bei C++ ist ja die
> weitgehende Gleichbehandlung von primitiven DT und UDT. Daher brauche
> ich die Operatorüberladung bei generischem Code zwingend (das motiviert
> auch, warum ich freie Funktionen brauche).

Stimmt.

Danke für die wichtige Ergänzung - bin wohl doch schon zu lange aus dem 
C++-Geschäft raus :-/

Aber ich ändere das gerade wieder:
Beitrag "Buchempfehlung? Aktuelles C++-Buch für C-Programmierer mit C++-Grundlagen" :-)

Autor: Nop (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was allerdings in C holprig ist, sind generische Datenstrukturen. Der 
Library-Quicksort muß für jeden Vergleich einen Funktionsaufruf machen, 
der nichtmal inline-fähig ist. C-Qsort ist daher ziemlich lahm. Man kann 
das natürlich abstellen, indem man einfach eine explizite Funktion 
schreibt, was aber mehr Codegröße bewirkt, wenn es mehr als eine 
Datenstruktur zu sortieren gibt.

In C++ ist das kein Problem. Man braucht keine expliziten Funktionen 
mehrfach hinschreiben und hat trotzdem nicht diesen indirekten 
Funktionsaufruf für die Vergleiche.

Frage: Angenommen, man will denselben Sortieralgorithmus auf zwei 
verschiedene Datenstrukturen anwenden in C++, was fällt bei C++ dann am 
Ende in Maschinencode raus? Sind das auch separate Funktionen, also von 
der Codegröße her dasselbe wie mit C und separatem Hinschreiben?

Autor: Wilhelm M. (wimalopaan)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nop schrieb:
> Was allerdings in C holprig ist, sind generische Datenstrukturen. Der
> Library-Quicksort muß für jeden Vergleich einen Funktionsaufruf machen,
> der nichtmal inline-fähig ist. C-Qsort ist daher ziemlich lahm. Man kann
> das natürlich abstellen, indem man einfach eine explizite Funktion
> schreibt, was aber mehr Codegröße bewirkt, wenn es mehr als eine
> Datenstruktur zu sortieren gibt.
>
> In C++ ist das kein Problem. Man braucht keine expliziten Funktionen
> mehrfach hinschreiben und hat trotzdem nicht diesen indirekten
> Funktionsaufruf für die Vergleiche.
>
> Frage: Angenommen, man will denselben Sortieralgorithmus auf zwei
> verschiedene Datenstrukturen anwenden in C++, was fällt bei C++ dann am
> Ende in Maschinencode raus? Sind das auch separate Funktionen, also von
> der Codegröße her dasselbe wie mit C und separatem Hinschreiben?

Du wetterst in Deinen obigen Beiträgen so gegen C++, aber hast Dich 
offenbar noch nicht wirklich damit befasst!
Schau mal bei template-Instanziierung nach ;-)

Autor: Nop (Gast)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
Wilhelm M. schrieb:

> Du wetterst in Deinen obigen Beiträgen so gegen C++, aber hast Dich
> offenbar noch nicht wirklich damit befasst!

Damit, was am Ende in Maschinencode rausfällt, in der Tat nicht, nein. 
Das wäre mir auch zu mühsam, weil mir dabei genau die ganze zusätzliche 
Abstraktion in den Weg gelegt wird. Sobald mir das Ergebnis auf 
Maschinencode-Ebene relevant ist, nehme ich in der Praxis lieber eine 
Sprache, die mir da weniger Versteckspiel aufzwingt.

Aber halt aus Interesse.

Autor: Wilhelm M. (wimalopaan)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nop schrieb:
> Wilhelm M. schrieb:
>
>> Du wetterst in Deinen obigen Beiträgen so gegen C++, aber hast Dich
>> offenbar noch nicht wirklich damit befasst!
>
> Damit, was am Ende in Maschinencode rausfällt, in der Tat nicht, nein.

Das brauchst Du auch nicht: Du musst nur generell wissen, was eine 
template-Instanziierung ist. So ähnlich wie Du Dich fragen musst, was 
eine Funktion list_add() wohl macht. Unterschied: das eine passiert zur 
Laufzeit, das andere zur Compilezeit.

Die template-Engine ist übrigens turing-vollständig ... mit 
Metafunktionen kann man also beliebig rechnen, wobei 
constexpr-Funktionen das sehr schön vereinfachen.

Autor: Nop (Gast)
Datum:

Bewertung
-4 lesenswert
nicht lesenswert
Wilhelm M. schrieb:

> Das brauchst Du auch nicht: Du musst nur generell wissen, was eine
> template-Instanziierung ist.

Hm ja, komplexere, u.a. auf den Datentyp parametrierbare Macros. Mit der 
overhead-freien Variante wäre die Codegröße dann dieselbe.

Autor: olaf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> entschieden bestreiten. Einfache Controller sind mit einfachen Sprachen
> besser bedient.

Das sehe ich auch so. Ich wuerde sogar fast sagen das dies unbestritten 
ist. Aber es wird bald keine einfachen Controller mehr geben. Zum Teil 
schon jetzt, spaetestens aber mit dem naechsten Generationssprung wirst 
du relativ dicke Controller fuer unter einem Euro bekommen.
Und als professioneller Entwickler wirst du zu der Erkenntnis kommen das 
du einen erheblichen Teil deiner Arbeit mit komplexen Controllern 
verbringst. Dann koenntest du die dafuer notwendigen Kenntnisse und 
Faehigkeiten auch fuer die wenigen Projekte mit schlichten Controllern 
verwenden.
Es zahlt sich also schon aus ueber die Zeit nach dem einfachen C 
nachzudenken.

Olaf

Autor: Eric B. (beric)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Torsten R. schrieb:
> Ja, genau so etwas meine ich: Da schreiben Leute Software, denen nicht
> einmal klar ist, dass zu einer Sprache eben nicht nur eine Menge
> reservierter Wörter gehört, sondern in erheblichen Umfang auch
> Bibliotheken

Gottseidank schreibe ich schon lange keine Software mehr :-P

> (der C buldin Type lautet übrigens _Bool).

I stand corrected, danke für die Aufklärung. Meine einzige Ausrede ist, 
dass ich in einem beruflichen Umfeld arbeite, dass technisch noch etwa 
20 Jahre hinterher hüpft. C99 wird damit wohl erst in 2019 erlaubt 
werden ;-)

> Die sind Teil der Sprache und werden auch ganz genau in der Definition
> der Sprache beschrieben.

Hm, da bin ich andere Meinung. Auch wenn in der Standard eine ganze 
Latte an Bibiliotheken beschrieben wird, die mitgeliefert werden soll, 
sind sie nicht Teil der Sprache: ich muss als Programmierer dem Compiler 
mitteilen, (über #include o.Ä.)  dass er bitteschön irgendwelche Typen, 
Funktionen usw. interpretieren soll.
Wenn ich dir sage, dass du überall wo "Blobfutzl" steht "Weissbier" 
lesen sollst, könen wir über "Blobfutzl" reden. Das macht es aber nicht 
Teil der deutsche Sprache.

> Da schreibt sich jeder seine eigenen header mit typedefs für u8, u16
> usw. statt sich einmal einen Nachmittag hin zu setzen und zu gucken, was
> die Sprache den schon so an Typen definiert und damit, mit jedem
> Compiler frei Haus geliefert wird.

Ohhh, die Diskussion hatte ich schon mal bei der Arbeit. Wir dürften 
da tatsächlich die Standard-Headers nicht benutzen, da man ja nie 
wissen konnte wie da drinnen Gott-weiss-was-alles definiert war. Also 
mussten tatsächlich im Haus geschriebene Headers mit eigenen, zum Teil 
sogar fehlerhafte typedefs fur u8 und co eingesetzt werden.

Autor: Nop (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
olaf schrieb:

> Aber es wird bald keine einfachen Controller mehr geben.

Doch, wird es, allein schon wegen Stromverbrauch, die nie gering genug 
sein kann.

Außerdem gibt es heute bereits komplexe Controller mit viel mehr Wums, 
das sind die Cortex-A. Die könnten von Kosten und Stromverbrauch her auf 
künftig auf die Werte eines heutigen M0 sinken per technischem 
Fortschritt.

Da ist C++ aber auch keine Lösung, die programmiert man gar nicht mehr 
bare metal. Das geht praktisch einfach nicht. Echtzeit kann man sich 
dann allerdings auch abschminken. Und genau deswegen wird es auch 
weiterhin einfache Controller geben, weil es einen Industriebedarf gibt, 
daß man leicht reviewbaren Code innerhalb der Anforderungen erstellen 
kann.

Immerhin wird sogar der 8051 auch heute noch eingesetzt.

Autor: Nop (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nop schrieb:

> Doch, wird es, allein schon wegen Stromverbrauch, DER nie gering genug
> sein kann.

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Eric B. schrieb:
> Auch wenn in der Standard eine ganze Latte an Bibiliotheken beschrieben
> wird, die mitgeliefert werden soll, sind sie nicht Teil der Sprache

Zumindest in C sind sie das: du darfst im eigenen Code beispielsweise
eben keine eigene printf-Implementierung haben, sondern wenn da
"printf" steht, ist das gemäß Standard gemeint, und es ist dem Compiler
überlassen, wie er das interpretiert.  Ein typisches Beispiel dafür
ist, dass GCC aus
printf("foo\n");

ein
puts("foo");

macht, um den Interpretations-Overhead für den Formatstring zu 
vermeiden.

Damit ist die Standardbibliothek aus Sicht der Sprach-Normierer ein
Teil der Sprache.  Alles zusammen ist dann “the implementation”.

Autor: olaf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Doch, wird es, allein schon wegen Stromverbrauch, die nie gering genug
> sein kann.

Gerade wegen dem Stromverbrauch setze ich ziemlich komplexe und dicke 
Controller weil weil sich da alles abschalten laesst und nur 
gelegentlich eingeschaltet wird und die aktive Zeit moeglich kurz sein 
kann und man halt sehr viel mehr skalieren kann.

Olaf

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
olaf schrieb:
> Gerade wegen dem Stromverbrauch setze ich ziemlich komplexe und dicke
> Controller weil weil sich da alles abschalten laesst

Nur der Leckstrom nicht … und der steigt mit sinkenden Strukturgrößen.

Autor: Torsten R. (Firma: robitzki.de) (torstenrobitzki)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Wilhelm M. schrieb:
>> Man könnte ... klar. Aber dann hat man keine Ahnung von C++. Und das
>> gilt für jede Sprache: jede hat ihre Eigenheiten, die man kennen muss.
>
> Ja, natürlich. Aber theoretisch müsstest Du Dir bei einem Code-Review
> jede theoretisch mögliche Überlagerung eines Operators anschauen, selbst
> wenn es sich um die Addition zweier simpler Integer-Variablen handelt.
> Das macht es "anstrengender". Und damit erhöht sich die Gefahr, dass man
> etwas übersieht. Genau das meinte ich mit "darüber hinwegsehen".

Ne, ganz so schlimm ist es nicht. In C++ kannst Du keine eigene 
Definition für operator+(int,int) angeben. Mindestens ein Operand muss 
Benutzer definiert sein.

Wenn Dir als Reviewer nicht auffällt, dass einer der beiden Operanden 
Benutzer definiert ist, dann ist der Code wohl eh schon recht ungünstig 
Strukturiert.

> Bei einem expliziten Funktionsaufruf bin ich als Code-Reviewer
> gezwungen, mir diese anzuschauen. Da gibt es keinen Zweifel.

So weit würde ich nicht gehen. Wenn jedes Stück Code im Projekt 
gereviewed wurde, dann auch die aufgerufene Funktion. Der Reviewer prüft 
dann, ob operator+ der richtige Name für die Funktion ist (do it like 
the ints do).

Operatoren werden in C++ eigentlich "relativ" selten verwendet, weil die 
Menge der zur Verfügung stehenden "Funktionsnamen" recht überschaubar 
ist und die Bedeutung jedes Operators recht klar definiert ist.

Autor: Stefanus F. (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich mag Operator-Überladung gar nicht und nutze es daher auch nur, wenn 
ich durch Libraries dazu gezwungen werde. Stattdessen benutze ich lieber 
Methoden mit sprechenden Namen (im Java Style), zum Beispiel 
MyList::append(element).

Aber ich mag die Sprache dennoch. Es zwingt mich ja niemand dazu, jedes 
Feature zu nutzen. Dann benutze ich halt nur das, was mir zusagt. Selbst 
für andere Entwickler ist das in der Praxis kein Hindernis, meine Codes 
weiter zu verwenden oder gar zu ändern.

Leite, die sich über solche Kleinigkeiten einen zu großen Kopf machen, 
nenne ich gerne "Künstler". Sie neigen auch dazu, ihr Programm so zu 
behandeln, wie die Glucke über ihre Küken wacht. Am liebsten darf das 
niemand verändern. ich habe schon mehrmals zugesehen, dass "Künstler" 
wegen diesem Verhalten entlassen wurden.

> Operatoren werden in C++ eigentlich "relativ" selten verwendet

Leider denkt nicht jeder Entwickler so vernünftig. Die meisten aber 
schon. Ich habe nur selten Code gesehen, wo Operatoren auf überraschende 
Weise überladen wurde. Wovon Stroustrup übrigens zu recht dringend 
abrädt.

: Bearbeitet durch User
Autor: Stefanus F. (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Gerade wegen dem Stromverbrauch setze ich ziemlich komplexe und dicke
> Controller weil weil sich da alles abschalten laesst

Na dann schalte mal bei einem noch relativ schlanken STM32F103 alles 
abschaltbare ab (außer Wake-Up per externem Signal) und vergleiche die 
Stromaufnahme mit irgendeinem beliebigen AVR oder PIC.

Was in der AVR Welt typischerweise  it "Super Low Power Consumption" 
hochgepriesen wird, ist immer noch mindestens um Faktor 10 über dem, was 
man von gewöhnlichen 8bit Controllern gewohnt ist.

Sicher gibt es tatsächlich (nicht durch Marketing erlogene) sparsame ARM 
Controller, aber wenn du die mit den speziellen Low-Power 8bit 
Controllern vergleichst (sagen wir mal, was in Taschenrechnern und Uhren 
steckt), dann liegen auch da wieder Welten zwischen.

Autor: Torsten R. (Firma: robitzki.de) (torstenrobitzki)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Eric B. schrieb:

> Wenn ich dir sage, dass du überall wo "Blobfutzl" steht "Weissbier"
> lesen sollst, könen wir über "Blobfutzl" reden. Das macht es aber nicht
> Teil der deutsche Sprache.

Naja, mit solchen Vergleichen, kannst Du Alles und Nix belegen. Sollten 
wir Techniker den Politikern und Theologen überlassen ;-)

Autor: Nop (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
olaf schrieb:

> Gerade wegen dem Stromverbrauch setze ich ziemlich komplexe und dicke
> Controller weil weil sich da alles abschalten laesst

Cortex-A hat einen wesentlich höheren Stromverbrauch als Cortex-M, und 
Cortex-M4 mehr als Cortex-M0. Darüberhinaus ist das An/Abschalten von 
Sachen auch nur eine API-Funktion, innerhalb derer man ein paar Register 
bedient. Baut man halt in der Treiberschicht ein und gut ist. Ich sehe 
da keine sonderliche Komplexität, zumal man ja auch nur das abschalten 
muß, was man selber mal angeschaltet hat.

Darüberhinaus darf x86 sicherlich als sehr komplex gelten, und trotzdem 
ist der Linuxkernel in C - und der Kernel ist komplexer als alles, was 
unsereins je embedded tun wird.

Autor: Stefanus F. (stefanus)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
> Und genau deswegen wird es auch weiterhin einfache Controller geben,
> weil es einen Industriebedarf gibt, daß man leicht reviewbaren Code
> innerhalb der Anforderungen erstellen kann.

Das sehe ich auch so. Als "Helfer" für größere Computer sehe ich bei den 
"kleinen" Mikrocontrollern noch eine lange Zukunft. Ich denke da an so 
Sachen wie Eingabegeräte, Laderegler, Timer, Verbrauchszähler, und viel 
Kleinzeug im Bereich der Maschinensteuerungen.

Autor: Eric B. (beric)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg W. schrieb:
> Zumindest in C sind sie das: du darfst im eigenen Code beispielsweise
> eben keine eigene printf-Implementierung haben,
int printf(char *str)
{
  return 0;
}

int main(void)
{
  return printf("Hello, Word!");
}
...compiliert und linkt ohne Fehlermeldungen mit VC und GCC.

: Bearbeitet durch User
Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Torsten R. schrieb:
> Operatoren werden in C++ eigentlich "relativ" selten verwendet

Gelegentlich finde ich sie schon sinnvoll.  Das verlässt natürlich
jetzt eher das Embedded-Thema, aber von einer String-Klasse würde
ich schon erwarten, dass man mit string1 + string2 die Verkettung
beider Strings als Ergebnis erhält – in reinem C war ja das Fehlen
einer derart intuitiven String-Verarbeitung immer ein Kritikpunkt.

Aber man kann natürlich in jeder Sprache Unfug zimmern, wenn man es
drauf anlegt.

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Eric B. schrieb:
> ...compiliert und linkt ohne Fehlermeldungen mit VC und GCC.
foo.c:1:5: warning: conflicting types for built-in function ‘printf’ [enabled by default]
 int printf(char *str)
     ^
foo.c: In function ‘printf’:
foo.c:1:18: warning: unused parameter ‘str’ [-Wunused-parameter]
 int printf(char *str)
                  ^

Naja.

Ändert nichts daran, dass der Standard es so sieht, dass printf ein
Bestandteil der Sprache ist, und darum ging's ja.  Letztlich bestätigt
der Compiler das ja auch durch sein "built-in function ‘printf’" auch,
dass er über diese Funktion Vorwissen besitzt, wie sie auszusehen
hätte.

: Bearbeitet durch Moderator
Autor: avr (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stefan U. schrieb:
> Na dann schalte mal bei einem noch relativ schlanken STM32F103 alles
> abschaltbare ab (außer Wake-Up per externem Signal) und vergleiche die
> Stromaufnahme mit irgendeinem beliebigen AVR oder PIC.

Dafür musstest du jetzt auch den Low cost controller von stm 
heraussuchen, der ein absoluter stromfresser ist. Gute arm-Controller 
haben einen Stromverbrauch von <100uA / MHz und wenige uA im sleep. 
Schau z.B. mal bei silabs efm32 Serie vorbei. Solange avrs nicht im 
sleep sind Verbrauchern die übrigens deutlich mehr als die meistens 
Arms.

Operatoren bieten sich immer an wenn man neue mathematische Datentypen 
benötigt. Beispielsweise biginteger, Vektoren, quaternionen, Matrizen. 
Ich hab vor kurzem in Java gekotzt, weil ein Algorithmus mit ungefähr 20 
Operationen schon nicht mehr normal lesbar war.

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
avr schrieb:
> deutlich mehr als die meistens Arms

Naja, eine maßlose Übertreibung: die meisten ARMs dürften keine
Cortex-M sein, sondern größere Boliden … aber selbst gegen Cortex-M
ist die Aussage nicht völlig korrekt.  Der ARM wird dann besser, wenn
wirklich groß was zu rechnen ist, das ist unstrittig.

Autor: olaf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Schau z.B. mal bei silabs efm32 Serie vorbei.

Genau die hab ich im Einsatz. :-)
Und jetzt ueberlegt mal wie vergleichbares in ein paar Jahren aussieht. 
Die Entwicklung bleibt ja nicht stehen. Man kann derzeit in C arbeiten 
und muss es auch weil es nunmal einfach Standard ist. Aber mit jedem 
Jahr wird der Wunsch groesser das etwas besseres gaebe. Ich hab z.b mit 
interesse go/golang angeschaut. Leider nur bis zu der Stelle mit dem 
garbage collector, seufz. Aber man darf ja hoffen das nochmal was 
kommt...

Olaf

Autor: Eric B. (beric)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg W. schrieb:

> foo.c:1:18: warning: unused parameter ‘str’ [-Wunused-parameter]
>  int printf(char *str)

> Naja.

Interessant:
D:\Temp>cl -Wall printf.c
Microsoft (R) C/C++ Optimizing Compiler Version 19.00.24215.1 for x86
Copyright (C) Microsoft Corporation.  All rights reserved.

printf.c
Microsoft (R) Incremental Linker Version 14.00.24215.1
Copyright (C) Microsoft Corporation.  All rights reserved.

/out:printf.exe
printf.obj

D:\Temp> _

Autor: Yalu X. (yalu) (Moderator)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Wilhelm M. schrieb:
> Nop schrieb:
>> Was allerdings in C holprig ist, sind generische Datenstrukturen. Der
>> Library-Quicksort muß für jeden Vergleich einen Funktionsaufruf machen,
>> der nichtmal inline-fähig ist. C-Qsort ist daher ziemlich lahm. […]
>>
>> In C++ ist das kein Problem. Man braucht keine expliziten Funktionen
>> mehrfach hinschreiben und hat trotzdem nicht diesen indirekten
>> Funktionsaufruf für die Vergleiche.
>>
>> Frage: Angenommen, man will denselben Sortieralgorithmus auf zwei
>> verschiedene Datenstrukturen anwenden in C++, was fällt bei C++ dann am
>> Ende in Maschinencode raus? Sind das auch separate Funktionen, also von
>> der Codegröße her dasselbe wie mit C und separatem Hinschreiben?
>
> Du wetterst in Deinen obigen Beiträgen so gegen C++, aber hast Dich
> offenbar noch nicht wirklich damit befasst!
> Schau mal bei template-Instanziierung nach ;-)

Er spricht aber einen wichtigen Punkt an:

Die sort-Funktion ist ja im Vergleich zu den meisten anderen Template-
Funktionen der Standardbibliothek eine recht große Funktion, weswegen
man sich bei mehreren Instanzen und beschränktem Programmspeicher
zumindest einmal kurz Gedanken machen sollte, wieviel eine Instanz von
sort tatsächlich in etwa belegt.

Wüsstest du es auf Anhieb? Oder was würdest du schätzen?

Ich habe mal nachgeschaut: Es sind um die 1kB, abhängig vom verwendeten
Datentyp, der Vergleichsfunktion und den Optimierungsoptionen des
Compilers.

Will man also nur Int-Vektoren sortieren, ist der Speicherbedarf in etwa
gleich wie bei qsort. Hat man zusätzlich noch einen zu sortierenden
Double-Vektor, wird ein weiteres kB belegt. Will man an einer anderen
Stelle die beiden Vektoren in ab- statt aufsteigender Reihenfolge
sortieren, kommt jeweils noch  ein kB hinzu. Selbst für das Sortieren
eines std::array, dessen Nutzdaten in derselben Form vorliegen wie beim
std::vector, wird eine neue Instanz von sort anlegt, d.h. noch ein kB
verbraucht.

Bei einem PC mit ein paar GB Hauptspeicher fallen selbst 1000 Instanzen
von sort nicht ins Gewicht, auf einem kleinen bis mittelgroßen µC aber
schon.

Das spricht nicht grundsätzlich gegen den Einsatz C++ auf µCs, denn man
hat ja auch in C++ nach wie vor Zugriff auf die qsort-Funktion. Das
Beispiel zeigt aber, dass man bei der Programmierung in C++ unter
Ressourcenbeschränkungen schon ziemlich genau wissen muss, was man tut
bzw. wie der Compiler den Quellcode umsetzt. Wenn man nun jedem neuen,
noch nicht so erfahrenen Mitglied einer Entwicklerguppe erklären muss,
was es bei der C++-Programmierung auf µCs alles zu beachten gibt, wendet
man dafür u.U. mehr Zeit auf als wenn man einfach bei der etwas weniger
produktiven C-Programmierung bleibt.

Autor: avr (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg W. schrieb:
> avr schrieb:
>> deutlich mehr als die meistens Arms
>
> Naja, eine maßlose Übertreibung: die meisten ARMs dürften keine
> Cortex-M sein, sondern größere Boliden … aber selbst gegen Cortex-M
> ist die Aussage nicht völlig korrekt.  Der ARM wird dann besser, wenn
> wirklich groß was zu rechnen ist, das ist unstrittig.

Ja, ich meinte eigentlich die Cortex-M Reihe. Dort verbrauchen die 
Controller eigentlich alle weniger µA/MHz. Die Avrs bieten Vorteile, 
wenn wirklich fast nichts zu rechnen ist. Aber selbst hier gewinnen sie 
gegen einen auf Stromverbrauch getrimmten M0+ kaum etwas.

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
avr schrieb:
> Aber selbst hier gewinnen sie gegen einen auf Stromverbrauch getrimmten
> M0+ kaum etwas.

Yep, Cortex-M0+ sind in der Tat in dieser Hinsicht interessant.
Wenn man sie dann noch als 5-V-Version hat (bspw. SAMC21), dann
hat man auch diesen bereich noch abgedeckt.

Autor: Wilhelm M. (wimalopaan)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Yalu X. schrieb:

> Er spricht aber einen wichtigen Punkt an:
>
> Die sort-Funktion ist ja im Vergleich zu den meisten anderen Template-
> Funktionen der Standardbibliothek eine recht große Funktion, weswegen
> man sich bei mehreren Instanzen und beschränktem Programmspeicher
> zumindest einmal kurz Gedanken machen sollte, wieviel eine Instanz von
> sort tatsächlich in etwa belegt.
>
> Wüsstest du es auf Anhieb? Oder was würdest du schätzen?
>
> Ich habe mal nachgeschaut: Es sind um die 1kB, abhängig vom verwendeten
> Datentyp, der Vergleichsfunktion und den Optimierungsoptionen des
> Compilers.

Für welche Architektur hast Du es probiert?

Autor: Der Andere (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Wird Zeit daß endlich mal jemand Fortran-2008 Compiler für µCs 
implementiert

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der Andere schrieb:
> Wird Zeit daß endlich mal jemand Fortran-2008 Compiler für µCs
> implementiert

Wenn du einen Cortex-M7 mit 32/64-bit-FPU hast, warum nicht? ;-)

Autor: Eric B. (beric)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg W. schrieb:
> Ändert nichts daran, dass der Standard es so sieht, dass printf ein
> Bestandteil der Sprache ist, und darum ging's ja.  Letztlich bestätigt
> der Compiler das ja auch durch sein "built-in function ‘printf’" auch,
> dass er über diese Funktion Vorwissen besitzt, wie sie auszusehen
> hätte.

Habe es noch mal probiert mit GCC und der meckert tatsächlich. 
Anderenseids meckert er auch wenn ich das selbstgebackene printf einfach 
weglasse:
/*int printf(char *str)
{
  return str != (char *) 0;
}*/

int main(void)
{
  return printf("Hello, World!");
}
D:\Temp>gcc printf.c
printf.c: In function 'main':
printf.c:8:10: warning: implicit declaration of function 'printf' [-Wimplicit-function-declaration]
   return printf("Hello, World!");
          ^
printf.c:8:10: warning: incompatible implicit declaration of built-in function 'printf'
printf.c:8:10: note: include '<stdio.h>' or provide a declaration of 'printf'
Also so ganz und komplett built-in ist es auch nicht...

Autor: S. R. (svenska)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Deklaration von printf() befindet sich in stdio.h - wenn du die 
nicht einbindest, bekommst du eine inkompatible Deklaration.

Dennoch ist dem Compiler printf() bekannt, was nicht so sein dürfte, 
wenn es nicht zum Standard gehörte.

Autor: Der Andere (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg W. schrieb:
> Wenn du einen Cortex-M7 mit 32/64-bit-FPU hast, warum nicht? ;-)

Warum, als Fortran entwickelt wurde, hatte ein IBM Mainframe weniger 
Rechenleistung. Ein heutiger 8bitter hat dieselbe Rechenleistung wie ein 
PC-XT.
Und selbst heute sind anspruchsvolle Mathebibliotheken, die in C++ und 
Phyton benutzt werden oft genug noch in Fortran geschrieben.

Gut ich gebe zu der Beitrag war nicht ganz erst gemeint, aber als 
kleiner Weckruf für die streitenden Ideologen gedacht.

:-)

Autor: Yalu X. (yalu) (Moderator)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Wilhelm M. schrieb:
> Für welche Architektur hast Du es probiert?

Entschuldigung, das wollte ich noch schreiben, habe es aber vergessen:

Es ist ein Notebook mit i7-CPU und GCC. Etwas anderes habe ich nicht zum
Testen da.

Autor: Eric B. (beric)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
S. R. schrieb:
> Dennoch ist dem Compiler printf() bekannt, was nicht so sein dürfte,
> wenn es nicht zum Standard gehörte.

Aber ein bisschen schizophren ist es schon. Der Compiler kennt printf() 
und auch die dazu gehörende Deklaration; sonst könnte er nicht 
anmeckern, dass ich eine andere Deklaration oder Definition verwende als 
was er kennt. Dennoch muss ich händisch (oder per #include) die Funktion 
deklarieren, und zwar genau so wie der Compiler sie schon kennt, um ihn 
zufrieden zu stellen?

(Wo ist c-hater wenn man ihn braucht? ;-D)

Autor: Wilhelm M. (wimalopaan)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Eric B. schrieb:
> S. R. schrieb:
>> Dennoch ist dem Compiler printf() bekannt, was nicht so sein dürfte,
>> wenn es nicht zum Standard gehörte.
>
> Aber ein bisschen schizophren ist es schon. Der Compiler kennt printf()
> und auch die dazu gehörende Deklaration; sonst könnte er nicht
> anmeckern, dass ich eine andere Deklaration oder Definition verwende als
> was er kennt. Dennoch muss ich händisch (oder per #include) die Funktion
> deklarieren, und zwar genau so wie der Compiler sie schon kennt, um ihn
> zufrieden zu stellen?

In C hat jede(!) Funktion ohne Prototyp den Rückegabetyp int und eine 
beliebige Parameterliste.

Autor: Wilhelm M. (wimalopaan)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Yalu X. schrieb:
> Wilhelm M. schrieb:
>> Für welche Architektur hast Du es probiert?
>
> Entschuldigung, das wollte ich noch schreiben, habe es aber vergessen:
>
> Es ist ein Notebook mit i7-CPU und GCC. Etwas anderes habe ich nicht zum
> Testen da.

Habs gerade auf einem AVR getestet:
00000146 00000220 W void quickSort<unsigned char, 100u>(std::array<unsigned char, 100u>&, unsigned int, unsigned int)
00000366 00000294 W void quickSort<unsigned int, 100u>(std::array<unsigned int, 100u>&, unsigned int, unsigned int)

wobei das natürlich nicht die Version der libstdc++ ist.
Also für 8-Bit: 220-Bytes und für 16-Bit 294 Bytes.

Autor: Wilhelm M. (wimalopaan)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dem gebenüber qsort() für uint8_t:
00000146 00000014 W int less<unsigned char>(void const*, void const*)
00000198 00000040 t swapfunc
00000238 00000106 t med3
00000344 00000730 T qsort
00001074 00000040 T __udivmodhi4

macht zusammen 930 Bytes (wobei dies natürlich fast (bis auf less()) 
unabhängig vom zu sortierenden DT ist).

Autor: S. R. (svenska)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wilhelm M. schrieb:
> Habs gerade auf einem AVR getestet: [...]
> Also für 8-Bit: 220-Bytes und für 16-Bit 294 Bytes.

Eine unbenannte Version ist also kleiner als die der Standardbibliothek. 
Das ist zwar schön, aber komplett am Thema vorbei.

Der Punkt ist nämlich, dass deine Template-Variante für 8-Bit und 
16-Bit schon 514 Byte braucht. Noch 32-Bit dazu, bist du vermutlich bei 
2 KB. Weil du dann schon drei Quicksorts in deinem Code hast.

Die C-Version kommt mit genau einem aus (plus drei trivialen 
Vergleichsfunktionen) und explodiert in der Größe eben nicht, wenn man 
sie für verschiedene Datentypen benutzt.

Autor: Sheeva P. (sheevaplug)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
H.J.Gebhardt schrieb:
> Sheeva P. schrieb:
>> und wie jedes mächtige Feature kann sie auch
>> mißbraucht werden. Aber das ist dann kein Argument gegen das Feature,
>> sondern erstens eines gegen den, der sie mißbraucht, und zweitens gegen
>> seinen Code.
>
> Ganz klar, bei soviel technokratischer Sichtweise ist natürlich *immer*
> der programmierende Mensch "schuld", nie die Programmiersprache.

Welchen Teil von "schlechten, unlesbaden und unverständlichen Code kann 
man in jeder Sprache schreiben" hast Du denn nicht verstanden? Wenn 
jemand sein Werkzeug nicht beherrscht, ist das nicht das Werkzeug 
schuld. Es kämme doch auch niemand auf die Idee, einer Badehose 
vorzuwerfen, daß ihr Träger nicht schwimmen kann... jedenfalls niemand, 
der noch alle Latten am Zaun hat.

Autor: Sheeva P. (sheevaplug)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stefan U. schrieb:
> Dagegen spricht, dass µC in der Regel keine so ausgefuchste
> Speicherverwaltung haben, wie die ausgewachsenen Server Betriebssysteme.
> In Kombination mit knapp bemessenem RAM kommst man schnell zu einem
> Out-Of-Memory wegen Heap-Fragmentierung.
>
> Also "durchgängig" ist hier nicht passend. Man kann C++ auf
> Mikrocontrollern verwenden, aber nur eingeschränkt.

C++ enthält einige Vereinfachungen für die dynamische Speicherverwaltung 
-- die benutzt aber auch in C kaum jemand auf Mikrocontrollern, aus 
denselben von Dir genannten Gründen. Deiner Argumentation folgend müßte 
man dann also sagen, daß auch C "nur eingeschränkt" auf Mikrocontrollern 
verwendet werden kann. Am Ende läuft die Argumentation dann auf die 
Frage hinaus, ob C++ nur dann "das einzig Wahre C++" (tm) ist, wenn man 
alle seine Features benutzt.

Autor: Sheeva P. (sheevaplug)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nop schrieb:
> Sheeva P. schrieb:
>> Doch, genau so ist es.
>
> Ja gut, insofern habe ich mich da lax ausgedrückt: es ist nicht so, daß
> er es aus Geschmacksgründen oder emotionalen Befindlichkeiten heraus
> nicht mag,

Doch, genau so ist es.

> sondern er lehnt es aus guten Gründen ab.

Er faselt von "horrible crap" für "substandard programmers". Wenn Du das 
für "gute Gründe" hälst, dann haben wir beide ein sehr unterschiedliches 
Verständnis davon, was "gute Gründe" sind. Sachliche Argumente gegen C++ 
habe ich von Linus jedenfalls keine gelesen oder gehört.

> Während Torvalds mit dem Linuxkernel und auch mit Git immerhin relevante
> Projekte vorzeigen kann?

Linus Torvalds hat meines Wissens bislang weder ein Industrie-, noch ein 
embedeed Projekt gemacht. Und, soweit ich weiß, auch noch kein 
C++-Projekt. Warum sollte ausgerechnet er dazu berufen sein, die einzig 
wahre Wahrheit über C++ oder embedded Projekte zu äußern? Ein Blinder 
redet über Farben, und Du beziehst Dich nur darauf, weil es Dir gerade 
in den Kram paßt.

> Doch, weil man Reviews dann nicht mehr lokal machen kann, denn C++ ist
> sehr kontextabhängig. Jedes popelige Pluszeichen kann diverse Additionen
> in Schleifen bedeuten. Jeder elementare Operator ist möglicherweise ein
> Funktionsaufruf, aber man sieht an der Stelle nicht, welche Funktion
> aufgerufen wird. Dazu muß man sich dann erstmal durch weitere Dateien
> wühlen.

Dann darf man auch in C keine Funktionen benutzen, denn schließlich muß 
unser Reviewer dann in anderen Dateien schauen, was die Funktion tut. 
Die Überladung von Operatoren benutzen fähige Entwickler natürlich nur, 
wenn ihre Funktion offensichtlich ist.

> Finde ich nicht. Es ist halt eine völlig andere Sichtweise. Sie erklärt
> auch, wieso das Anpreisen von noch mehr Features nicht überzeugt, im
> Gegenteil.

Was Dich nicht überzeugt, finden andere ziemlich gut.

Autor: Sheeva P. (sheevaplug)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Eric B. schrieb:
> Hm, da bin ich andere Meinung. Auch wenn in der Standard eine ganze
> Latte an Bibiliotheken beschrieben wird, die mitgeliefert werden soll,
> sind sie nicht Teil der Sprache: ich muss als Programmierer dem Compiler
> mitteilen, (über #include o.Ä.)  dass er bitteschön irgendwelche Typen,
> Funktionen usw. interpretieren soll.

Der Standard definiert die Sprache. Alles, was im Standard steht, ist 
damit auch Bestandteil der Sprache, unabhängig davon, ob diese 
Sprachfeatures nun über Bibliotheken und Header aktiviert werden.

Autor: Programmiersprachentheaterintendant (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Intermediate Summary

Die x-te Zankerei um das Geschwisterpaar "C/C++" ist hier trotz der 
Erbsenzählerei ziemlich sachlich und es hat auch etliche informative und 
lehrreiche Häppchen dabei. (das sollte trotz des heiklen Themas ein Lob 
sein)

M.M.n. wird aber an der Fragestellung des TOs vorbeidiskutiert.
Was für eine Aufgabe soll mit dem gut ausgestatteten uC denn erledigt 
werden? Was hat dieser dann zu rechnen und sortieren? Und wieviel davon?
M.M.n. geben die Antworten auf diese Fragen den entscheidenden 
Richtungshinweis für die Programmiersprache.

Ich konkretisiere mit (hoffentlich representativen) Beispielen.
Ein Apparat mit ein paar Schnittstellen dessen Aufgabe im Wesentlichen 
"store&forward", allenfalls etwas Protokollumsetzungen ist, kann 
durchaus "viel" FLASH (Protokollcode) und RAM (Datenpuffer) erfordern, 
hat aber kaum was zu rechnen (Numbercrunching) und die Komplexität 
seiner Firmware/Datenstrukturen wird maximal ein "beschedenes" Niveau 
erreichen.
Da könnte also fast BASIC, 'tschuldigung: C reichen.
Anderseits kann ein intelligentes Messgerät (1 Liter Volumen, an 
Hutschiene, ~5W Leistungs = Embedded), welches 2-3 physikalische 
Umweltgrössen indirekt erfasst + zur Zeit korreliert (ja: RealTime) und 
über zu seinem Einsatzort spezifischen, flexibel konfigurierbare 
Angaben, direkt aber aufwändig umrechnet in bloss eine einzige 
domainspezifische Kenngrösse + eine Handvoll Alarme (Relaiskontakte) es 
erfordern dass wegen der hohen Integration diverse Libraries 
(Linearalgebra, Geometrie im Raum, Parser f. Konfigurationsdatensprache, 
lokaler Interpreter f. Scriptsprache zwecks ad-hoc 
Funktionalitätsfinetuning) zwingend dynamische Speicherverwaltung 
unumgänglich ist.
Hier geben eher die zur Problemdomain bereits bewährten Libraries resp. 
deren vorhandenen/fehlenden Sprachbindings den Ton zur 
Programmiersprachenwahl an. Und es soll bitte eine HOCHsprache sein.

Dann vermisse ich den Hinweis dass der in Embeddedkreisen so 
hochgehaltenen Zwang zur Ressourcenknappheit meist stärker durch hohe 
bis sehr hohe zu produzierenden Stückzahlen diktiert wird, als durch das 
Miniaturisieren des Endproduktes an sich. (echte Miniaturisierungskosten 
werden selten in Projekten akzeptiert)
Das drückt dann eher die Tendenz richtung C.

Ja, die Wechselwirkung C/C++ zu Ausbildungsniveau der MA zu 
Projektanforderungen UND die unzaehligen, sich immer wiederholenden 
Threads wie dieser, bestärkten mich wiederholend in folgenden 2 
Meinungen:

 - echt gute (Embedded-)Programmier-Cracks sind schwer zu finden, egal 
ob C oder C++; das meisste ist menschliches Mittelmass (ist unsicher, 
trifft strategische/architektonische Fehlentscheidungen, macht laufend 
diverse Fehler). Achtung: ich Stufe mich auch bei letzteren ein.
  Die ganz "coolen Oberhechte" können es nichtmal bei "in flagranti 
erwischt" zugeben, die müssten einen Doktortitel alleine ihres Benehmens 
wegen aufgezwungen bekommen...

 - zur Wahrnehmung der vermeintlichen "guten Eignung" von C/C++ wg. 
allgegenwärtiger Verbreitung (nicht nur Embedded) trägt das viele 
Wiederholen der immer gleichen Fehler bei: entsprechend füllen sich 
Foren, Blogs, Kursangebote, das Angebot an Bücher/Tutorials/etc.
  Wären die Programmiersprachen C/C++ echt gut so würden sie viele 
bekannte Stolperfallen gar nicht bieten (damit sie intrinsisch gemieden 
wären).

Zuletzt noch eine Ergänzung zum Komplexitätsvergleich oben, der auf den 
Umfang der Standards basiert. Meine Lieblingsgrösse ist der Umfang der 
Sprachesyntax in EBNF:
  - Modula-2 passt auf 1 A4 Blatt, dabei bleiben keine "interpretation 
is left to the compiler implementor" über; (na gut, ist bloss 
Prozedural)
  - OO-Erweiterungen zu M2, benötigen nur 1 Handvoll EBNF-Regeln dazu, 
auch Oberon ist auf wenig mehr als 1 A4 Blatt beschrieben.
  - Ada belegt über 20 Seiten (Unterscheidung Ada95 oder andere hier 
nicht relevant)
  - tja und C/C++, wie umfangreich ist das? (es muss CPP zwingend dazu, 
denn ohne kann man nicht...)

  Diese Vergleichgrösse schlägt sich direkt in Komplexität, Grösse, 
(Fehlerpotential) und Abarbeitungsgeschwindigkeit des Compilers nieder. 
Ein schlanker und blitzschneller Compiler ist auf einer zeitgemäßer, 
boliden Entwicklerworkstation nur noch schneller!

  AUF einen üppig ausgestatteten uC gehört also z.B. Lua, um eine 
moderne, schlanke ProgrammierHOCHsprache zu nennen (wenn auch beim 
Design von Lua bewusst Kompromisse im Bezug auf Sprachfeatures 
eingegangen wurden).
  Oder MicroPython, ist aber noch ein wenig jung...

popcorn hol

Autor: A. S. (achs)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Eric B. schrieb:
> Aber ein bisschen schizophren ist es schon. Der Compiler kennt printf()
> und auch die dazu gehörende Deklaration;

Dann lass uns mal die original-Fehlermeldung auseinandernehmen:

Jörg W. schrieb:
> foo.c:1:5: warning: conflicting types for built-in function ‘printf’
> [enabled by default]

Das [enabled by default] ist schon ein Hinweis, dass diese Meldung kein 
C-Problem ist und der Compiler "zu laut" ist. Er kennt sprintf, um die 
wenig typsicheren Parameter wenigstens ein bisschen prüfen zu können. 
Wenn ich ein eigenes, inkompatibles printf baue, dann sollte ich dem 
Compiler das auch sagen oder auf diesen Komfort verzichten.

>  int printf(char *str)
>      ^
> foo.c: In function ‘printf’:
> foo.c:1:18: warning: unused parameter ‘str’ [-Wunused-parameter]
>  int printf(char *str)
Das ist ein einfacher "Programmierfehler". str wird ja in der Tat nicht 
benutz. Meist reicht ein einfaches (void) str; oder so.

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Achim S. schrieb:
> Das [enabled by default] ist schon ein Hinweis, dass diese Meldung kein
> C-Problem ist und der Compiler "zu laut" ist.

Nein, es ist ein Hinweis, dass es dafür keiner -Wirgendwas-Option
bedarf.

Autor: Sheeva P. (sheevaplug)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Programmiersprachentheaterintendant schrieb:
> Zuletzt noch eine Ergänzung zum Komplexitätsvergleich oben, der auf den
> Umfang der Standards basiert. Meine Lieblingsgrösse ist der Umfang der
> Sprachesyntax in EBNF:
> [...]
>   - tja und C/C++, wie umfangreich ist das? (es muss CPP zwingend dazu,
> denn ohne kann man nicht...)

Google hilft, die EBNF für C hat 3 Seiten [1], die für C++ ca. 5 Seiten 
[2].

[1] 
https://cs.wmich.edu/~gupta/teaching/cs4850/sumII06/The%20syntax%20of%20C%20in%20Backus-Naur%20form.htm

[2] 
http://www-i3.informatik.rwth-aachen.de/tikiwiki/tiki-download_file.php%3FfileId=103

Autor: Yalu X. (yalu) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Programmiersprachentheaterintendant schrieb:
> Zuletzt noch eine Ergänzung zum Komplexitätsvergleich oben, der auf den
> Umfang der Standards basiert. Meine Lieblingsgrösse ist der Umfang der
> Sprachesyntax in EBNF:
>   - Modula-2 passt auf 1 A4 Blatt, dabei bleiben keine "interpretation
> is left to the compiler implementor" über; (na gut, ist bloss
> Prozedural)

Hast du einen Link dazu? Oder eine Empfehlung, wie stark das Mikroskop
eingestellt werden muss, um den Text auf der A4-Seite überhaupt lesen zu
können?

>   Diese Vergleichgrösse schlägt sich direkt in Komplexität, Grösse,
> (Fehlerpotential) und Abarbeitungsgeschwindigkeit des Compilers nieder.
> Ein schlanker und blitzschneller Compiler ist auf einer zeitgemäßer,
> boliden Entwicklerworkstation nur noch schneller!

Ich sag ja schon immer, dass Lisp die beste aller Programmiersprachen
ist. Da passt die EBNF in großer Schrift auf die Handfläche, so dass man
sie immer mit dabei hat:

program = s-expr;
s-expr  = atom
        | "(" s-expr "." s-expr ")"
        | "(" { s-expr } ")";

;-)

Edit:

Da fällt mir gerade ein, dass es ja noch eine bessere Programmiersprache
als Lisp gibt, nämlich Forth:

program = { word };

: Bearbeitet durch Moderator
Autor: Sheeva P. (sheevaplug)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Yalu X. schrieb:
> Ich sag ja schon immer, dass Lisp die beste aller Programmiersprachen
> ist. Da passt die EBNF in großer Schrift auf die Handfläche, so dass man
> sie immer mit dabei hat:
>
>
>
> program = s-expr;
> s-expr  = atom
>         | "(" s-expr "." s-expr ")"
>         | "(" { s-expr } ")";
> 

Lisp... warte, war das nicht dieser als höhere Sprache getarnte 
Binärcode, bei dem "(" für eine 0, ")" für eine 1 steht -- manchmal, je 
nach Dialekt, auch umgekehrt? ;-)

Autor: Nop (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sheeva P. schrieb:

> Sachliche Argumente gegen C++ habe ich von Linus jedenfalls keine gelesen oder 
gehört.

Eine Brille oder ein Hörgerät wären eine Überlegung wert. ;-)

> Und, soweit ich weiß, auch noch kein C++-Projekt.

Auch das liegt nicht an Torvalds.

> Ein Blinder redet über Farben

Das hat bei Dan Saks keinen gestört. Darüberhinaus hat er genau welche 
Großprojekte vorzuweisen?

> Dann darf man auch in C keine Funktionen benutzen

Der Punkt war nicht, daß eine Funktionalität ausgeführt wird.

> Die Überladung von Operatoren benutzen fähige Entwickler natürlich nur, wenn 
ihre Funktion offensichtlich ist.

Von irreführender Überladung war nicht die Rede.

> Was Dich nicht überzeugt, finden andere ziemlich gut.

Weswegen sogar ein C++-Proponent eingesteht, daß C++ embedded auf dem 
absteigenden Ast ist. Könnte natürlich auch ökonomisch begründet sein. 
Du wirst, ceterum paribus, für dasselbe Ausmaß an Qualifikation in einer 
wesentlich komplexeren Sprache nunmal deutlich mehr zahlen müssen. 
Alternativ kriegst Du für denselben Preis eben weniger Qualifikation.

Das rechnet sich in dem Moment, wo man ein Projekt hat, das in C 
wesentlich länger dauern würde. Insbesondere GUI und Simulationen sehe 
ich hier. Das sind aber nicht die typischen embedded-Geschichten.

Autor: Jobst Q. (joquis)
Datum:

Bewertung
-4 lesenswert
nicht lesenswert
Jörg W. schrieb:
> aber von einer String-Klasse würde
> ich schon erwarten, dass man mit string1 + string2 die Verkettung
> beider Strings als Ergebnis erhält –

Das tolle an der Stringaddition ist, dass 1000€ und 100€ schon reichen 
um Millionär zu sein.

"1000"+"100" = "1000100"

oder sogar schon 7€:

"1"+"1"+"1"+"1"+"1"+"1"+"1" = "1111111"

Sorry, aber meine Intuition sagt da, dass Verkettung etwas ganz anderes 
ist als Addition.

Autor: Programmiersprachentheaterintendant (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
>
> Hast du einen Link dazu? Oder eine Empfehlung, wie stark das Mikroskop
> eingestellt werden muss, um den Text auf der A4-Seite überhaupt lesen zu
> können?

ISBN 978-3-642-83565-0
T:"Programming in Modula-2"
A:"N. Wirth"

Soll aber nur ein Beispiel sein, konkrete Implementationen, ggfs mit 
OO-Erweiterungen, weichen ein wenig davon ab.

>
>>   Diese Vergleichgrösse schlägt sich direkt in Komplexität, Grösse,
>> (Fehlerpotential) und Abarbeitungsgeschwindigkeit des Compilers nieder.
>> Ein schlanker und blitzschneller Compiler ist auf einer zeitgemäßer,
>> boliden Entwicklerworkstation nur noch schneller!
>
> Ich sag ja schon immer, dass Lisp die beste aller Programmiersprachen
> ist.
:
:
> Da fällt mir gerade ein, dass es ja noch eine bessere Programmiersprache
> als Lisp gibt, nämlich Forth:

Sehr schön: mit einem offenen Blick über den Gartenzaun der Grauen C/C++ 
Welt wird die diskussion Farbig. :-)

Mit Forth landet man auch direkt wieder zentriert im Themengebiet 
uC/RT/Embedded.

Autor: Wilhelm M. (wimalopaan)
Datum:
Angehängte Dateien:

Bewertung
1 lesenswert
nicht lesenswert
Ergänzend zu meinen Zahlen von gestern hier eine Zusammenstellung (s.a. 
Anhang).

Wenn ich nochmal Zeit finde und Luste dazu habe werde ich die Zahlen 
auch noch für ARM-Cortex-Mx (dazu brauche ich aber HW) und Intel Core i7 
zusammenstellen.

Autor: Programmiersprachentheaterintendant (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
>
> Lisp... warte, war das nicht dieser als höhere Sprache getarnte
> Binärcode, bei dem "(" für eine 0, ")" für eine 1 steht -- manchmal, je
> nach Dialekt, auch umgekehrt? ;-)

Polymorphismus und Dynamic Typing (pun intended ;) gab es bereits vor 
der EDV auf Schreibmaschinen: da wurden ganze Datenbanken mit 'l' für 1 
und 'O' für 0 erstellt ;-D

Autor: Nop (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Jobst Q. schrieb:

> Das tolle an der Stringaddition ist, dass 1000€ und 100€ schon reichen
> um Millionär zu sein.

Nein, weil 1 und '1' logisch völlig verschiedene Dinge sind.


Programmiersprachentheaterintendant schrieb:

> Dynamic Typing (pun intended ;)

LOL der war gut!


Wilhelm M. schrieb:

> Ergänzend zu meinen Zahlen von gestern hier eine Zusammenstellung (s.a.
> Anhang).

Embedded nutzt qsort oftmals nicht Quicksort, weil man mit rekursiven 
Algorithmen u.U. in Stackprobleme rennt. Für die typischen Listenlängen 
von vielleicht 100 Elementen oder so, die man auf µCs mal haben kann, 
ist Shellsort wohl die beste Lösung (Ciura-Sequenz nehmen). Oder 
Insertion Sort, bei sehr kurzen Listen. Oder Selection Sort, wenn man 
nur das maximale (oder minimale) Element benötigt.

Siehe auch hier:
http://embeddedgurus.com/stack-overflow/2009/03/sorting-in-embedded-systems/

Auch ein Grund, wieso ich qsort nicht nutze, weil man nie weiß, was 
genau da unter der Haube passiert. Die Ergebnisse sollten zwar 
äquivalent sein, aber wenn es doppelte Sortierschlüssel gibt, weichen 
sie u.U. dennoch ab. Das macht Debugging und Portierung unnötig 
schwierig.

Autor: Wilhelm M. (wimalopaan)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Nop schrieb:
> Wilhelm M. schrieb:
>
>> Ergänzend zu meinen Zahlen von gestern hier eine Zusammenstellung (s.a.
>> Anhang).
>
> Embedded nutzt qsort oftmals nicht Quicksort, weil man mit rekursiven
> Algorithmen u.U. in Stackprobleme rennt.

Nun, damit wollte ich ja auch gar nicht Quicksort propagieren, sondern 
einfach nur u.a. einen Vergleich zu (hier) avr-libc herstellen - völlig 
wertfrei. Und weil nun die libc ein Quicksort (mit Stackbegrenzung und 
Umschaltung auf Insertionsort) verwendet, habe ich es als Template 
genauso gemacht und die anderen Realisierungen von Quicksort dazu 
gepackt.

> Auch ein Grund, wieso ich qsort nicht nutze, weil man nie weiß, was
> genau da unter der Haube passiert. Die Ergebnisse sollten zwar
> äquivalent sein, aber wenn es doppelte Sortierschlüssel gibt, weichen
> sie u.U. dennoch ab. Das macht Debugging und Portierung unnötig
> schwierig.

Die Ergebnisse sind nur gleich, wenn es stabile Sortierverfahren sind.

Autor: Carl D. (jcw2)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jobst Q. schrieb:
> Jörg W. schrieb:
>> aber von einer String-Klasse würde
>> ich schon erwarten, dass man mit string1 + string2 die Verkettung
>> beider Strings als Ergebnis erhält –
>
> Das tolle an der Stringaddition ist, dass 1000€ und 100€ schon reichen
> um Millionär zu sein.
>
> "1000"+"100" = "1000100"

Schöner sind doch die Sprachen, bei denen die Operation nicht vom Typ 
sondern vom Inhalt abhängt:
"x"+"1" -> "x1"
"1"+"1" -> 2
"1"+"x" -> Exception: x is not a number

Das nenn ich wirklich konsistent.

Autor: Nop (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wilhelm M. schrieb:

> Nun, damit wollte ich ja auch gar nicht Quicksort propagieren, sondern
> einfach nur u.a. einen Vergleich zu (hier) avr-libc herstellen - völlig
> wertfrei.

Ah, so herum.

> Die Ergebnisse sind nur gleich, wenn es stabile Sortierverfahren sind.

Sie sind auch gleich, wenn man jedesmal exakt dasselbe instabile 
Sortierverfahren auf denselben Daten anwendet. Derselbe Shellsort auf 
einem ARM wird eine gegebene Liste genauso sortieren wie auf x86.

Hingegen qsort kann in Wahrheit sonstwas sein, und ist es embedded auch 
oft. Das macht natürlich dann auch Vergleiche mit Codegröße und 
Geschwindigkeit schwierig, und Stackbedarf sowieso.

Autor: Wilhelm M. (wimalopaan)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nop schrieb:
> Wilhelm M. schrieb:
>
>> Nun, damit wollte ich ja auch gar nicht Quicksort propagieren, sondern
>> einfach nur u.a. einen Vergleich zu (hier) avr-libc herstellen - völlig
>> wertfrei.
>
> Ah, so herum.
>
>> Die Ergebnisse sind nur gleich, wenn es stabile Sortierverfahren sind.
>
> Sie sind auch gleich, wenn man jedesmal exakt dasselbe instabile
> Sortierverfahren auf denselben Daten anwendet. Derselbe Shellsort auf
> einem ARM wird eine gegebene Liste genauso sortieren wie auf x86.

Welcher (derselbe!) Quicksort wird denn dieselben(!) Daten auf 
unterschiedlichen Architekturen unterschiedliche sortieren? 
(Irgendwelche DT-Begrenzungen ausgeschlossen).

Autor: Yalu X. (yalu) (Moderator)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Jobst Q. schrieb:
> Das tolle an der Stringaddition ist, dass 1000€ und 100€ schon reichen
> um Millionär zu sein.
>
> "1000"+"100" = "1000100"
> ...
> Sorry, aber meine Intuition sagt da, dass Verkettung etwas ganz anderes
> ist als Addition.

Wenn du so denkst (was ich durchaus nachvollziehen kann), dann ist
Haskell dein Freund :)

Dort sind die Operatoren "+", "-" und "*" den Zahlen vorbehalten
(genauer gesagt, der Typklasse Num, die in der Algebra grob dem Ring
entspricht). Für Strings und Listen gibt es "++" oder (allgemeiner, da
auf beliebige Monoide anwendbar) `mappend`.

Anders als in C++ unterliegt das Überladen von Operatoren gewissen
Regeln, um allzu üblem Überladungswildwuchs vorzubeugen. Wobei das
Stringverkettungs-"+" in C++ für mich ja gerade noch akzeptabel ist,
aber mit dem Missbrauch der Bitshift- als Stream-Operatoren ist für mich
die Grenze des guten Geschmacks erreicht. Sie sind dafür nicht nur
logisch, sondern auch in der Operatorrangfolge fehlplatziert und
verstoßen damit ganz klar gegen das Prinzip der geringsten Überraschung.

Natürlich wäre es in Haskell mit wenig Aufwand möglich, Definitionen der
Arithmetikoperatoren für Strings derart zu schreiben, dass, wie von dir
erwartet, "1000"+"100" = "1100" und "3" * "4" = "12" ist. Da aber diese
Form der String-Arithmetik nicht auf beliebige Strings anwendbar ist und
ohnehin kaum gebraucht wird, lässt man es besser bleiben.

Autor: Yalu X. (yalu) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Programmiersprachentheaterintendant schrieb:
>> Hast du einen Link dazu? Oder eine Empfehlung, wie stark das Mikroskop
>> eingestellt werden muss, um den Text auf der A4-Seite überhaupt lesen zu
>> können?
>
> ISBN 978-3-642-83565-0
> T:"Programming in Modula-2"
> A:"N. Wirth"

Ich habe dieses Buch nicht und kann die entsprechende Seite auch in
books.google.com nicht finden. Vermutlich sieht die Syntaxbeschreibung
in etwa so aus:

  https://www.modula2.org/tutor/syntax.php

Weil das aber in lesbarer Schriftgröße kaum auf eine A4-Seite passt,
hätte mich interessiert, wie es im Original aussieht. Ok, dreispaltig
oder mit Weglassen der Zeilenumbrüche in den einzelnen Regeln könnte es
vielleicht passen.

Autor: Jobst Q. (joquis)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nop schrieb:
>> Das tolle an der Stringaddition ist, dass 1000€ und 100€ schon reichen
>> um Millionär zu sein.
>
> Nein, weil 1 und '1' logisch völlig verschiedene Dinge sind.

Logisch nicht, es sind beides gültige Darstellungen vom Typ char. 
Verschieden ist es arithmethisch:'1' ist nicht 1 sondern meistens 49. 
Aber du hast recht, wenn du "1" statt '1' meinst.

Und weil 1 und "1" logisch völlig verschiedene Dinge sind, sind auch 
Verkettung und Addition völlig verschiedene Dinge. Es gibt eine 
Stringverkettung, aber keine Stringaddition. Man kann es praktisch 
finden, für beides denselben Operator zu verwenden, aber es führt auch 
zur Verwirrung.

Ebenso ist das Aufnehmen in eine Liste nicht sinnvoll eine Addition zu 
nennen. list_add(list, item) ist ähnlich irreführend  wie list += item. 
Treffender wären list_append für unsortierte Listen und list_insert für 
die etwas intelligenteren Listen.

Autor: Nop (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Wilhelm M. schrieb:

> Welcher (derselbe!) Quicksort wird denn dieselben(!) Daten auf
> unterschiedlichen Architekturen unterschiedliche sortieren?

Gar keiner natürlich, nur ist qsort nicht Quicksort, und schon gar nicht 
immer derselbe, sondern nur irgendetwas, das sortiert.

Autor: Heinz V. (heinz_v)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Carl D. schrieb:
> Schöner sind doch die Sprachen, bei denen die Operation nicht vom Typ
> sondern vom Inhalt abhängt:
> "x"+"1" -> "x1"
> "1"+"1" -> 2
> "1"+"x" -> Exception: x is not a number
>
> Das nenn ich wirklich konsistent.

Wurde das von, oder für K.B. entwickelt?

Autor: Carl D. (jcw2)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Heinz V. schrieb:
> Carl D. schrieb:
>> Schöner sind doch die Sprachen, bei denen die Operation nicht vom Typ
>> sondern vom Inhalt abhängt:
>> "x"+"1" -> "x1"
>> "1"+"1" -> 2
>> "1"+"x" -> Exception: x is not a number
>>
>> Das nenn ich wirklich konsistent.
>
> Wurde das von, oder für K.B. entwickelt?

Es scheint so.

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
-4 lesenswert
nicht lesenswert
Wilhelm M. schrieb:
>
> auto s = 1_m;
> auto t = 1_sec;
> 
> Velocity = s/t;
> 

Schön, da geht dann auch
Velocity = s + t;

Endlich das tun, was in der Physik nicht geht :-)

Autor: Wilhelm M. (wimalopaan)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Johann L. schrieb:
> Wilhelm M. schrieb:
>>
>> auto s = 1_m;
>> auto t = 1_sec;
>>
>> Velocity = s/t;
>> 
>
> Schön, da geht dann auch
>
>
Velocity = s + t;
>
> Endlich das tun, was in der Physik nicht geht :-)

Hä? Nö.

Autor: Vincent H. (vinci)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Johann L. schrieb:
> Wilhelm M. schrieb:
>>
>> auto s = 1_m;
>> auto t = 1_sec;
>>
>> Velocity = s/t;
>> 
>
> Schön, da geht dann auch
>
>
Velocity = s + t;
>
> Endlich das tun, was in der Physik nicht geht :-)


User defined literals können auch eigene Typen zurück geben. Es ist 
nirgends in Stein gemeißelt, dass s ein Integer ist...

Autor: Sheeva P. (sheevaplug)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Nop schrieb:
> Sheeva P. schrieb:
>
>> Sachliche Argumente gegen C++ habe ich von Linus jedenfalls keine
>> gelesen oder gehört.
>
> Eine Brille oder ein Hörgerät wären eine Überlegung wert. ;-)

Meine Ehefrau sagt sowas auch immer wieder, aber meine Ärzte sagen, daß 
weder das Eine noch das Andere notwendig sind. Aber da Du ja sachliche 
Argumente gefunden haben willst, kannst Du sie doch sicherlich zitieren. 
Vielleicht würde das Deine Argumentation endlich versachlichen, anstatt 
immer wieder über die Ringstruktur jener Vorurteile zu iterieren, die Du 
mit den Aussagen von Linus und Dan initialisiert hast.

>> Und, soweit ich weiß, auch noch kein C++-Projekt.
>
> Auch das liegt nicht an Torvalds.

An wem denn sonst, am Osterhasen vielleicht?

>> Ein Blinder redet über Farben
>
> Das hat bei Dan Saks keinen gestört. Darüberhinaus hat er genau welche
> Großprojekte vorzuweisen?

Frag' Dan, seine Kontaktdaten findest Du dort: [1].

>> Dann darf man auch in C keine Funktionen benutzen
>
> Der Punkt war nicht, daß eine Funktionalität ausgeführt wird.

Aber ja, natürlich. Ein überladener Operator ist nichts anderes als eine 
Funktion, die nur mit einer anderen Syntax aufgerufen wird. Und da einer 
der Operanden immer ein benutzerdefinierter Datentyp sein muß, sieht 
jeder Hirni sofort, daß Dein "+"-Operator nicht auf zwei Zahlen 
angewendet wird, sondern auf Datentypen, die sich normalerweise nicht 
addieren lassen. Also schaut unser Hirni natürlich nach, was da gemacht 
wird -- genau wie bei einem "normalen" Funktionsaufruf auch.

> Du wirst, ceterum paribus, für dasselbe Ausmaß an Qualifikation in einer
> wesentlich komplexeren Sprache nunmal deutlich mehr zahlen müssen.
> Alternativ kriegst Du für denselben Preis eben weniger Qualifikation.
>
> Das rechnet sich in dem Moment, wo man ein Projekt hat, das in C
> wesentlich länger dauern würde.

Das ist eine sehr kurzsichtige Sichtweise, die alle langfristigen 
Effekte besserer Codeorganisation, Les- und Wiederverwendbarkeit 
ignoriert. Klar, kann man machen -- fragt sich nur, wie lange. Nach 
meiner Erfahrung sind Entwickler und Unternehmen, die sich nicht 
weiterentwickeln und -bilden wollen, ziemlich bald auf dem Abstellgleis 
anzutreffen.

[1] http://www.dansaks.com/

Autor: Peter D. (peda)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Torsten R. schrieb:
> In Bereichen, wo die Software einen sehr hohen Anteil an der Entwicklung
> ausmacht, wird arbeitsteilig gearbeitet. Der E-Techniker macht die
> Hardware und SW-Techniker macht die Software.

Das ist in der Tat die Krux, sowas geht eben nicht.
Der HW-Entwickler hat nicht die Lust, sich mit sowas langweiligen wie 
GUI und Webinterface auseinander zu setzen und der GUI-Programmierer 
glänzt wiederum mit völligen Unverständnis der darunter liegenden 
Hardware.
Wir versuchen daher, einen Mittelweg zu nehmen. Der HW-Entwickler macht 
die HW-nahe Programmierung auf einem einfachen MC mit CAN-Interface 
(z.B. AT90CAN128) und der GUI-Crack kann sich dann mit den CAN-Kommandos 
ungeniert austoben, ohne HW zerstören zu können. Er kriegt auch 
Fehlermeldungen, wenn er falsche Kommandos schickt.
Wichtig ist vor allem, der HW-Entwickler bastelt sich auch Kommandos zum 
Test und Diagnose ein, die dann z.B. über UDP getunnelt werden. Das war 
immer ein Hauptproblem, wenn der GUI-Progger direkt auf die HW 
zugegriffen hatte, fehlten sämtlich Diagnosemöglichkeiten. Und 
Fehlermeldungen landeten in /dev/null.

Autor: Wilhelm M. (wimalopaan)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vincent H. schrieb:
> Johann L. schrieb:
>> Wilhelm M. schrieb:
>>>
>>> auto s = 1_m;
>>> auto t = 1_sec;
>>>
>>> Velocity = s/t;
>>> 
>>
>> Schön, da geht dann auch
>>
>>
Velocity = s + t;
>>
>> Endlich das tun, was in der Physik nicht geht :-)
>
>
> User defined literals können auch eigene Typen zurück geben. Es ist
> nirgends in Stein gemeißelt, dass s ein Integer ist...

Da hat ja mal einer mitgedacht: genau so ist es!
DAS meine ich mit einer reichen Typisierung durch domänenspezifische 
Datentypen!
typedef Quantity<1,0,0> Mass;
typedef Quantity<0,1,0> Length;
typedef Quantity<0,2,0> Area;
typedef Quantity<0,3,0> Volume;
typedef Quantity<0,0,1> Time;
typedef Quantity<0,1,-1> Speed;
typedef Quantity<0,1,-2> Acceleration;
typedef Quantity<0,0,-1> Frequency;
typedef Quantity<1,1,-2> Force;
typedef Quantity<1,-1,-2> Pressure;

Mit dem template Quantity<M,L,T> kann man wie oben das Einheitensystem 
bauen. Und definiert dann die physikalisch sinnvollen Operationen.

Autor: Sheeva P. (sheevaplug)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Carl D. schrieb:
> Schöner sind doch die Sprachen, bei denen die Operation nicht vom Typ
> sondern vom Inhalt abhängt:
> "x"+"1" -> "x1"
> "1"+"1" -> 2
> "1"+"x" -> Exception: x is not a number
>
> Das nenn ich wirklich konsistent.

Auch schön: Sprachen, die das "x" dann einfach verschlucken...

"x" + "1" -> 1
"1" + "1" -> 2
"1" + "x" -> 1

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Wilhelm M. schrieb:
> Dem gebenüber qsort() für uint8_t:
>
>
> 00000146 00000014 W int less<unsigned char>(void const*, void const*)
> 00000198 00000040 t swapfunc
> 00000238 00000106 t med3
> 00000344 00000730 T qsort
> 00001074 00000040 T __udivmodhi4

Das ist jetzt nicht dein Ernst, oder?

Autor: Torsten R. (Firma: robitzki.de) (torstenrobitzki)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter D. schrieb:
> Torsten R. schrieb:
>> In Bereichen, wo die Software einen sehr hohen Anteil an der Entwicklung
>> ausmacht, wird arbeitsteilig gearbeitet. Der E-Techniker macht die
>> Hardware und SW-Techniker macht die Software.
>
> Das ist in der Tat die Krux, sowas geht eben nicht.

Doch, soetwas geht! ;-) Mehrfach selbest erlebt und dran teilgenommen.

Autor: Nop (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Sheeva P. schrieb:

> Aber da Du ja sachliche
> Argumente gefunden haben willst, kannst Du sie doch sicherlich zitieren.

Es ist doch allgemein bekannt, wenn man nicht nur die belustigenden 
Teile von Torvalds' Rants liest, daß die sehr wohl versucht haben, ob 
C++ im Kernel sinnvoll ist. Sicher war C++ damals bei weitem nicht da, 
wo es heute ist, aber die Grundphilosophie der compiler magic ist nicht 
weniger, sondern mehr geworden.

> Frag' Dan, seine Kontaktdaten findest Du dort: [1].

Wenn Dan etwas wie den Kernel oder Git vorzuweisen hätte, wüßte man das, 
da braucht man nicht zu fragen. Insbesondere haben sowohl Kernel als 
auch Git genau die Bedingungen der Industrie - immer wieder wechselnde 
Programmierer mit schwankender Qualität.

Wenn Dan sich hinstellt und von modernem C++ erzählt, drückt er damit 
auch nur aus, daß Legcy-Code ihm egal ist, er ist kein 
Maintenance-Programmierer, sondern macht lieber die neuen Systeme (die 
dann in 10 Jahren zum Alptraum der Maintenance-Programmierer werden).

>> Der Punkt war nicht, daß eine Funktionalität ausgeführt wird.
>
> Aber ja, natürlich. Ein überladener Operator ist nichts anderes als eine
> Funktion, die nur mit einer anderen Syntax aufgerufen wird.

Eben das ist das Problem:

http://www.rachelslabnotes.com/2009/10/the-hidden-cost-of-c/

Torvalds' Rant laufen darauf hinaus, daß er keine Leute im Projekt haben 
will, die hierin weder ein offenkundiges Problem sehen noch es bei 
Erklärung als Problem wahrnehmen.

Es sieht elegant aus, ist toll hinzuschreiben, aber professionell wird 
Code viel öfter gelesen als geschrieben. Für den 
Maintenance-Programmierer danach ist sowas die Hölle.

Und es wird noch besser, JEDE Zeile, die in C offensichtlich nichts oder 
nur Elementares tut, kann in C++ einen riesigen Rattenschwanz im 
Hintergrund bedeuten. Der wird vor dem Programmierer versteckt. Das kann 
man als Abstraktion sehen, aber auch als Obfuscation.

Ist egal für den Ersteller, aber extrem mies für die 
Maintenance-Programmierer, und die machen in der Industrie den 
Löwenanteil aus. Weil man eben nicht dauernd alles neu schreibt, schon 
weil Firmen dann pleitegehen würden. Dazu hat Joel Spolsky ja auch ein 
paar interessante Artikel, kennste ja sicher.

Insofern spart C++ da Kosten beim Erstellen, aber sobald der Entwickler 
weg ist, schlagen die Folgekosten umso heftiger zu. Und zwar jedesmal, 
wenn der Entwickler wechselt.

Mag für Dich egal sein, wenn Du selbständig ist und daher Deine Produkte 
selber betreust.

> Also schaut unser Hirni natürlich nach, was da gemacht
> wird -- genau wie bei einem "normalen" Funktionsaufruf auch.

Siehste, Du nimmst das also nicht als Problem wahr. Deswegen zählst Du 
zu genau den Leuten, die ein Torvalds aus seinen Projekten schon dadurch 
vergraulen will, daß er sich für C anstatt für C++ entscheidet.

Wobei man da auch in C Sachen verbrechen kann.. ich sag nur die ST-HAL, 
wo für simples Pin-Toggling Unmengen an Code durchlaufen werden. Es 
bleibt von der Performance her ähnlich problematisch, aber das Problem 
kann sich zumindest nicht auch noch hinter oberflächlicher Einfachheit 
verstecken.

> Das ist eine sehr kurzsichtige Sichtweise, die alle langfristigen
> Effekte besserer Codeorganisation, Les- und Wiederverwendbarkeit
> ignoriert.

Als ob das rein durch C++ gegeben wäre - im Gegenteil, weil es noch viel 
mehr Möglichkeiten gibt, wie man falsch abbiegen kann. Der ganze Code 
aus der Ära, in der man Vererbung und Hierarchien wie geschnitten Brot 
in den Code gekippt hat, ist doch einfach geronnene Lava.

Zumal auch C++ seine eigene Pasta hat - in dem Fall Ravioli. Muß man 
alles nicht machen, man kann auch alles in C++ genau richtig machen? Ja. 
Theoretisch schon. Theoretisch kann man aber auch in C alles richtig 
machen.

> meiner Erfahrung sind Entwickler und Unternehmen, die sich nicht
> weiterentwickeln und -bilden wollen, ziemlich bald auf dem Abstellgleis
> anzutreffen.

Wer jedem Hype hinterherrennt, nur weil's neu ist, macht sich auch nicht 
besser. Wenn man da wirklich woanders hinwollte, wäre C++ keine 
Alternative zu C, sondern völlig neue Sprachen, die die Fehler von C++ 
und Java adressieren. Da tut sich derzeit eine Menge.

C++ ist weder neu noch modern, sondern nur einen Hauch weniger veraltet 
als C. Es ist der Großvater unter den heutigen OOP-Sprachen. Das als 
modern auszugeben ist ein Brüller, der allenfalls im Vergleich mit dem 
noch älteren C funktioniert.

Und zum Weiterentwickeln hatte ich schon etwas gesagt, daß ich es für 
sinnvoller halte, sich auf das Domänenwissen zu konzentrieren, weil das 
im Gegensatz zum Coding Kern-Knowhow ist. Coding wird zusehends 
ausgelagert. Die Leute in Osteuropa sind sehr fit (Indien sieht eher 
schlecht aus), und wenn Du künftig mit deren Gehalt konkurrieren 
möchtest, dann ergibt es strategisch Sinn, sich auf dieses Gebiet zu 
konzentrieren.

Ich konzentriere mich lieber auf andere Sachen und bilde mich 
insbesondere über den Tellerrand der reinen SW-Entwicklung hinaus. Mehr 
dahin, was man überhaupt entwickeln sollte; da gibt's beispielsweise in 
Sachen Usability und Barrierefreiheit eine Menge zu lernen.

Überdies sind in meiner industriellen Praxis die weitaus meisten realen 
Fehler, die ich antreffe, keine C-Fehler - ich entsinne in den letzten 
zwei Jahren überhaupt keinen direkten. Liegt natürlich auch daran, daß 
man mit MISRA die fehlerträchtigsten Konstrukte nur dann erlaubt, wenn 
sie einem gründlichen Review unterzogen wurden. Die natürliche Faulheit 
führt dazu, daß man sich den Aufwand nur ungern antut.

Etwa 25% sind algorithmische Fehler, 75% sind Fehler in der 
Systemdefinition (die aber korrekt in Code umgesetzt wurde), die erst 
bei partiellem Systemausfall oder unter pathologischen Bedingungen zum 
Tragen kommen konnten.

Beitrag #5037862 wurde von einem Moderator gelöscht.
Autor: avr (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
*** schrieb im Beitrag #5037862:
> Ohne
> unnütz sprachgewaltiges Administrations- und Code Palaver, kein
>
> Nop schrieb:
>> ST-HAL,
>> wo für simples Pin-Toggling Unmengen an Code durchlaufen werden

Was natürlich nur dann zutrifft, wenn man sein Werkzeug, den Compiler, 
nicht beherscht. Seit LTO ist das kein Thema mehr.

Beitrag #5037885 wurde von einem Moderator gelöscht.
Autor: Nop (Gast)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
avr schrieb:

> Was natürlich nur dann zutrifft, wenn man sein Werkzeug, den Compiler,
> nicht beherscht. Seit LTO ist das kein Thema mehr.

Ja, beim Compilieren "-flto" in die Flags zu setzen erfordert natürlich 
auch eine unglaubliche Kompetenz - mindestens 50% mehr als "-O02". Zumal 
ich nicht glaube, daß sich die ST-HAL dank LTO wirklich in direkte 
Registerzugriffe übersetzt.

Abgesehen davon sind bei ernsthafteren Projekten keine 
Compiler-Optimierungen erlaubt, wenn man nicht nachweist, daß der 
resultierende Binärcode dann noch das ist, was der Programmierer 
beabsichtigt hat. Der nachweis ist aber dermaßen teuer, daß man ihn 
praktisch nicht führen kann.

Für Consumer-Elektronik ist das natürlich alles egal, die wird aber auch 
billigst in China zusammengedengelt, auch die Software. Schließlich ist 
Qualität dabei weder von Auflagen noch vom Kunden gefordert.

Beitrag #5037967 wurde vom Autor gelöscht.
Autor: Carl D. (jcw2)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Nop schrieb:
...
> Abgesehen davon sind bei ernsthafteren Projekten keine
> Compiler-Optimierungen erlaubt, wenn man nicht nachweist, daß der
> resultierende Binärcode dann noch das ist, was der Programmierer
> beabsichtigt hat. Der nachweis ist aber dermaßen teuer, daß man ihn
> praktisch nicht führen kann.

Eher was der Programmierer dem Compiler mitteilen wollte. Und da ist 
eine Sprache klar im Vorteil die mit Typen virtuos umgehen kann.

Autor: Nop (Gast)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
Carl D. schrieb:

> Eher was der Programmierer dem Compiler mitteilen wollte. Und da ist
> eine Sprache klar im Vorteil die mit Typen virtuos umgehen kann.

Nein, das hat mit Typen wenig zu tun, sondern damit, daß der Compiler 
ganze Codepassagen wegoptimieren kann, die durchaus wesentlich waren. 
Das ist natürlich dann ein Fehler im Code (normalerweise).

Typensicherheit ist sicherlich nett, betrachte ich aber anhand der 
Fehler, die mir real so unterkommen, als nebensächlich. Die Fehler wären 
selbst mit Ada passiert, weil auch Ada keine fehlerhafte Spec abfängt 
und auch keine algorithmischen Fehler.

Autor: Gerhard O. (gerhard_)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Ich finde, soll doch jeder diejenige Werkzeuge verwenden die (für ihn) 
zum vernünftigen Erfolg führen. Die jeweiligen Randbedingungen, Zugang 
zu den notwendigen Werkzeugen, Erfahrung und Sprachengewandtheit, die 
Art der Anwendung und alle andere Faktoren die eine Rolle spielen, 
bestimmen oft maßgeblich die Art der Lösung dieser Aufgaben. Nichts auf 
dieser Erde ist perfekt(nicht einmal ich;-) ) Jede Sprache hat ihre 
Stärke und Schwächen und da so Vieles intrikat voneinander abhängt gibt 
es sowieso keine "goldene" Lösung des Problems. Letztlich hängt es dann 
vom Entwickler, die vorhandenen Werkzeuge und dem Druck des 
Auftraggebers ab, wie es gemacht wird. Und dann, muß man eben (als 
Entwickler) die Suppe auf Gedeih und Verderb selber auslöffeln.

Es hieß ja vor langer Zeit, C wäre ja nur ein verbesserter Assembler. 
Hardware nahe läßt sich Vieles Resourcen effizient erreichen und ist für 
knappe uC ideal. Das gilt zum Teil auch für C++, wenn mit Verstand 
eingesetzt.

Auch wenn C heutzutage einen faden Geschmack aufweisen mag und seine 
bekannten Herausforderungen stellt, wird der Erfahrene trotzdem seine 
Probleme in einer angemessenen Zeit erfolgreich lösen und das Projekt 
zum Erfolg führen. Das Gleiche gilt für andere Sprachen. Sorgfältiges 
und richtiges Design und Planung ist doch um Größenordnungen wichtiger 
als unbedingt die Sprache. Für Steueraufgaben mäßiger Komplexität kommt 
man mit C immer zurecht.
In fast zwanzig Jahren brauchte ich nur einmal eine Sortierfunktion. Mir 
scheint (aus meiner Sicht) es ist also für viele Entwickler eher nur 
eine esoterische Notwendigkeit.

Für Anwendungen mit GUI gelten natürlich andere Betrachtungen und 
Voraussetzungen und C++ ist dafür wahrscheinlich viel besser geignet. 
Aber das wird man ja heutzutage kaum auf einem 8-bitter uC machen 
wollen. Und bei leistungsfähigerer HW. spielt der höhere 
Resourcenverbrauch sowieso nur eine zweitrangige Rolle.

Schönes Wochenende,
Gerhard

: Bearbeitet durch User
Autor: Sheeva P. (sheevaplug)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Nop schrieb:
> Sheeva P. schrieb:
>> Aber da Du ja sachliche
>> Argumente gefunden haben willst, kannst Du sie doch sicherlich zitieren.
>
> Es ist doch allgemein bekannt, wenn man nicht nur die belustigenden
> Teile von Torvalds' Rants liest, daß die sehr wohl versucht haben, ob
> C++ im Kernel sinnvoll ist. Sicher war C++ damals bei weitem nicht da,
> wo es heute ist, aber die Grundphilosophie der compiler magic ist nicht
> weniger, sondern mehr geworden.

Also wieder keine sachlichen Argumente, stattdessen nur das jetzt 
sattsam bekannte Argumentum ad verecundiam (die Berufung auf Linus als 
Autorität) sowie ein Argumentum ad populum (etwas sei "allgemein 
bekannt").

Angeblich soll Linus C++ einmal im Jahre 1992 ausprobiert haben, als 
alles noch in den Kinderschuhen steckte: Linus, sein Kernel, und auch 
C++. Auch dazu hat er leider nichts geäußert, was Ähnlichkeit mit einem 
sachlichen Argument gehabt hätte.

>> Frag' Dan, seine Kontaktdaten findest Du dort: [1].
>
> Wenn Dan etwas wie den Kernel oder Git vorzuweisen hätte, wüßte man das,

Nö. Außerhalb der OpenSource-Welt sind nur sehr wenige Entwickler 
bekannt geworden. Es gibt viele Softwareprojekte, deren Komplexität und 
Umfang die von Linux, von Git, und von beiden zusammengenommen weit 
übersteigen. Aber deren Entwickler kennt dennoch niemand. Und sogar 
innerhalb der OSS-Welt sind die meisten Entwickler völlig unbekannt.

> Eben das ist das Problem:
>
> http://www.rachelslabnotes.com/2009/10/the-hidden-cost-of-c/

LOL!

> Insofern spart C++ da Kosten beim Erstellen, aber sobald der Entwickler
> weg ist, schlagen die Folgekosten umso heftiger zu. Und zwar jedesmal,
> wenn der Entwickler wechselt.
>
> Mag für Dich egal sein, wenn Du selbständig ist und daher Deine Produkte
> selber betreust.

Ach, weißt Du, ich arbeite seit vielen Jahren in kleinen, mittleren, und 
manchmal auch recht großen Teams, und bisher sind mir die Probleme, 
deren Vorhandensein Du behauptest, in der Praxis noch nie begegnet. Das 
kommt vielleicht davon, daß Beispiele wie jenes von Rachel "groby" Blum, 
die Du oben zitierst, vollkommen konstruiert und irrelevant sind, weil 
niemand in der Praxis so etwas schreiben würde. (Und wenn das einer 
meiner Entwickler täte, hätte er spätestens nach dem ersten Code Review 
einige ausgesprochen unangenehme Gespräche vor sich.)

Es ist billig, sich irgendwelchen irrelevanten Quatsch aus den Fingern 
zu saugen, den niemand in der Realität machen würde, und diesen Quatsch 
dann als Argument zu mißbrauchen. Das nennt man ein "hypothetisches 
Argument", das schon daran krankt, daß die Prämisse -- nämlich, daß 
jemand so etwas schreiben würde -- schlicht nicht zutrifft. In der 
Praxis ist C++ leichter zu lesen und zu verstehen als die wüsten Orgien 
von Referenzierung und Dereferenzierung, Casts und Zeigerarithmetik, die 
ich in C schon gesehen habe -- die allerdings in der Praxis, und nicht 
nur in der Theorie.

>> Also schaut unser Hirni natürlich nach, was da gemacht
>> wird -- genau wie bei einem "normalen" Funktionsaufruf auch.
>
> Siehste, Du nimmst das also nicht als Problem wahr. Deswegen zählst Du
> zu genau den Leuten, die ein Torvalds aus seinen Projekten schon dadurch
> vergraulen will, daß er sich für C anstatt für C++ entscheidet.

Und trotzdem hat er Patches von uns angenommen, ist das nicht lustig?

>> Das ist eine sehr kurzsichtige Sichtweise, die alle langfristigen
>> Effekte besserer Codeorganisation, Les- und Wiederverwendbarkeit
>> ignoriert.
>
> Als ob das rein durch C++ gegeben wäre - im Gegenteil, weil es noch viel
> mehr Möglichkeiten gibt, wie man falsch abbiegen kann.

Zwischen "falsch abbiegen können" und "falsch abbiegen" liegen aber 
immer noch Welten. Und, wie gesagt: man kann in jeder Programmiersprache 
miesen Code schreiben, da bilden C und C++ keine Ausnahme.

>> meiner Erfahrung sind Entwickler und Unternehmen, die sich nicht
>> weiterentwickeln und -bilden wollen, ziemlich bald auf dem Abstellgleis
>> anzutreffen.
>
> Wer jedem Hype hinterherrennt, nur weil's neu ist, macht sich auch nicht
> besser.

Sicher, aber darum geht es ja nicht. C++ ist kein Hype, sondern längst 
eine etablierte Programmiersprache. Das einzige mir bekannte Umfeld, in 
dem sich noch Leute um "C vs. C++" kloppen, ist das 
Mikrocontroller-Umfeld. Und da begegnen einem selten sachliche 
Argumente, sondern immer wieder dieselben Vorurteile, die entweder noch 
nie gestimmt haben oder im Laufe der Jahre längst behoben worden sind.

Autor: avr (Gast)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
Nop schrieb:
> Abgesehen davon sind bei ernsthafteren Projekten keine
> Compiler-Optimierungen erlaubt,

Hab ich oft genug schon gesehen. Allerdings aus eine anderen Grund. Der 
Code lief mit Optimierungen nicht mehr richtig und das wurde dann auf 
den Compiler geschoben. Tatsächlich lag es an nicht wenigen 
Programmierfehlern. Ich hab oft genug schon den Assembleroutput von 
Compilern debuggt. Ein einziges mal hab ich tatsächlich einen Fehler 
gefunden, der sich aber nur in Verbindung mit Assemblercode zeigte 
(avr-gas). In allen anderen Fällen war der Programmierer schuld. Ich 
behaupte das in mindestens 99,999% der Fälle, in denen Programme mit 
Optimierung nicht laufen, die Schuld bei den Programmierern liegt und es 
gerne auf den Compiler geschoben wird. Keiner ist unfehlbar, jeder macht 
Fehler beim Programmieren - die Optimierung abzulehnen ist jedoch ein 
weitaus schlimmerer. Oftmals findet man Fehler erst dadurch, dass der 
Compiler Code wegoptimiert, weil der Programmierer falschen Code 
schreibt. Somit steigt auch die Codequalität. Ansonsten funktioniert der 
Code im schlimmsten Fall mit einer neuen Compilerversion nicht mehr.

Gerhard O. schrieb:
> Ich finde, soll doch jeder diejenige Werkzeuge verwenden die (für ihn)
> zum vernünftigen Erfolg führen.

Sehe ich auch so, solange man nicht über Werkzeuge herzieht, die man 
nicht kennt.

Autor: avr (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nop schrieb:
> Zumal
> ich nicht glaube, daß sich die ST-HAL dank LTO wirklich in direkte
> Registerzugriffe übersetzt.

Glauben kannst du in der Kirche. Mit der Cube Hal muss man sogar eine 
Data Synchronisation Barrier zwischen Aktivierung des Taktes und 
Peripherieinitialisierung einbauen. Ansonsten schlägt diese gerne fehl 
(siehe auch Errata).

Autor: Sheeva P. (sheevaplug)
Datum:

Bewertung
4 lesenswert
nicht lesenswert
Gerhard O. schrieb:
> Ich finde, soll doch jeder diejenige Werkzeuge verwenden die (für ihn)
> zum vernünftigen Erfolg führen.

Der TO hatte nach einer Empfehlung für ein Werkzeug, genauer: einer 
Sprache gefragt -- und angelegentlich einige etwas krude Aussagen 
getätigt. Daraus hat sich dann eine Diskussion entwickelt, in der einige 
Diskutanten diese Aussagen geradezurücken versucht, und andere jenen 
widersprochen haben.

Kurz gesagt, gibt es hinsichtlich geeigneter Sprachen für μCs mehrere 
"Fraktionen". Da sind einerseits jene, die von jeher nur mit Assembler 
arbeiten wollen oder können, andererseits gibt es eine recht starke C- 
sowie eine etwas weniger starke C++-Fraktion. Bereits zwischen diesen 
Fraktionen gibt es mehr oder weniger sachliche Diskussionen. Derartige 
Diskussionen werden aber nicht einfacher dadurch, daß es innerhalb der 
Fraktionen wiederum unzählige Subfraktionen gibt: manche mit Exoten wie 
Haskell, Forth, Oberon oder Modula, andere mit Erfahrung in Assembler, C 
und C++, wieder andere mit Erfahrung in lediglich einer dieser Sprachen, 
und dann wiederum Leute mit Abneigungen gegen eine der Sprachen.

> Es hieß ja vor langer Zeit, C wäre ja nur ein verbesserter Assembler.
> Hardware nahe läßt sich Vieles Resourcen effizient erreichen und ist für
> knappe uC ideal. Das gilt zum Teil auch für C++, wenn mit Verstand
> eingesetzt.

Das gilt ganz genau so für C++ wie für C. Beide muß man mit Verstand 
nutzen, beide haben ihre Fallstricke (think malloc(3) und new) und 
müssen deswegen auf eng limitierten Umgebungen wie μC immer mit Verstand 
eingesetzt werden. Mit zunehmender Leistungsfähigkeit des μC und 
zunehmender Komplexität des Programms können immer mehr Features benutzt 
werden.

> Für Anwendungen mit GUI gelten natürlich andere Betrachtungen und
> Voraussetzungen und C++ ist dafür wahrscheinlich viel besser geignet.

Das ist der Grund, warum sich OO-Sprachen wie C++, Java und C# in der 
GUI-Entwicklung durchgesetzt haben.

> Aber das wird man ja heutzutage kaum auf einem 8-bitter uC machen
> wollen. Und bei leistungsfähigerer HW. spielt der höhere
> Resourcenverbrauch sowieso nur eine zweitrangige Rolle.

Siehst Du, und da ist es schon wieder, eines dieser Vorurteile. C++ hat 
überhaupt gar keinen höheren Ressourcenverbrauch als C, wenn man es mit 
Verstand einsetzt. Richtig ist, daß der Lernaufwand ein wenig höher ist, 
was sich aber schnell relativiert, wenn man zum Beispiel auch Prüf- oder 
andere Werkzeuge für den PC schreiben will oder muß. Für jene, die das 
nicht müssen, bietet ein -- mit Verstand genutztes -- C++ eine bessere 
Codeorganisation, Typsicherheit, Les-, Wart- und Wiederverwendbarkeit.

Zweifellos gibt es ein paar Leute, die wirklich nur die kleinsten aller 
μC-Programme schreiben und darum auf solche Features verzichten können. 
Sowas ist auch ganz legitim, sollen diese Leute mit ihrem C oder ihrem 
Assembler glücklich sein und bleiben. Kein Problem, solange sie keinen 
Unsinn über andere Sprachen reden.

Ich persönlich bin da eher pragmatisch orientiert: auf PCs (und SBCs wie 
dem RasPi) nutze ich -- je nach Anforderungen, zeitlichen 
Beschränkungen, Verfügbarkeit von Bibliotheken und Werkzeugen -- 
wahlweise Python, C++, sowie Java. Auf μCs benutze ich in der Regel C++, 
meist aber nur wenige Features. Das richtige Werkzeug für meine konkrete 
Aufgabe zu wählen, funktioniert aber nur dann, wenn ich tatsächlich eine 
Wahl habe: also mehrere Werkzeuge beherrsche und ihre Stärken und 
Schwächen kenne.

Autor: Gerhard O. (gerhard_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sheeva P. schrieb:
>> Aber das wird man ja heutzutage kaum auf einem 8-bitter uC machen
>> wollen. Und bei leistungsfähigerer HW. spielt der höhere
>> Resourcenverbrauch sowieso nur eine zweitrangige Rolle.

> Siehst Du, und da ist es schon wieder, eines dieser Vorurteile. C++ hat
> überhaupt gar keinen höheren Ressourcenverbrauch als C, wenn man es mit
> Verstand einsetzt.

Hallo Sheeva,

wollte gerade abschalten und konnte aber nicht umhin hier nochmals 
nachschauen;-)

Vielen Dank für Deine Ausführungen. Aber da hatte ich mich 
wahrscheinlich unklar ausgedrückt. Ich bezog mich in diesem Paragraph 
nicht auf die Wahl der Sprache sondern lediglich auf die 
Leistungsfähigkeit der HW und Speicherplatz Ressourcen. Ich wollte 
wirklich keine Werkzeug Vorurteile aussprechen.

Wenn GUI zur Anwendung kommt, verstehe ich diesbezüglich z.B. als 
Minimum ein HW System auf ARM7TDI/Cortex Basis mit externen großen FLASH 
Speicher (64MB) und SDRAM (16MB) und richtigen TFT Graphics Controller 
mit Touchscreen Interface, Ethernet und sonst noch alles Mögliche. Damit 
läßt sich ein gut funktionierendes System erreichen.

Z.B. auf einem ATMEGA2560 war die Leistung eines GUI mit TFT (320x240) 
schon mehr als gewöhnungsbedürftig. Wir probierten das mal aus und es 
war (wie erwartet) nicht sehr befriedigend. Es funktionierte zwar; aber 
kein Vergleich zu den 32-bittern mit viel höherer Leistung. Aber dafür 
kann der AVR nichts. Für solche Zwecke war er ja nie gedacht. Deshalb 
finde ich es irgendwie unangebracht auf dem Markt (z.B. Arduino, 
Adafruit...) solche Bords, TFTs und LIBs anzubieten weil die 
Voraussetzungen für ein schnelles GUI mit befriedigender Leistung 
einfach nicht gegeben sind. Da spielt die Wahl der Sprache wenig Rolle.

Die HW. Architektur für ein High Performance GUI muß eben aufwendig 
genug  sein um am Ende befriedigende Leistung zu erbringen und die 
Entwicklung nicht zur Qual werden lassen. Und dazu gehört auch die Wahl 
der Werkzeuge und Sprachen.

: Bearbeitet durch User
Autor: Atlas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sheeva P. schrieb:
> C++ ist kein Hype, sondern längst
> eine etablierte Programmiersprache.

Definitiv nicht bei einfacherern MCs, und das hat die hinreichend 
bekannten Gründe. Das wird auch so bleiben. Vielleicht kann man es so 
beschreiben: Komplexe Architekturen verlangen nach komplexen Sprachen, 
einfache nach einfachen. Leistet eine Hochsprache wie C++ bei 
datenintensiven Plattformen wie ARM oder gar PC noch einen Beitrag, die 
Dinge in den Griff zu bekommen ist sie im Umfeld einfacher Controller 
eher zusätzliche Belastung- mit der großen Gefahr, hier ineffizienten 
Code zu schreiben. Nicht daß sie zwangsläufig dazu führen müsste, aber 
sie provoziert ihn, denn da gibt es immer noch den Faktor Mensch, der 
mit dem Füllhorn sprachlicher Möglichkeiten auch umgehen können muß. Zur 
perfekten Beherrschung aber ist für C++ immer noch ein längerer 
Ausbildungsweg nötig als ihn einfachere Sprachen voraussetzen. 
Schlußendlich bleibt eigentlich nur eines festzustellen: Die Gleichung 
"richtige Programmiersprache" enthält neben den Möglichkeiten der 
Sprache und den Erfordernissen des Programms immer auch den Faktor 
Mensch mit seinen Kenntnissen, Voraussetzungen und Vorlieben.

Autor: Gerhard O. (gerhard_)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Sheeva P. schrieb:
> Kurz gesagt, gibt es hinsichtlich geeigneter Sprachen für μCs mehrere
> "Fraktionen". Da sind einerseits jene, die von jeher nur mit Assembler
> arbeiten wollen oder können, andererseits gibt es eine recht starke C-
> sowie eine etwas weniger starke C++-Fraktion. Bereits zwischen diesen
> Fraktionen gibt es mehr oder weniger sachliche Diskussionen. Derartige
> Diskussionen werden aber nicht einfacher dadurch, daß es innerhalb der
> Fraktionen wiederum unzählige Subfraktionen gibt: manche mit Exoten wie
> Haskell, Forth, Oberon oder Modula, andere mit Erfahrung in Assembler, C
> und C++, wieder andere mit Erfahrung in lediglich einer dieser Sprachen,
> und dann wiederum Leute mit Abneigungen gegen eine der Sprachen.

Ich habe eher den Eindruck, daß es innerhalb von Firmen oft schwer ist 
über den Tellerrand zu schauen um Vergleiche mit fortschrittlichen 
Werkzeugen zu ermöglichen. Da muß man als Entwickler oft Eigeninitiative 
ergreifen um sich ein Bild vom Fortschritt machen zu können und eigene 
erste Erfahrungen sammeln zu können.

Meistens ist es so, daß schon vorhandene firmeneigene Werkzeuge 
verwendet werden (müssen oder) sollen und schon vorhandene Bibliotheken 
und vorhandener Code wiederverwendet werden muß. Viele Projekte sind 
Weiterentwicklung schon existierender Gerätschaften oder Produkte und da 
will die GL auch nicht ohne zwingenden Grund Jahrzehnte investierte 
Arbeit wegschmeißen. Oft kommen dann auch noch erschwerend die Kosten 
von Neuzulassungen dazu.

Um in einem solchen Umfeld neue Tools und neue Wege zu verlangen und 
beschreiten kann schwierig sein. Aber das kennt ihr ja alle. Dann ist 
oft keine Zeit für Training und Lernen. Meist erwartet die GL, daß man 
gleich produktiv sein muß. Da ist dann kein Wunder wenn der "Bauer 
nichts frißt, was nicht auf seinem Feld gewachsen ist" und man weiterhin 
althergebrachte Wege wie von jeher beschreitet. Dann bleibt die 
Entwicklung (leider) stehen und das Wissen stagniert und die MA atmen 
bald den Staub der Einsichtigeren (oder Glücklicheren) ein, die mit Elan 
an solchen Firmen vorbei flitzen. Leider kann sich nicht jeder 
Entwickler aussuchen wo er lieber sein möchte.

Autor: AVRler (Gast)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
Atlas schrieb:
> Leistet eine Hochsprache wie C++ bei
> datenintensiven Plattformen wie ARM oder gar PC noch einen Beitrag, die
> Dinge in den Griff zu bekommen ist sie im Umfeld einfacher Controller
> eher zusätzliche Belastung-

Genau. Ich möchte meine klein aber fein bekannte Hardware direkt, klar 
und verständlich ansprechen und nicht in einem abstrakten Wust mit 3 Mal 
um die Ecke denken vernebeln lassen.

Autor: Johannes S. (jojos)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich sehe das 'andersrum': weil ich lieber mit C++ arbeite und die 
Vorzüge nutzen möchte nehme ich passende Controller dazu (Hobby, keine 
HW/SW Zwänge). Und das geht bei Cortex-M0 los die mechanisch nicht 
größer als ATtiny sind aber viel mehr Dampf haben. Und nach oben hin 
geht es mit gleichen oder ähnlichen Werkzeugen zu Devices mit Ethernet 
und schnellen Grafikkontrollern.

Autor: Roland F. (rhf)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Sheeva,

> Auf μCs benutze ich in der Regel C++, meist aber nur wenige Features.

Welche sind das? Das würde mich wirklich mal interessieren.

rhf

Autor: Wilhelm M. (wimalopaan)
Datum:

Bewertung
5 lesenswert
nicht lesenswert
Roland F. schrieb:
> Hallo Sheeva,
>
>> Auf μCs benutze ich in der Regel C++, meist aber nur wenige Features.
>
> Welche sind das? Das würde mich wirklich mal interessieren.

Ich denke, dass Sheeva das genauso sieht wie ich:

Nicht auf µC verwenden:

- RTTI und dyn. Polymorphie
- Exceptions
- Heap-Allokation

Sehr gut zu verwenden:
grundsätzlich alles, was Compiletime-Berechnungen zur Folge hat.

- TMP: haupsächlich als template-Metafunktionen
- variadische templates und fold-expressions
- constexpr, constexpr-functions, constexpr-lambdas und IIFE, 
constexpr-if
- statische Polymorphie
- constraints und concepts

Die Basis dafür ist ein "reiches Typsystem" (was man sich in seiner 
Domäne schafft, etwa wie die oben schon mal angesprochenen 
SI-Einheiten), denn jede Information, die man in die DT codiert, ist 
eine Information weniger, die man zur Laufzeit auswerten muss (manchem 
mag es merkwürdig erscheinen, das man bspw. ganzzahlige Informationen 
auch als DT (etwa wie std::integral_constant, std::false_type, 
std::true_type) darstellen kann). Und auch damit zur Compilezeit rechnen 
kann, so dass das Ergebnis eine Konstante zur Laufzeit ist. Das 
erscheint vielen wahrscheinlich befremdlich, aber die template-engine 
ist eben turing-complete, wobei ich hier nicht zur mit Werten zur 
Compilezeit rechnen kann, sondern ich kann mit Typ-Information rechnen! 
Nochmal: Typinformation kostet keine Laufzeit, eher im Gegenteil.

Wenn ich die Kommentare auch in diesem Thread lese, dann haben (fast) 
alle bei C++ Laufzeit-Polymorphie im Sinn. Und das ist (s.o.) ein 
Feature dieser multiparadigmen Sprache, was auf µC aus gutem Grunde 
nicht zum Einsatz kommt bzw. sehr mit Bedacht eingesetzt werden muss. 
Wer aus diesem, etwa durch Java oder C# geprägtem Blickwinkel, auf C++ 
schaut, sieht die vielfältigen Möglichkeiten gar nicht.

Aber man sollte auch die "Kleinigkeiten" wie Funktionsüberladung, RAII, 
ranged-based-loops, scoped enums, structured bindings, UDL, Op-Overload, 
statische generische Container, unified-initialization, ... nicht 
vergessen. (Jetzt ahbe ich bestimmt ein paar auch von mir sehr oft 
genutzte goodies vergessen).

: Bearbeitet durch User
Autor: avr (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Wilhelm M. schrieb:
> Nicht auf µC verwenden:
>
> - RTTI und dyn. Polymorphie
> - Exceptions
> - Heap-Allokation

Und auf größeren µCs kann man sogar diese verwenden. Vor einem Jahr habe 
ich http://www.partow.net/programming/exprtk/index.html auf einem 
STM32F4 eingesetzt. Das kostete zwar 1 MB an Flash, aber die Bibliothek 
lief einwandfrei und vor allem wahnsinnig schnell (was auch wichtig 
war). Sie nutzt übrigens alle oben aufgeführten Punkte.

Autor: FinFet (Gast)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
Johannes S. schrieb:
> weil ich lieber mit C++ arbeite und die
> Vorzüge nutzen möchte nehme ich passende Controller dazu ...
> Und das geht bei Cortex-M0 los ... viel mehr Dampf haben

So kann man natürlich auch ausdrücken, daß C++ seinen Hardware-Tribut 
einfordert.

Sheeva P. schrieb:
> Zweifellos gibt es ein paar Leute, die wirklich nur die kleinsten aller
> μC-Programme schreiben und darum auf solche Features verzichten können.

Also ich fülle meine AVR-Flashspeicher in C oder purem Assembler meist 
gut aus, da werden es schon nicht die "kleinsten aller μC-Programme" 
sein. Auf welche glorreichen, unverzichtbaren C++ Features ich da 
bislang verzichten musste (außer jenes natürlich, dafür erst dicke 
Lehrbücher pauken zu müssen) ist mir auch nicht ganz klar... So richtig 
austoben können sich Fans hochabstrakter Konstruktion doch damit nur, 
wenn viel Speicher nun wirklich keine Rolle mehr spielt. Weder bin ich 
aber das eine noch steige ich deshalb um auf andere, leistungsfähigere 
MCs. Die wertvolle Zeit ist immer noch besser in die eigentlichen 
Projekte als in fortlaufend neue Controller, Sprachen und Arbeitsmittel 
investiert. Aus meiner bescheidenen Hobby-Sicht.

Autor: Wilhelm M. (wimalopaan)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
FinFet schrieb:

> Also ich fülle meine AVR-Flashspeicher in C oder purem Assembler meist
> gut aus, da werden es schon nicht die "kleinsten aller μC-Programme"
> sein. Auf welche glorreichen, unverzichtbaren C++ Features ich da
> bislang verzichten musste (außer jenes natürlich, dafür erst dicke
> Lehrbücher pauken zu müssen) ist mir auch nicht ganz klar...

Dann ist doch alles ok. Dann bleib dabei!

> So richtig
> austoben können sich Fans hochabstrakter Konstruktion doch damit nur,
> wenn viel Speicher nun wirklich keine Rolle mehr spielt.

Eben nicht! Wieder dieses Vorurteil ...
Was ich oben als gut zu benutzende Features aufgelistet habe, "kostet" 
nichts im direkten Vergleich zu C, aber es macht Programme lesbarer, 
wartbarer, weniger fehleranfälliger, robuster, ...

Autor: PeterPan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
FinFet schrieb:
> Also ich fülle meine AVR-Flashspeicher in C oder purem Assembler meist
> gut aus, da werden es schon nicht die "kleinsten aller μC-Programme"
> sein.

Das ist schön für dich und legitim.

FinFet schrieb:
> Auf welche glorreichen, unverzichtbaren C++ Features ich da
> bislang verzichten musste (außer jenes natürlich, dafür erst dicke
> Lehrbücher pauken zu müssen) ist mir auch nicht ganz klar...

Das ist vermutlich das Problem bei dir...

FinFet schrieb:
> So richtig
> austoben können sich Fans hochabstrakter Konstruktion doch damit nur,
> wenn viel Speicher nun wirklich keine Rolle mehr spielt.

In C++? Nein.

avr schrieb:
> Hab ich oft genug schon gesehen. Allerdings aus eine anderen Grund. Der
> Code lief mit Optimierungen nicht mehr richtig und das wurde dann auf
> den Compiler geschoben. Tatsächlich lag es an nicht wenigen
> Programmierfehlern.

Oh ja, hatte es mal mit einem Kollegen zu tun, der aus der 
Flugzeugsoftware-Branche kam. Ich durfte eine Firmware für einen 
Prototypen von ihm zum Laufen bringen. Optimierungen waren bei ihm total 
verpönt, macht nur Probleme. Und was war? Sobald man die Optimierung 
anschaltete (da reichte schon -O1), machte die Firmware irgendwas 
undefiniertes. Der Grund war, dass Variablen die zwischen Interrupts und 
Mainthread benutzt wurden, keinen Zugriffsmodifier "volatile" besaßen. 
Der Typ hatte schlichtweg keine Ahnung davon, aber Schuld sind natürlich 
die Optimierungen gewesen. Würde mich nicht wundern, wenn seine 
ehemaligen Kollegen auch so Knalltüten sind.

Autor: Programmiersprachentheaterintendant (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>> ISBN 978-3-642-83565-0
>> T:"Programming in Modula-2"
>> A:"N. Wirth"
>
> Ich habe dieses Buch nicht und kann die entsprechende Seite auch in
> books.google.com nicht finden. Vermutlich sieht die Syntaxbeschreibung
> in etwa so aus:
>
>   https://www.modula2.org/tutor/syntax.php
>
> Weil das aber in lesbarer Schriftgröße kaum auf eine A4-Seite passt,
> hätte mich interessiert, wie es im Original aussieht.

:-). 1 A4 Blatt ~ 2 A4 Seiten    ok?

Hier noch die letzte der PIM Varianten, halt noch mit Prosa dazwischen:
* <http://freepages.modula2.org/report4/modula-2.html>;
$ curl -s http://freepages.modula2.org/report4/modula-2.html ¦ grep -oc '$ .*$' 
114
$     # die erste Zeile ist zuviel, also 113 oder noch weniger

Nach durchschütteln von google doch noch ein "Original", S.42+43 = 2x A5 
Seiten (also gar nur 1 A5 Blatt!)
* <http://eah-jena.de/~kleine/history/languages/Wirth-Modula2.pdf>;


Die Unterschiede zu der von dir verlinkten ISO Varianten fallen 
bezüglich (un-)Kompaktheit auf z.B. bei fieldlist oder dem CASE 
Statement. Da scheint bei EBNF auch noch ordentlich Luft für 
"künstlerische Freiheiten" zu sein...
Mit der ISO Variante hatte ich selbst noch nicht das vergnügen.

An einem ehem. Arbeitsplatz konnte ich aber ~10 J BE sammeln mit "Tailor 
M2":
R&D bei Hersteller von VCS f. ATC, also Embedded (68k & PPC), RT 
Sprachkommunikation weil massig PCM30 basiert. Rund 200 operative 
Systeme installiert vom Lappland bis Südafrika / von Portugal bis China 
(inkl. ESA + ein paar Sonderanwendungen ausserhalb ATC). Definitiv reale 
Industrie, nicht Akademie.

Autor: Oliver J. (skriptkiddy)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Hier ist ja mal wieder eine echte C vs C++ Duskussion im Gange. :)

Dann will ich mal meine Ansicht zum Besten geben.

Ich war sehr lange der Meinung, man müsse kleine 8-Biter mit C 
programmieren, da C++ der totale Overkill dafür ist. Mittlerweile sehe 
ich das etwas anders. Man kann C++ sehr wohl gewinnbringend auf kleinen 
µC einsetzen. Ein guter Proof of Concet ist meiner Meinung nach 
"Arduino" [Bitte nicht schlagen :D]. Da gehört zwar noch Ordnung rein 
und ein Teil sollte etwas weniger verschwenderisch umgestzt sein, aber 
im großen und Ganzen zeigt es, dass man mit C++ durchaus Code 
produzieren kann, der sich sehr einfach verstehen/verwenden lässt. 
Ehrlich gesagt nutze ich das sogar privat für meine Bastelprojekte, da 
man UART/Zeitmessung/u.a. einfach schon geschenkt bekommt. Ich habe 
dafür den avr-arduino-core geforkt und da dann alles was ich so brauchte 
drüber gesetzt. Das Letzte was ich dafür (aus Spaß an der Freude) 
gemacht hab sind I2C-Treiber für ein paar I2C-ICs die ich hier so 
rumliegen hatte. Das sind alles Klassen, die im Konstruktor eine 
Referenz auf einen abstrakten I2C-Bus erwartet haben. Damit konnte ich 
sehr gut verschiedene I2C-Treiber (HW/SW) reingeben und auch einen 
I2C-MUX abbilden. Die Treiber ließen sich perfekt Unittesten, indem man 
einfach einen I2C-Bus-Mock(gmock) beim Instanziieren reingegeben hat. 
Angelegt wurden die Objekte für den AVR statisch. Ich glaube nicht, dass 
das am Ende so viel mehr Speicher gebraucht hat, als eine äquivalente 
Lösung in C. Das Vorgehen mag vielleicht für einige Mitstreiter so 
wirken, als würde man so mit Kanonen auf Spatzen schießen, aber für mich 
zählen hier mittlerweile ganz klar die Lesbarkeit und die Wartbarkeit. 
Ich erreiche beides durch die Verwendung von C++ leichter als mit der 
Sprache C.

Von mir für den AVR-Code genutzte Features aus C++11 (Reihenfolge hat 
keine Bedeutung):
- Polymorphie (für Interfaces -> ist gar nicht so teuer wie man denkt, 
sollte aber trotzdem sparsam eingesetzt werden)
- Enum-Klassen (die Namensraumverschmutzung in C ist doch grausig oder?)
- Überladen (eher für Methoden, weniger für Operatoren)
- Namespaces (das schafft richtig Ordnung)
- References (viel schöner als Pointer)
- Lambda-Ausdrücke
- Default-Parameter
- Templates (damit bin ich aber sehr sparsam, da es die Lesbarkeit 
rapide sinken lässt)
- ... mehr fällt mir jetzt nicht ein

Es muss natürlich jeder für sich entschieden, was er hernimmt, aber ich 
für meinen Teil werde nicht mehr auf C++ für die AVR verzichten.

Edit:
Ich nutze C++ seit nun mehr als 4 Jahren beruflich im 
(Fast-)Embedded-Bereich (Cortex-A8 mit vielen MB Flash und RAM und OS 
ist ja nicht wirklich embedded)


Grüße Oliver

: Bearbeitet durch User
Autor: Sheeva P. (sheevaplug)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
Gerhard O. schrieb:
> Ich bezog mich in diesem Paragraph nicht auf die Wahl der Sprache sondern
> lediglich auf die Leistungsfähigkeit der HW und Speicherplatz Ressourcen.

Ja, ich auch. Mit Verstand eingesetzt, kostet C++ im Vergleich zu C: 
nichts. C++ verbraucht nicht mehr Hardwareressourcen und keinen 
Speicherplatz, der Mehrverbrauch gegenüber C an CPU-Takten, Flash- oder 
RAM-Speicher ist gleich null. Genau das ist es, was ich meine: der 
Glaube, C++ würde mehr CPU-Takte, mehr RAM oder mehr Flash verbrauchen, 
ist falsch -- und ein Vorurteil.

Autor: Sheeva P. (sheevaplug)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Atlas schrieb:
> Definitiv nicht bei einfacherern MCs, und das hat die hinreichend
> bekannten Gründe.

Du meinst: die hinreichend bekannten Vorurteile.

> Das wird auch so bleiben.

Das glaube ich nicht, aber wir werden sehen. Prognosen sind bekanntlich 
schwierig, vor allem, wenn sie die Zukunft betreffen.

> Vielleicht kann man es so beschreiben: Komplexe Architekturen verlangen
> nach komplexen Sprachen, einfache nach einfachen.

Diesen Status hatte die Diskussion eigentlich schon überwunden.

Autor: Sheeva P. (sheevaplug)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Roland F. schrieb:
>> Auf μCs benutze ich in der Regel C++, meist aber nur wenige Features.
>
> Welche sind das? Das würde mich wirklich mal interessieren.

Templates, Vererbung, Referenzen, Scoped Enums, um ein paar Beispiele zu 
nennen. Selten bis gar nicht: Polymorphie, dynamische 
Speicherverwaltung, dynamisches Binden zu Laufzeit, Mehrfachvererbung.

Autor: Sheeva P. (sheevaplug)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
FinFet schrieb:
> Also ich fülle meine AVR-Flashspeicher in C oder purem Assembler meist
> gut aus, da werden es schon nicht die "kleinsten aller μC-Programme"
> sein. Auf welche glorreichen, unverzichtbaren C++ Features ich da
> bislang verzichten musste (außer jenes natürlich, dafür erst dicke
> Lehrbücher pauken zu müssen) ist mir auch nicht ganz klar...

Also: Du kennst D++ nicht und willst es auch nicht lernen, bist Dir aber 
schon ganz sicher, daß C++ einen "Hardware-Tribut" einfordert.

Autor: Atlas (Gast)
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
Sheeva P. schrieb:
> Atlas schrieb:
>> Definitiv nicht bei einfacherern MCs, und das hat die hinreichend
>> bekannten Gründe.
>
> Du meinst: die hinreichend bekannten Vorurteile.

Nö. Gründe. Daß zumindest bis Stand heute bei MCs immer noch "niedere" 
Sprachen die Oberhand haben räumst Du ja mit

>> Das wird auch so bleiben.
>
> Das glaube ich nicht, aber wir werden sehen

selber ein. Nun gibt es aber sowohl MCs als auch C++ nicht erst seit 
gestern... Am PC hingegen hat es sich aus ebenso guten Gründen 
behauptet.

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

Autor: Wilhelm M. (wimalopaan)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Atlas (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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!

Autor: Wilhelm M. (wimalopaan)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Carl D. (jcw2)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Atlas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
3 lesenswert
nicht lesenswert
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.

Autor: avr (Gast)
Datum:

Bewertung
4 lesenswert
nicht lesenswert
@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).

Beitrag #5039410 wurde von einem Moderator gelöscht.
Autor: Wilhelm M. (wimalopaan)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
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).

Autor: Torsten R. (Firma: robitzki.de) (torstenrobitzki)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Arduino Fanboy D. (ufuf)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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!

Beitrag #5039493 wurde von einem Moderator gelöscht.
Beitrag #5039537 wurde von einem Moderator gelöscht.
Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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.

Beitrag #5039546 wurde von einem Moderator gelöscht.
Beitrag #5039549 wurde von einem Moderator gelöscht.
Beitrag #5039554 wurde von einem Moderator gelöscht.
Beitrag #5039559 wurde von einem Moderator gelöscht.
Autor: Arduino Fanboy D. (ufuf)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
[ot]

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

Hier mal was zum Thema:
"Konservativ" vs." jeden Scheiß mit machen"
Youtube-Video "Ruthe.de - Nachrichten - Ehe für alle"


[/ot]

Beitrag #5039563 wurde von einem Moderator gelöscht.
Beitrag #5039567 wurde von einem Moderator gelöscht.
Beitrag #5039570 wurde von einem Moderator gelöscht.
Beitrag #5039575 wurde von einem Moderator gelöscht.
Beitrag #5039578 wurde von einem Moderator gelöscht.
Beitrag #5039580 wurde von einem Moderator gelöscht.
Beitrag #5039589 wurde von einem Moderator gelöscht.
Beitrag #5039592 wurde von einem Moderator gelöscht.
Beitrag #5039595 wurde von einem Moderator gelöscht.
Beitrag #5039597 wurde von einem Moderator gelöscht.
Beitrag #5039615 wurde von einem Moderator gelöscht.
Beitrag #5039616 wurde von einem Moderator gelöscht.
Beitrag #5039619 wurde von einem Moderator gelöscht.
Beitrag #5039622 wurde von einem Moderator gelöscht.
Beitrag #5039625 wurde von einem Moderator gelöscht.
Beitrag #5039628 wurde von einem Moderator gelöscht.
Beitrag #5039632 wurde von einem Moderator gelöscht.
Beitrag #5039633 wurde von einem Moderator gelöscht.
Beitrag #5039634 wurde von einem Moderator gelöscht.
Beitrag #5039639 wurde von einem Moderator gelöscht.
Beitrag #5039643 wurde von einem Moderator gelöscht.
Beitrag #5039644 wurde von einem Moderator gelöscht.
Beitrag #5039655 wurde von einem Moderator gelöscht.
Beitrag #5039658 wurde von einem Moderator gelöscht.
Beitrag #5039668 wurde von einem Moderator gelöscht.
Autor: Karl Käfer (Gast)
Datum:

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

Autor: Chris F. (chfreund) Benutzerseite
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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

Autor: W.S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Nop (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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.

Beitrag #5039777 wurde von einem Moderator gelöscht.
Autor: Sheeva P. (sheevaplug)
Datum: