Announcement: there is an English version of this forum on 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....
Beitrag #5033526 wurde von einem Moderator gelöscht.
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).
Der Nuller schrieb: > der besseren Selbstdokumentation Was meinst Du damit? Und warum den uC-Code nicht am PC testen und laufen lassen?
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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.
Beitrag #5034468 wurde von einem Moderator gelöscht.
Beitrag #5034558 wurde von einem Moderator gelöscht.
Beitrag #5034574 wurde von einem Moderator gelöscht.
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.
:
Bearbeitet durch User
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 ...
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
> 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 ;-)
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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 ...)
Johannes S. schrieb: > Peripherie einfach z.B. mit 'spi.frequency = 1e6;' einstellen und nicht Und wenn dann da noch
1 | spi.frequency = 1e6_HZ; |
steht, dann ist das sogar dokumentiert. Stichwort "User Definded Literals".
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
Carl D. schrieb: > Johannes S. schrieb: >> Peripherie einfach z.B. mit 'spi.frequency = 1e6;' einstellen und nicht > > Und wenn dann da noch >
1 | spi.frequency = 1e6_HZ; |
> steht, dann ist das sogar dokumentiert. > Stichwort "User Definded Literals". Und mit eine paar templates dazu, kann man sich ein ganze SI-Einheiten System bauen ... dann kann man auch:
1 | auto d1 = 10_km |
2 | auto d2 = 1_mm |
3 | auto d = d1 + d2; |
4 | |
5 | auto s = 1_m; |
6 | auto t = 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
Wilhelm M. schrieb: >
1 | > auto d1 = 10_km |
2 | > auto d2 = 1_mm |
3 | > auto d = d1 + d2; |
4 | >
|
5 | > auto s = 1_m; |
6 | > auto t = 1_sec; |
7 | >
|
8 | > Velocity = s/t; |
9 | >
|
> > schreiben, und keine Sonde fliegt mehr am Mars vorbei ;-) oder gar >
1 | > auto d1 = 10_km; |
2 | > auto d2 = 1_miles; |
3 | > auto d = d1 + d2; |
4 | >
|
falls auch zukünftig noch Forschung zwischen Metric- und Imperial-Ländern stattfindet. (BTW, das Semikolon ist immer noch Pflicht. C++ != JavaScript)
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.
H.J.Gebhardt schrieb: > Sheeva P. schrieb: >> C++ einfach mal lernt > > Ein Widerspruch in sich. > Der Umfang gängiger Lehrbücher spricht Bände. Was für ein lahmes Pseudoargument. Es gibt auch sehr schlanke Lehrbücher für C++, zum Beispiel diese: [1,2,3]. Alle unter 500 Seiten; wenn man bedenkt, daß das Standardwerk für C [4], das ja bekanntlich ein Subset von C++ ist, 274 Seiten hat, wird klar, wie niedrig die Schwelle tatsächlich ist -- und insbesondere für erfahrene C-Entwickler, die die C-bezogenen Teile eines C++-Lehrbuches bereits kennen. Und daß man auch über C sehr umfangreiche Bücher schreiben kann, zeigt [5] mit 1190 Seiten. Allerdings halte ich es gerade in diesem Bereich für vollkommen unsinnig, vom Umfang eines Lehrbuches auf die Komplexität einer Sprache zu schließen. Mit mehr Beispielcode läßt sich der Seitenumfang so eines Buches wunderbar aufblähen, während die Autoren nach Seitenzahl bezahlt werden... ;-) [1] https://www.amazon.de/C-Objektorientiertes-Programmieren-von-Anfang/dp/3499600773 [2] https://www.amazon.de/C-eine-Einf%C3%BChrung-Ulrich-Breymann/dp/3446446370 [3] https://www.amazon.de/f%C3%BCr-Dummies-Stephen-R-Davis/dp/3527710981 [4] https://www.amazon.de/Programming-Language-Prentice-Hall-Software/dp/0131103628 [5] https://www.amazon.de/von-bis-umfassende-Handbuch-Computing/dp/3836214113
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.
:
Bearbeitet durch Moderator
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch Moderator
Wilhelm M. schrieb: > Man könnte ... klar. > Aber dann hat man keine Ahnung von C++. Und das gilt für jede Sprache: > jede hat ihre Eigenheiten, die man kennen muss. > Man könnte auch grundsätzlich "übersehen", dass bestimmte Algorithmen > aufwändiger sind als andere ... Das sehe ich ähnlich. Das Überladen von Operatoren empfand ich schon damals als wirklich hilfreich und einen großen Fortschritt gegenüber C. Es gestaltet den Code deutlich besser lesbar und entspricht viel mehr der menschlichen Intuition. obstkorb = apfel + birne + orange + zitrone finde ich viel klarer als ein Wust aus Funktionsaufrufen. Meiner Meinung nach sinkt dadurch die Fehleranfälligkeit. Dass man aber natürlich vor dem Betrachten von C++-Code davon gehört haben sollte, dass es sowas gibt, sollte selbstverständlich sein. Im übrigen gab es schon damals Editoren, die solche überladenen Operatoren (und nur solche) farblich gekennzeichnet haben, so dass sie einem sofort ins Auge fallen. Ich nehme mal an, dass man heute mit einem Klick darauf direkt zu der Überladung geführt wird. "Hab ich nich' gesehen" lasse ich also nicht gelten ;-)
:
Bearbeitet durch Moderator
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.
:
Bearbeitet durch User
> 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.
Jörg W. schrieb: > Zumindest in C sind sie das: du darfst im eigenen Code beispielsweise > eben keine eigene printf-Implementierung haben,
1 | int printf(char *str) |
2 | {
|
3 | return 0; |
4 | }
|
5 | |
6 | int main(void) |
7 | {
|
8 | return printf("Hello, Word!"); |
9 | }
|
...compiliert und linkt ohne Fehlermeldungen mit VC und GCC.
:
Bearbeitet durch User
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.
Eric B. schrieb: > ...compiliert und linkt ohne Fehlermeldungen mit VC und GCC.
1 | foo.c:1:5: warning: conflicting types for built-in function ‘printf’ [enabled by default] |
2 | int printf(char *str) |
3 | ^ |
4 | foo.c: In function ‘printf’: |
5 | foo.c:1:18: warning: unused parameter ‘str’ [-Wunused-parameter] |
6 | int printf(char *str) |
7 | ^ |
Naja. Ändert nichts daran, dass der Standard es so sieht, dass printf ein Bestandteil der Sprache ist, und darum ging's ja. Letztlich bestätigt der Compiler das ja auch durch sein "built-in function ‘printf’" auch, dass er über diese Funktion Vorwissen besitzt, wie sie auszusehen hätte.
:
Bearbeitet durch Moderator
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
Jörg W. schrieb: > foo.c:1:18: warning: unused parameter ‘str’ [-Wunused-parameter] > int printf(char *str) > Naja. Interessant:
1 | D:\Temp>cl -Wall printf.c |
2 | Microsoft (R) C/C++ Optimizing Compiler Version 19.00.24215.1 for x86 |
3 | Copyright (C) Microsoft Corporation. All rights reserved. |
4 | |
5 | printf.c |
6 | Microsoft (R) Incremental Linker Version 14.00.24215.1 |
7 | Copyright (C) Microsoft Corporation. All rights reserved. |
8 | |
9 | /out:printf.exe |
10 | printf.obj |
11 | |
12 | D:\Temp> _ |
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?
Wird Zeit daß endlich mal jemand Fortran-2008 Compiler für µCs implementiert
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 | int main(void) |
7 | {
|
8 | return printf("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:
1 | 00000146 00000220 W void quickSort<unsigned char, 100u>(std::array<unsigned char, 100u>&, unsigned int, unsigned int) |
2 | 00000366 00000294 W void quickSort<unsigned int, 100u>(std::array<unsigned int, 100u>&, unsigned int, unsigned int) |
wobei das natürlich nicht die Version der libstdc++ ist. Also für 8-Bit: 220-Bytes und für 16-Bit 294 Bytes.
Dem gebenüber qsort() für uint8_t:
1 | 00000146 00000014 W int less<unsigned char>(void const*, void const*) |
2 | 00000198 00000040 t swapfunc |
3 | 00000238 00000106 t med3 |
4 | 00000344 00000730 T qsort |
5 | 00001074 00000040 T __udivmodhi4 |
macht zusammen 930 Bytes (wobei dies natürlich fast (bis auf less()) unabhängig vom zu sortierenden DT ist).
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: > [...] > - tja und C/C++, wie umfangreich ist das? (es muss CPP zwingend dazu, > denn ohne kann man nicht...) Google hilft, die EBNF für C hat 3 Seiten [1], die für C++ ca. 5 Seiten [2]. [1] https://cs.wmich.edu/~gupta/teaching/cs4850/sumII06/The%20syntax%20of%20C%20in%20Backus-Naur%20form.htm [2] http://www-i3.informatik.rwth-aachen.de/tikiwiki/tiki-download_file.php%3FfileId=103
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:
1 | program = { word };
|
:
Bearbeitet durch Moderator
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.
Wilhelm M. schrieb: >
1 | > auto s = 1_m; |
2 | > auto t = 1_sec; |
3 | >
|
4 | > Velocity = s/t; |
5 | >
|
Schön, da geht dann auch
1 | Velocity = s + t; |
Endlich das tun, was in der Physik nicht geht :-)
Johann L. schrieb: > Wilhelm M. schrieb: >>
1 | >> auto s = 1_m; |
2 | >> auto t = 1_sec; |
3 | >>
|
4 | >> Velocity = s/t; |
5 | >>
|
> > Schön, da geht dann auch > >
1 | Velocity = s + t; |
> > Endlich das tun, was in der Physik nicht geht :-) Hä? Nö.
Johann L. schrieb: > Wilhelm M. schrieb: >>
1 | >> auto s = 1_m; |
2 | >> auto t = 1_sec; |
3 | >>
|
4 | >> Velocity = s/t; |
5 | >>
|
> > Schön, da geht dann auch > >
1 | Velocity = s + t; |
> > Endlich das tun, was in der Physik nicht geht :-) User defined literals können auch eigene Typen zurück geben. Es ist nirgends in Stein gemeißelt, dass s ein Integer ist...
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.
Vincent H. schrieb: > Johann L. schrieb: >> Wilhelm M. schrieb: >>>
1 | >>> auto s = 1_m; |
2 | >>> auto t = 1_sec; |
3 | >>>
|
4 | >>> Velocity = s/t; |
5 | >>>
|
>> >> Schön, da geht dann auch >> >>
1 | Velocity = s + t; |
>> >> Endlich das tun, was in der Physik nicht geht :-) > > > User defined literals können auch eigene Typen zurück geben. Es ist > nirgends in Stein gemeißelt, dass s ein Integer ist... Da hat ja mal einer mitgedacht: genau so ist es! DAS meine ich mit einer reichen Typisierung durch domänenspezifische Datentypen!
1 | typedef Quantity<1,0,0> Mass; |
2 | typedef Quantity<0,1,0> Length; |
3 | typedef Quantity<0,2,0> Area; |
4 | typedef Quantity<0,3,0> Volume; |
5 | typedef Quantity<0,0,1> Time; |
6 | typedef Quantity<0,1,-1> Speed; |
7 | typedef Quantity<0,1,-2> Acceleration; |
8 | typedef Quantity<0,0,-1> Frequency; |
9 | typedef Quantity<1,1,-2> Force; |
10 | typedef Quantity<1,-1,-2> Pressure; |
Mit dem template Quantity<M,L,T> kann man wie oben das Einheitensystem bauen. Und definiert dann die physikalisch sinnvollen Operationen.
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
Wilhelm M. schrieb: > Dem gebenüber qsort() für uint8_t: > >
1 | > 00000146 00000014 W int less<unsigned char>(void const*, void const*) |
2 | > 00000198 00000040 t swapfunc |
3 | > 00000238 00000106 t med3 |
4 | > 00000344 00000730 T qsort |
5 | > 00001074 00000040 T __udivmodhi4 |
Das ist jetzt nicht dein Ernst, oder?
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.
Beitrag #5037862 wurde von einem Moderator gelöscht.
*** schrieb im Beitrag #5037862: > Ohne > unnütz sprachgewaltiges Administrations- und Code Palaver, kein > > Nop schrieb: >> ST-HAL, >> wo für simples Pin-Toggling Unmengen an Code durchlaufen werden Was natürlich nur dann zutrifft, wenn man sein Werkzeug, den Compiler, nicht beherscht. Seit LTO ist das kein Thema mehr.
Beitrag #5037885 wurde von einem Moderator gelöscht.
avr schrieb: > Was natürlich nur dann zutrifft, wenn man sein Werkzeug, den Compiler, > nicht beherscht. Seit LTO ist das kein Thema mehr. Ja, beim Compilieren "-flto" in die Flags zu setzen erfordert natürlich auch eine unglaubliche Kompetenz - mindestens 50% mehr als "-O02". Zumal ich nicht glaube, daß sich die ST-HAL dank LTO wirklich in direkte Registerzugriffe übersetzt. Abgesehen davon sind bei ernsthafteren Projekten keine Compiler-Optimierungen erlaubt, wenn man nicht nachweist, daß der resultierende Binärcode dann noch das ist, was der Programmierer beabsichtigt hat. Der nachweis ist aber dermaßen teuer, daß man ihn praktisch nicht führen kann. Für Consumer-Elektronik ist das natürlich alles egal, die wird aber auch billigst in China zusammengedengelt, auch die Software. Schließlich ist Qualität dabei weder von Auflagen noch vom Kunden gefordert.
Beitrag #5037967 wurde vom Autor gelöscht.
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
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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.
Hallo Sheeva,
> Auf μCs benutze ich in der Regel C++, meist aber nur wenige Features.
Welche sind das? Das würde mich wirklich mal interessieren.
rhf
Roland F. schrieb: > Hallo Sheeva, > >> Auf μCs benutze ich in der Regel C++, meist aber nur wenige Features. > > Welche sind das? Das würde mich wirklich mal interessieren. Ich denke, dass Sheeva das genauso sieht wie ich: Nicht auf µC verwenden: - RTTI und dyn. Polymorphie - Exceptions - Heap-Allokation Sehr gut zu verwenden: grundsätzlich alles, was Compiletime-Berechnungen zur Folge hat. - TMP: haupsächlich als template-Metafunktionen - variadische templates und fold-expressions - constexpr, constexpr-functions, constexpr-lambdas und IIFE, constexpr-if - statische Polymorphie - constraints und concepts Die Basis dafür ist ein "reiches Typsystem" (was man sich in seiner Domäne schafft, etwa wie die oben schon mal angesprochenen SI-Einheiten), denn jede Information, die man in die DT codiert, ist eine Information weniger, die man zur Laufzeit auswerten muss (manchem mag es merkwürdig erscheinen, das man bspw. ganzzahlige Informationen auch als DT (etwa wie std::integral_constant, std::false_type, std::true_type) darstellen kann). Und auch damit zur Compilezeit rechnen kann, so dass das Ergebnis eine Konstante zur Laufzeit ist. Das erscheint vielen wahrscheinlich befremdlich, aber die template-engine ist eben turing-complete, wobei ich hier nicht zur mit Werten zur Compilezeit rechnen kann, sondern ich kann mit Typ-Information rechnen! Nochmal: Typinformation kostet keine Laufzeit, eher im Gegenteil. Wenn ich die Kommentare auch in diesem Thread lese, dann haben (fast) alle bei C++ Laufzeit-Polymorphie im Sinn. Und das ist (s.o.) ein Feature dieser multiparadigmen Sprache, was auf µC aus gutem Grunde nicht zum Einsatz kommt bzw. sehr mit Bedacht eingesetzt werden muss. Wer aus diesem, etwa durch Java oder C# geprägtem Blickwinkel, auf C++ schaut, sieht die vielfältigen Möglichkeiten gar nicht. Aber man sollte auch die "Kleinigkeiten" wie Funktionsüberladung, RAII, ranged-based-loops, scoped enums, structured bindings, UDL, Op-Overload, statische generische Container, unified-initialization, ... nicht vergessen. (Jetzt ahbe ich bestimmt ein paar auch von mir sehr oft genutzte goodies vergessen).
:
Bearbeitet durch User
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>;
1 | $ curl -s http://freepages.modula2.org/report4/modula-2.html ¦ grep -oc '$ .*$' |
2 | 114 |
3 | $ # 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
:
Bearbeitet durch User
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!
Atlas schrieb: > Wilhelm M. schrieb: >> Naja, wenn Du nur einen Faustkeil zur Verfügung hast, brauchst viele >> Arbeitsschritte, machst viele Fehler und verbrauchst u.U. mehr Material, >> um ein Handy zu bauen, als wenn Du die richtigen Maschinen verwendest. > > Und Du glaubst wirklich, Asm+C/C++ vs. Faustkeil/richtige Maschine wär > ein passender Vergleich? Warum hat (Misra-)C eine jahrzehntelang > unangefochtene Stellung bei den MCs? Die Antwort auf diese Frage würde > glaube ich weiterführen! Misra-C gibt keine Antwort auf die Frage C vs C++. Misra-C++ gibt auch keine Antwort auf die Frage C++ vc C. Diese Guidelines betrachten jeweils nur die Zielsprache.
Wilhelm M. schrieb: > Atlas schrieb: > >> Sheeva P. schrieb: >>> der >>> Glaube, C++ würde mehr CPU-Takte, mehr RAM oder mehr Flash verbrauchen, >>> ist falsch -- und ein Vorurteil >> >> Nö. Weil Menschen damit programmieren. Je komplexer das Werkzeug desto >> schwieriger der richtige Einsatz. Das übersiehst Du mit einer >> vehementen Konstanz die fast schon beängstigend ist :) > > Naja, wenn Du nur einen Faustkeil zur Verfügung hast, brauchst viele > Arbeitsschritte, machst viele Fehler und verbrauchst u.U. mehr Material, > um ein Handy zu bauen, als wenn Du die richtigen Maschinen verwendest. Oder auch: wer bisher nur einen Faustkeil hatte, wird den Vorteil eines Hammers nicht verstehen, wenn er ihn identisch einsetzt. Er wird sich dann über den störenden Holzstock ärgern. Eigentlich darf's aber jeder machen, wie er's will. (Sie auch) Das gilt für Assembler-Freunde, C-Liebhaber, aber das darf dann bitte auch für die gelten, die lieber C++ benutzen.
Wilhelm M. schrieb: > Misra-C gibt keine Antwort auf die Frage C vs C++. Misra-C und nicht etwa Misra-C++ steht hier in erster Linie für den Standard automobiler Steuergeräte-Software. Deren MC-Bedarf ist wie man weiß nicht ganz unwesentlich. Carl D. schrieb: > Eigentlich darf's aber jeder machen, wie er's will. Das mag ja als salomonisches Urteil durchgehen gibt aber letztlich keine Hilfestellung zum Thema. Den Gläubigen des no-limit abstrakten C++ Himmels auf MCs möchte ich noch zurufen: Manchmal ist weniger mehr, man kann alles auch übertreiben!
Atlas schrieb: > Misra-C und nicht etwa Misra-C++ steht hier in erster Linie für den > Standard automobiler Steuergeräte-Software. Dass es aber mittlerweile ein Misra-C++ überhaupt gibt, zeigt, dass dafür offensichtlich durchaus Bedarf war.
@Atlas Bevor das hier mit dir so weiter geht, würde mich zuerst interessieren, wie gut du überhaupt C++ kennst. Aus deinen Beiträgen heraus lese ich eher, dass du damit nicht wirklich zurecht kommst. Dass C++ nur langsam in der Embedded-Welt ankommt, hängt mMn eher damit zusammen, dass die C++ Compiler, verglichen mit den C-Compilern, eher jung sind. Bis sich das dann in einer schon älteren Firma durchsetzt, dauert das eben etwas. Ich habe das Gefühl, dass tendenziell in kleineren Firmen eher C++ programmiert wird. Wahrscheinlich, weil es in großen Firmen häufig zu viele Personen gibt, die sich dagegen sträuben - mit dem unausgesprochenen Hauptargument, dass sie die Sprache, so hart es klingt, einfach nicht beherschen. Natürlich kann es sinnvoll sein, kleine Projekte in C durchzuführen, weil man weniger qualifizierte Arbeitskräfte einsetzen kann. Wenn man allerdings schon eine entsprechende Codebasis durch andere Projekte in C++ hat, dann zieht das auch nicht mehr. Mit Klassen lässt sich Peripherie wunderbar abstrahieren, und das ohne Overhead, vorausgesetzt man macht es richtig (nicht wie bei Arduino).
Beitrag #5039410 wurde von einem Moderator gelöscht.
AVRler schrieb im Beitrag #5039410: > avr schrieb: >> mit dem unausgesprochenen Hauptargument, dass sie die Sprache, so hart >> es klingt, einfach nicht beherschen > > Weil die Sprache eben doch lernintensiver ist? Selbstverständlich! > Weil viele Entwickler darin für ihre Arbeit keinen Vorteil sehen? Das mag sein - geschieht m.E. aber einfach aus Unkenntnis bzw. dem mangelnden Willen oder der mangelnden Zeit, sich da einzuarbeiten (s. Posts weiter oben). > avr schrieb: >> Mit Klassen lässt sich >> Peripherie wunderbar abstrahieren, und das ohne Overhead, > > Das ist doch ein Märchen. Eben nicht (s.o.: Unkenntnis).
AVRler schrieb im Beitrag #5039410: > Das ist doch ein Märchen. Die periphere Hardware ist dazu viel zu > unterschiedlich. Davon abgesehen benötigt die einfache Peripherie eines > AVRs keine solchen Kopfstände. Naja, wenn ich auf jeder Plattform schon mal das gleiche Interface zu GPIOs und Timern hätte, wäre doch schon viel gewonnen. Ich denke, soetwas kann sehr gut funktionieren, wenn ich meine Bedürfnisse an die Hardware möglichst konkret definieren kann. Wenn ich also eine effektive PWM haben möchte, dann müsste ich das meiner Library so mitteilen. Wenn die Plattform dann peripherals für PWM hat, dann wird das direkt darauf abgebildet. Wenn nicht, wird das halt mit einem Timer umgesetzt. Soetwas kann man mit C++ mit Zero-Overhead Abstraction machen, das ist aber viel Arbeit. Und nein, sagt nicht wieder, dass es nicht geht, wenn ihr C++ nicht kennt.
Hi! Darf ich auch mal? (Öl ins Feuer gießen?) Ich bin nicht nur Arduino Fan, sondern auch noch OOP Fan obendrauf. Damit ist schon mal ganz klar, welche, c oder C++, ich bevorzuge. Davon ab, sind beide Turing vollständig. Also in letzter Instanz gleichwertig. Es ist also eher ein Geschmacksfrage. Und das ist dann der Nährboden für Grabenkriege. In der beruflichen Praxis stellt sich die Frage nur selten. Ein Hobby Programmierer mag sich daran aufgeilen, aber in der Firma/Team wird meist die Firmenlinie verfolgt. Ohne Not davon abweichen? Nö! Mit Recht!
Beitrag #5039493 wurde von einem Moderator gelöscht.
Beitrag #5039537 wurde von einem Moderator gelöscht.
Arduino F. schrieb: > aber in der Firma/Team wird meist die Firmenlinie verfolgt Die muss aber auch mal jemand festlegen. Gelegentlich dürfte sie sich auch ändern, ansonsten würden wohl heute einige große Firmen noch immer alles in FORTRAN programmieren. :) Wie oben schon festgestellt worden ist: in kleinen Firmen dürften solche Änderungen weniger „politischen Wirbel“ verursachen als in großen. Da macht man's einfach, wenn man sich Vorteile davon verspricht.
Beitrag #5039546 wurde von einem Moderator gelöscht.
Beitrag #5039549 wurde von einem Moderator gelöscht.
Beitrag #5039554 wurde von einem Moderator gelöscht.
Beitrag #5039559 wurde von einem Moderator gelöscht.
[ot] Jörg W. schrieb: > Die muss aber auch mal jemand festlegen. Hier mal was zum Thema: "Konservativ" vs." jeden Scheiß mit machen" https://www.youtube.com/watch?v=VdTXdGf4WQQ [/ot]
Beitrag #5039563 wurde von einem Moderator gelöscht.
Beitrag #5039567 wurde von einem Moderator gelöscht.
Beitrag #5039570 wurde von einem Moderator gelöscht.
Beitrag #5039575 wurde von einem Moderator gelöscht.
Beitrag #5039578 wurde von einem Moderator gelöscht.
Beitrag #5039580 wurde von einem Moderator gelöscht.
Beitrag #5039589 wurde von einem Moderator gelöscht.
Beitrag #5039592 wurde von einem Moderator gelöscht.
Beitrag #5039595 wurde von einem Moderator gelöscht.
Beitrag #5039597 wurde von einem Moderator gelöscht.
Beitrag #5039615 wurde von einem Moderator gelöscht.
Beitrag #5039616 wurde von einem Moderator gelöscht.
Beitrag #5039619 wurde von einem Moderator gelöscht.
Beitrag #5039622 wurde von einem Moderator gelöscht.
Beitrag #5039625 wurde von einem Moderator gelöscht.
Beitrag #5039628 wurde von einem Moderator gelöscht.
Beitrag #5039632 wurde von einem Moderator gelöscht.
Beitrag #5039633 wurde von einem Moderator gelöscht.
Beitrag #5039634 wurde von einem Moderator gelöscht.
Beitrag #5039639 wurde von einem Moderator gelöscht.
Beitrag #5039643 wurde von einem Moderator gelöscht.
Beitrag #5039644 wurde von einem Moderator gelöscht.
Beitrag #5039655 wurde von einem Moderator gelöscht.
Beitrag #5039658 wurde von einem Moderator gelöscht.
Beitrag #5039668 wurde von einem Moderator gelöscht.
Karl Käfer schrieb: > Da gibt sich aber jemand Mühe, die Diskussion zu stören. ;-) Wie "stören"? Das sieht hier aus wie das Internet nach dem Netzwerkdurchdringungsgesetz ... :-D
Torsten R. schrieb: > Naja, wenn ich auf jeder Plattform schon mal das gleiche Interface zu > GPIOs und Timern hätte, wäre doch schon viel gewonnen. Ach wo. Gleiche Interfaces sind genau dort von Vorteil, wo man es mit immer wieder gleichartigen Datenströmen zu tun hat, also serielle Interfaces aller Art, SDIO, Grafik-Aufbau in einen Bildspeicher für Display-Aufgaben und dergleichen. Aber schon bei den Timern und noch viel mehr bei den schieren GPIO's hört das komplett auf. Das, was dort stattfindet, ist eigentlich immer derart projektabhängig, daß es absolut kontraproduktiv wäre, dort deinen Gedanken in die Tat umzusetzen. Stattdessen braucht es Treiber, die das jeweilige Problem direkt in eine höhere Ebene umsetzen. Also mal ganz vulgär: nicht "SetzePin(Port,Nummer,Zustand);" sondern "SchalteMotorEin();" Kurzum, der Versuch, auf niedrigster Ebene zu vereinheitlichen, ist unproduktiv. Sowas muß man auf einer angemessenen höheren Ebene machen. W.S.
Torsten R. schrieb: > Naja, wenn ich auf jeder Plattform schon mal das gleiche Interface zu > GPIOs und Timern hätte, wäre doch schon viel gewonnen. STs HAL ist ein Versuch in diese Richtung, zumindest auf STM32. Das reale Ergebnis ist dann, daß man erstens das Datenblatt immer noch lesen muß, um zu verstehen, welche Optionen man genau hat, und sich zweitens auch noch mit der HAL rumschlagen muß. Nicht nur, wie man das benutzen soll, sondern schlimmer noch, wenn man das dann auch noch debuggen muß. Und wehe, man will das dann auch noch plattformübergreifend erweitern. Das wird dann in der Praxis schnell fragmentieren, weil man immer irgendwelche Sachen hat, die mit der Architektur so genau aber gerade nicht gehen. Das erreicht den Punkt, an dem man das wegwerfen kann und schneller mit ein paar Registerzugriffen am Ziel ist. Die Kehrseite von Abstraktion ist Obfuscation. Mir scheint eh, daß es da grundlegend unterschiedliche Denkansätze gibt. Der eine sagt, je mehr Abstraktion, desto besser, und möchte idealerweise reine Mathematik machen. Die grundsätzliche Denkweise ist abstrakt und wird bei Bedarf konkretisiert. Scheint mir typisch für Informatiker zu sein. Der andere möchte das Modell so einfach wie möglich halten, so daß es gerade noch den vorliegenden Fall ausreichend genau annähert. Die grundsätzliche Denkweise ist konkret, und die Modellierung ist nicht Abstraktion, sondern Vereinfachung. Typisch für Ingenieure. Und dann gibt's noch die Physiker, die in jeder Sprache Fortran schreiben.
Beitrag #5039777 wurde von einem Moderator gelöscht.
avr schrieb: > Dass C++ nur langsam in der Embedded-Welt ankommt, hängt mMn eher damit > zusammen, dass die C++ Compiler, verglichen mit den C-Compilern, eher > jung sind. Bis sich das dann in einer schon älteren Firma durchsetzt, > dauert das eben etwas. Ich habe das Gefühl, dass tendenziell in > kleineren Firmen eher C++ programmiert wird. Wahrscheinlich, weil es in > großen Firmen häufig zu viele Personen gibt, die sich dagegen sträuben - > mit dem unausgesprochenen Hauptargument, dass sie die Sprache, so hart > es klingt, einfach nicht beherschen. Na, wer würde schon zu seinem Chef so etwas sagen wie "jetzt nochmal nicht nur eine ganz neue Sprache, sondern sogar ein ganz neues Paradigma lernen, och nö, lieber nicht". Also mein Vorgesetzer würde mich dann nicht ganz zu Unrecht fragen, ob ich wohl noch alle Tässchen im Schränkchen habe. Deswegen wird dann lieber ausgewichen auf "ach nö, Chef, das kostet enorme Ressourcen, dafür brauchen wir größere und teurere Controller und müßten außerdem unsere ganze bewährte Codebasis umbauen". Im Zweifelsfall kann man sogar schnell ein Beispielchen mit Exceptions, dynamischer Polymorphie und ähnlichen Schmankerln bauen, und seine Aussagen damit "beweisen". Was höre ich da, das klänge jetzt arg konstruiert? Ja, ist es, aber leider habe ich solche Vermeidungs- und Verweigerungsstrategien schon erlebt, bei Kollege und auch bei Vorgesetzten. "Das hamwer immer schon so jemacht" ist doch immer wieder ein starkes Argument.
Beitrag #5039831 wurde von einem Moderator gelöscht.
Nop schrieb: > Torsten R. schrieb: > >> Naja, wenn ich auf jeder Plattform schon mal das gleiche Interface zu >> GPIOs und Timern hätte, wäre doch schon viel gewonnen. > > STs HAL ist ein Versuch in diese Richtung, zumindest auf STM32. Das > reale Ergebnis ist dann, daß man erstens das Datenblatt immer noch lesen > muß, um zu verstehen, welche Optionen man genau hat, und sich zweitens > auch noch mit der HAL rumschlagen muß. Nicht nur, wie man das benutzen > soll, sondern schlimmer noch, wenn man das dann auch noch debuggen muß. > > Und wehe, man will das dann auch noch plattformübergreifend erweitern. > Das wird dann in der Praxis schnell fragmentieren, weil man immer > irgendwelche Sachen hat, die mit der Architektur so genau aber gerade > nicht gehen. > > Das erreicht den Punkt, an dem man das wegwerfen kann und schneller mit > ein paar Registerzugriffen am Ziel ist. > > Die Kehrseite von Abstraktion ist Obfuscation. Mir scheint eh, daß es da > grundlegend unterschiedliche Denkansätze gibt. Eigentlich ist kein einziger Chiphersteller daran interessiert vernünftige Bibliotheken anzubieten. Bibliotheken bringen kein Geld und verkaufen keine Hardware. Umso flexibler so eine Bibliothek wäre, umso einfacher wäre ein Port zu einem Fremdprozessor. Eine quasi platformübergreifende Lösung entspräche einem Supergau, da man plötzlich an Konkurrenten, die 0.0001c billiger verkaufen können bereits Kunden verliert... Es ist ja nicht so als wäre ARM nicht bemüht dem entgegenzuwirken. Man versucht mit Dingen wie CMSIS und mbed zu kontern wo es nur geht. Es gibt das SVD Format zur Hardware Beschreibung und sogar Code-Gen Tools für zig-tausende Zeilen lange Header. Die Realität sieht dann so aus, dass etwa ST nicht einmal innerhalb von winzigen Prozessorfamilien (z.B. L4) jene SVD Files und Header konstant hält. Da wird gepfutscht und gepatzt wo es nur geht, mit Sicherheit mangels Interesse und vielleicht sogar aus schlichtem Kalkül. Obwohl mbed zugegebenermaßen eher die IoT Seite anspricht und nicht die "Hardcore"-Embedded Seite, so ist alles über dem setzen eines GPIO Pins ein Krampf... da bekommt man dann ungefähr ein Gefühl dafür, wie ernst es Chiphersteller mit Software-Unterstützung sehn.
Kenuino F. schrieb: > Hi! > > Darf ich auch mal? > (Öl ins Feuer gießen?) <cite> : Everybody I know, whether it’s personal or corporate, selects a subset and these subsets are different. So it’s not a good language to transport an algorithm—to say, “I wrote it; here, take it.” It’s way too big, way too complex. : – Ken Thompson, interviewed about C++ for the book Peter Seibel, Coders at work , Apress, 2009 </cite> Trotz des Zitats bin ich nicht vorbehaltslos nur pro-C; aber wo er Recht hat, hat der alte Bartträger ins Schwarze getroffen.
>> Da gibt sich aber jemand Mühe, die Diskussion zu stören. ;-) > > Wie "stören"? Das sieht hier aus wie das Internet nach dem > Netzwerkdurchdringungsgesetz ... :-D oder die Moderatoren waren wiedermal nicht mit dem selbst gewählten Automatismus zufrieden und haben von Hand den GarbageCollector angeschubst.
Beitrag #5039852 wurde von einem Moderator gelöscht.
Beitrag #5039854 wurde von einem Moderator gelöscht.
W.S. schrieb: > Gleiche Interfaces sind genau dort von Vorteil, wo man es mit immer > wieder gleichartigen Datenströmen zu tun hat, also serielle Interfaces > aller Art, SDIO, Grafik-Aufbau in einen Bildspeicher für > Display-Aufgaben und dergleichen. Das sowieso. > Aber schon bei den Timern und noch viel mehr bei den schieren GPIO's > hört das komplett auf. Das, was dort stattfindet, ist eigentlich _immer_ > derart projektabhängig, daß es absolut kontraproduktiv wäre, dort deinen > Gedanken in die Tat umzusetzen. Stattdessen braucht es Treiber, die das > jeweilige Problem direkt in eine höhere Ebene umsetzen. > > Also mal ganz vulgär: > nicht "SetzePin(Port,Nummer,Zustand);" > sondern "SchalteMotorEin();" ...oder eben: "motor.einschalten();". Das läßt sich mit einfacher Vererbung ganz einfach, elegant und kostenlos umsetzen. Das bedarf nur einer simplen Elternklasse, die einen Pin abstrahiert -- und ist dann mit einer anderen Elternklasse, die dasselbe Interface auf einer anderen Controllerfamilie implementiert, sogar portabel.
:
Bearbeitet durch User
Beitrag #5039861 wurde von einem Moderator gelöscht.
Beitrag #5039868 wurde von einem Moderator gelöscht.
Beitrag #5039872 wurde von einem Moderator gelöscht.
Sheeva P. schrieb: > ...oder eben: "motor.einschalten();". Das läßt sich mit einfacher > Vererbung ganz einfach, elegant und kostenlos umsetzen. Es läßt sich auch ohne Vererbung einfach, elegant und kostenlos umsetzen. KISS und YAGNI gilt auch für Tools.
Nop schrieb: > Sheeva P. schrieb: > >> ...oder eben: "motor.einschalten();". Das läßt sich mit einfacher >> Vererbung ganz einfach, elegant und kostenlos umsetzen. > > Es läßt sich auch ohne Vererbung einfach, elegant und kostenlos > umsetzen. KISS und YAGNI gilt auch für Tools. Was ist an Vererbung kompliziert? Naja, es geht ja auch ohne: durch Komposition und generische Typen. Ist aber wohl auch zu kompliziert ...
Beitrag #5039899 wurde von einem Moderator gelöscht.
Wilhelm M. schrieb: > Was ist an Vererbung kompliziert? Wieder ein Konzept mehr, das man nicht braucht, also weg damit. Zudem baut man sich dann nicht mit Diamant-Hierarchien in die Ecke. Hauptnachteil ist, daß man nicht stundenlang beim Käffchen über Scheinprobleme wie is-a vs. has-a debattieren kann. > Naja, es geht ja auch ohne: durch Komposition und generische Typen. Braucht man auch nicht, um einen Motor einzuschalten.
Peter Gerlich schrieb im Beitrag #5039861: > avr schrieb: >> lässt sich wunderbar abstrahieren > > ungleich > > Torsten R. schrieb: >> kann man mit C++ ... machen, das ist aber viel Arbeit Für dich gibt es auch nur schwarz und weiß? Mit C++ hat man ein mächtiges Werkzeug zur Abstraktion, vieles kann man sogar zur Compilezeit machen. Natürlich hängt der Arbeitsaufwand mit dem Abstraktionsgrad zusammen. Eine einfache Klasse, welche ein Peripheriebaustein eines speziellen Controllers abstrahiert ist deshalb nicht übermäßig schwer. Wobei ich mich frage, wie man überhaupt auf diesen Zug kommen kann. Abstraktion ist ebenso in C möglich. Und auch dort kann man es übertreiben. Da wird es jedoch sehr viel schneller hässlich, wo es in C++ noch elegante Möglichkeiten gibt. Unter anderem auch, weil das sehr mächtige Templatesystem in C nicht vorhanden ist. => Ein Vorteil von C++ ist nicht die Abstraktion, sondern die Möglichkeit deutlich besser und eleganter abstrahieren zu können. Und so lange hier keine widerspricht bleibe ich bei der Behauptung, dass die meisten C++-Kritiker hier mit der Sprache Probleme haben. Und zwar nicht mit der Syntax, sondern mit den Paradigmen. Denn die Argumente hier sind nur noch zu schwer, zu komplex, braucht man nicht oder irgendwelche Mythen der Overhead. @Nop Du bestätigst mich gerade. Wenn man OOP nicht kennt, dann kann man sie auch nicht brauchen. Wenn man sie als sinnvolles Paradigma akzeptiert, erkennt man auch einen Mehrwert in C++.
Sheeva P. schrieb: > oder eben: "motor.einschalten();". Das läßt sich mit einfacher > Vererbung ganz einfach, elegant und kostenlos umsetzen. Das bedarf nur > einer simplen Elternklasse, die einen Pin abstrahiert -- und ist dann > mit einer anderen Elternklasse, die dasselbe Interface auf einer anderen > Controllerfamilie implementiert, sogar portabel. Aber genau dass geht in C genauso gut. In C++ gibt es halt nur mehr (Austrucks-)Möglichkeiten, die im Zweifel auch performanter sind. Nur sind sie halt nicht immer so gut lesbar und jeder favorisiert einen anderen Ansatz.
Beitrag #5039908 wurde von einem Moderator gelöscht.
Nop schrieb: > Wilhelm M. schrieb: > > >> Naja, es geht ja auch ohne: durch Komposition und generische Typen. > > Braucht man auch nicht, um einen Motor einzuschalten. Klar, geht ja auch mit dem Faustkeil (s.o.).
Beitrag #5039911 wurde von einem Moderator gelöscht.
Achim S. schrieb: > Sheeva P. schrieb: >> oder eben: "motor.einschalten();". Das läßt sich mit einfacher >> Vererbung ganz einfach, elegant und kostenlos umsetzen. Das bedarf nur >> einer simplen Elternklasse, die einen Pin abstrahiert -- und ist dann >> mit einer anderen Elternklasse, die dasselbe Interface auf einer anderen >> Controllerfamilie implementiert, sogar portabel. > > Aber genau dass geht in C genauso gut. In C++ gibt es halt nur mehr > (Austrucks-)Möglichkeiten, die im Zweifel auch performanter sind. Woher nimmst Du diese Behauptung???
Ach ja, wo OOP wirklich Sinn ergibt, das ist, wenn man nicht eingebildete Pseudo-Objekte baut, nur um OOP zu machen, sondern wenn tatsächlich dynamisch Objekte erzeugt werden und verschwinden, die auch tatsächlich eigenes Benehmen haben. Simulationen sind da wichtig (da kommt OOP ja her), und damit auch heutige Spiele, weil die einzelnen Elemente jedes für sich agieren und entstehen sowie verschwinden können. Und natürlich GUIs, wo das genauso ist. Aber Motoren und ihre Pins sind, wo sie sind, und da bleiben sie auch. Motoren entstehen nicht dynamisch und verschwinden wieder. Gaspedale und Bremsen auch nicht.
Beitrag #5039919 wurde von einem Moderator gelöscht.
Nop schrieb: > Ach ja, wo OOP wirklich Sinn ergibt, das ist, wenn man nicht > eingebildete Pseudo-Objekte baut, nur um OOP zu machen, sondern wenn > tatsächlich dynamisch Objekte erzeugt werden und verschwinden, die auch > tatsächlich eigenes Benehmen haben. Sag mal, liest Du überhaupt die Beiträge hier? OOP im engeren Sinn ist zwar ein Möglichkeit, ich habe aber oben schon zigmal gesagt, dass andere Konzeote viel wichtiger sind. Mittlerweile denke, Du weißt gar nicht, was bestimmte Begriffe bedeuten ... > Aber Motoren und ihre Pins sind, wo sie sind, und da bleiben sie auch. > Motoren entstehen nicht dynamisch und verschwinden wieder. Gaspedale und > Bremsen auch nicht. Genau! Wie gesagt, OOP im engeren Sinn ist nicht das Einzige, was C++ beherrscht (s.o, x-te Iteration).
Beitrag #5039931 wurde von einem Moderator gelöscht.
Beitrag #5039933 wurde von einem Moderator gelöscht.
Beitrag #5039934 wurde von einem Moderator gelöscht.
Beitrag #5039936 wurde von einem Moderator gelöscht.
Beitrag #5039939 wurde von einem Moderator gelöscht.
Nop schrieb: > sondern wenn > tatsächlich dynamisch Objekte erzeugt werden und verschwinden, die auch > tatsächlich eigenes Benehmen haben. OOP hat erst mal nichts mit dem Erzeugen von Objekten zu tun. Es kann auch alles statisch bleiben. Und daher kann man auch einen UART wunderbar in eine statische Klasse stecken. Wenn man möchte, kann diesem UART durch Vererbung beliebige Features hinzufügen (Puffer, Protokolle) und diese Klasse beliebig oft verwenden. Wenn einem das nicht passt, kann man auch in C++ ohne OO programmieren und freut sich z.B. über Templates, welche Berechnungen zur Compilezeit durchführen oder was auch immer.
avr schrieb: > Nop schrieb: >> sondern wenn >> tatsächlich dynamisch Objekte erzeugt werden und verschwinden, die auch >> tatsächlich eigenes Benehmen haben. > > OOP hat erst mal nichts mit dem Erzeugen von Objekten zu tun. Es kann > auch alles statisch bleiben. Und daher kann man auch einen UART > wunderbar in eine statische Klasse stecken. Wenn man möchte, kann diesem > UART durch Vererbung beliebige Features hinzufügen (Puffer, Protokolle) > und diese Klasse beliebig oft verwenden. Wenn einem das nicht passt, > kann man auch in C++ ohne OO programmieren und freut sich z.B. über > Templates, welche Berechnungen zur Compilezeit durchführen oder was auch > immer. Auch das habe ich schon x-mal hier geschrieben, nur mich beschleicht das Gefühl, dass nicht verstanden wird, was z.B. constexpr-lambdas sind ...
Beitrag #5039955 wurde von einem Moderator gelöscht.
Wilhelm M. schrieb: > Genau! Wie gesagt, OOP im engeren Sinn ist nicht das Einzige, was C++ > beherrscht (s.o, x-te Iteration). Ja, die Modewellen macht C++ alle mit. Vererbung war der Hype in den 90ern, heute werden dem C++11-beinigen Octopus auch noch funktionale Konzepte reingenagelt. Und der Scope wächst, wächst und wächst. Ich ziehe es vor, wenn ich direkt Zeile für Zeile lesen kann, was genau der Code tut, besonders wenn er nicht von mir ist. Das ist bei C++ schon wegen der Fragmentierung problematisch. Außer natürlich für die Profis des Forums, die die C++-Standards von 1998 bis 2017 zu 100% beherrschen, STL und Boost ebenso, mitsamt den Nuancen für diverse FAST identische Wege, dasselbe zu erreichen, aber die stets den richtigen nehmen. Die Realität: MISRA-C wurde geschaffen, weil sogar der C-Standard zu komplex ist. Und wieso hat man die Leute nicht einfach alle rausgeworfen, C-Programmierer sollte es doch erst recht geben? Weil das Domänenwissen das Entscheidende ist und nicht das Programmieren.
Beitrag #5039959 wurde von einem Moderator gelöscht.
Beitrag #5039961 wurde von einem Moderator gelöscht.
Nop schrieb: > Sheeva P. schrieb: > >> ...oder eben: "motor.einschalten();". Das läßt sich mit einfacher >> Vererbung ganz einfach, elegant und kostenlos umsetzen. > > Es läßt sich auch ohne Vererbung einfach, elegant und kostenlos > umsetzen. KISS und YAGNI gilt auch für Tools. Kostenlos, Kunststück, wenn C die Kostenreferenz ist, einfach auch, solange man nur diese einfache Instruktion betrachtet, aber... elegant? Es ist ganz sicher auch eine Frage des persönlichen Empfindens (und der Fähigkeiten und Kenntnisse) aber für mich sieht "SchalteMotorEin()" eher unelegant aus. Die unnatürlichen Bandwurmworte unterstützen den Lesefluß jedenfalls nicht. Aber, weißt Du, ich glaube wir nähern uns dem Kern der Mißverständnisse zwischen uns beiden, den de facto ist die Vererbung extrem einfach, so man sie einmal verstanden hat. Daß Du sie als kompliziert ansiehst, läßt mich vermuten, daß das bei der -- warum auch immer -- nicht der Fall ist. Wenn meine Vermutung zutrifft, dann ist klar, warum wir immer an einander vorbei reden: weil ich C++ kenne und seine äußerst positiven Effekte in diversen Umgebungen ausnutze, während das bei Dir nicht der Fall ist und Du zuerst nur die Lernhürde siehst, die Du zuvor einmal überwinden müßtest, um die positiven Effekte kennenzulernen -- und weil Du mir nicht glauben willst, daß es diese positiven Effekte gibt und daß sie groß genug sind, um die nötige Lerninvestition sehr schnell zu amortisieren. Was ich dann allerdings nicht verstehe, ist, warum Du nicht einfach bei Deiner Lieblingssprache bleibst und die C++-Freunde ihr Ding machen läßt, sondern explizit gegen C++ und damit gegen etwas argumentierst, das Du im Grunde genommen gar nicht beurteilen kannst (und willst). Darauf deutet jedenfalls auch hin, daß Du so gar keine eigenen Sachargumente in diese Diskussion eingebracht hast, sondern immer wieder auf andere verweist und Dich ansonsten auf die Behauptung zurückziehst, C++ sei (zu) kompliziert. Naja, nichts für ungut, vielleicht liege ich ja auch flashc. Dann würden mich Deine sachlichen Argumente allerdings umso brennender interessieren.
Beitrag #5039964 wurde von einem Moderator gelöscht.
Beitrag #5039970 wurde von einem Moderator gelöscht.
Beitrag #5039973 wurde von einem Moderator gelöscht.
Wilhelm M. schrieb: > Aber genau dass geht in C genauso gut. In C++ gibt es halt nur mehr >> (Austrucks-)Möglichkeiten, die im Zweifel auch performanter sind. > > Woher nimmst Du diese Behauptung??? welche meinst Du? Dass die Abstrahierung von motor.einschalten() in C genauso gut geht? weil ich es so mache. Kann ich Dir gerne konkrete Beispiele liefern Dass es mehr Ausdrucksmöglichkeiten in C++ gibt? Das ist doch gerade die Quintessenz der Diskussion hier. Das es in C++ im Zweifel performanter ist? Weil die meisten Ausdrucksmöglichkeiten zur Compilezeit in nichts zerfallen. Im Video oben von Dan Saks über C++ zeigt er auch genau das. (Da. wo inline in beiden Sprachen das Optimum ist).
Beitrag #5039980 wurde von einem Moderator gelöscht.
Nop schrieb: > Wilhelm M. schrieb: > >> Genau! Wie gesagt, OOP im engeren Sinn ist nicht das Einzige, was C++ >> beherrscht (s.o, x-te Iteration). > > Ja, die Modewellen macht C++ alle mit. Vererbung war der Hype in den > 90ern, heute werden dem C++11-beinigen Octopus auch noch funktionale > Konzepte reingenagelt. Und der Scope wächst, wächst und wächst. Wir haben 2017 und OOP gibt es immer noch: 27 Jahre nach Deiner Rechnung (eigentlich schon viel älter) - ist das noch ein Hype oder hat das seine Gründe. Aber: OOP im engeren Sinn (etwas anderes scheinst Du nicht zu kennen) ist nicht das Mittel der Wahl für µC (aus ganz verschiedenen Gründen). > Ich ziehe es vor, wenn ich direkt Zeile für Zeile lesen kann, was genau > der Code tut, besonders wenn er nicht von mir ist. Ok, das spricht eigentlich für Assembler, oder? > Das ist bei C++ schon > wegen der Fragmentierung problematisch. Was bezeichnest Du als Fragmentierung?
Nop schrieb: > Wilhelm M. schrieb: > >> Was ist an Vererbung kompliziert? > > Wieder ein Konzept mehr, das man nicht braucht, also weg damit. Du hast Recht: man braucht das Konzept nicht, genauso, wie man keine Spül- und keine Wachmaschine braucht. Diese Dinge machen das Leben zwar in vielen Bereichen wesentlich einfacher und müheloser, aber Du kannst natürlich gern auf diese Annehmlichkeiten verzichten. Warum Du dann allerdings andere dazu bringen willst, ebenfalls zu verzichten, bleibt wohl Dein Geheimnis. > Zudem baut man sich dann nicht mit Diamant-Hierarchien in die Ecke. > Hauptnachteil ist, daß man nicht stundenlang beim Käffchen über > Scheinprobleme wie is-a vs. has-a debattieren kann. Schon wieder diese konstruierten Probleme -- beides ist mir in > 20 Jahren objektorientierter Softwareentwicklung noch nie passiert.
Achim S. schrieb: > Wilhelm M. schrieb: >> Aber genau dass geht in C genauso gut. In C++ gibt es halt nur mehr >>> (Austrucks-)Möglichkeiten, die im Zweifel auch performanter sind. >> >> Woher nimmst Du diese Behauptung??? > > welche meinst Du? Ups, hatte Dich so verstanden, das Du C im Vorteil siehst. Mein Fehler ...
Beitrag #5039987 wurde von einem Moderator gelöscht.