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?
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
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.
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....
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. ;-)
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
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.
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).
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++.
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!
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.
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.
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
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.
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 ^^
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
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.
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.
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 ...
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.
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. ;-)
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.
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:
https://www.youtube.com/watch?v=D7Sd8A6_fYU
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...
Vincent H. schrieb:>> Leider nein. Laut Dan Saks sinkt die Trendlinie von embedded C++> software, während die von C steigt.>> Siehe hier:> https://www.youtube.com/watch?v=D7Sd8A6_fYU
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.
https://www.youtube.com/watch?v=zBkNBP00wJE
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.
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++ ...
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:>> https://www.youtube.com/watch?v=D7Sd8A6_fYU>> 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.> https://www.youtube.com/watch?v=zBkNBP00wJE
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 ...
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.
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.
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.
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/
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?
> 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
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.
> 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.
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.
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.
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 ;-)
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).
> 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
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
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".
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.
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!
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...
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.
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.
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.
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.
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 ...)
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.
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:> https://www.youtube.com/watch?v=D7Sd8A6_fYU
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
> 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:
1
autod1=10_km
2
autod2=1_mm
3
autod=d1+d2;
4
5
autos=1_m;
6
autot=1_sec;
7
8
Velocity=s/t;
schreiben, und keine Sonde fliegt mehr am Mars vorbei ;-)
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>
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
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.
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
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. :-)
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:
1
Sprache Umfang/S Art des Dokuments
2
———————————————————————————————————————————————
3
C11 180 ISO-Norm
4
C++14 411 ISO-Norm
5
C# 2.0 443 ECMA-Norm
6
C# 5.0 468 Sprachreferenz
7
C# 7.1 ? kein geschlossenes Dokument
8
Java 8 699 Sprachreferenz
9
Haskell 153 Sprachreferenz
10
———————————————————————————————————————————————
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.
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!
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.
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.
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
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.
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.
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.
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.
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?
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.
> 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.
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, ...
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.
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.
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
1
list+=item;
zu
1
list_add(list,item);
?
In beiden(!) Fällen muss ich mir ggf. die Operation ansehen, egal wie
sie syntaktisch geschrieben wurde.
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.
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 ...
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.
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.
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 ;-)
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).
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" :-)
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?
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 ;-)
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.
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.
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.
> 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
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.
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.
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
1
printf("foo\n");
ein
1
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”.
> 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
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.
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.
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.
> 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.
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 ;-)
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.
> 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.
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.
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.
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.
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.
> 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
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.
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.
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.
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?
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? ;-)
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:
1
/*int printf(char *str)
2
{
3
return str != (char *) 0;
4
}*/
5
6
intmain(void)
7
{
8
returnprintf("Hello, World!");
9
}
1
D:\Temp>gcc printf.c
2
printf.c: In function 'main':
3
printf.c:8:10: warning: implicit declaration of function 'printf' [-Wimplicit-function-declaration]
4
return printf("Hello, World!");
5
^
6
printf.c:8:10: warning: incompatible implicit declaration of built-in function 'printf'
7
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...
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.
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.
:-)
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.
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)
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.
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:
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.
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.
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.
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.
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.
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
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.
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.
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:
1
program = s-expr;
2
s-expr = atom
3
| "(" s-expr "." s-expr ")"
4
| "(" { s-expr } ")";
;-)
Edit:
Da fällt mir gerade ein, dass es ja noch eine bessere Programmiersprache
als Lisp gibt, nämlich Forth:
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:>>>
1
> program = s-expr;
2
> s-expr = atom
3
> | "(" s-expr "." s-expr ")"
4
> | "(" { s-expr } ")";
5
>
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? ;-)
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.
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.
>> 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.
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.
>> 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
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.
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.
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.
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.
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).
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.
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.
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.
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.
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?
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.
>> 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...
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/
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.
>>>> 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!
1
typedefQuantity<1,0,0>Mass;
2
typedefQuantity<0,1,0>Length;
3
typedefQuantity<0,2,0>Area;
4
typedefQuantity<0,3,0>Volume;
5
typedefQuantity<0,0,1>Time;
6
typedefQuantity<0,1,-1>Speed;
7
typedefQuantity<0,1,-2>Acceleration;
8
typedefQuantity<0,0,-1>Frequency;
9
typedefQuantity<1,1,-2>Force;
10
typedefQuantity<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.
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
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.
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.
*** 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.
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.
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.
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.
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
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.
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.
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).
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.
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.
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.
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.
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.
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.
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).
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.
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.
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, ...
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.
>> 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>;
$ # 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.
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
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.
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.
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.
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.
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 :)
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.
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!
Thread beobachten
Seitenaufteilung abschalten