Hallo zusammen, ich bin einen C++ Programmierer und vor kurzen habe ich die Aufgabe bekommen in Embedded Bereich einzusteigen. In C Bereich habe ich während das Studium mit einem Atmega 8 was gemacht aber das war vor 10 jahre. Meine Frage an euch: Lohnt es sich überhaupt in C Welt was zu machen oder soll ich weiterhin embedded mit C++ programmieren? Wie ist eure Erfahrung mit C++ in Embeddedwelt? danke
ManuelGast schrieb: > Wie ist eure Erfahrung mit C++ in Embeddedwelt? Definieren "Embeddedwelt"? Meinst du damit einen Attiny mit 4k Flash oder einen Rechenboliden mit Linux?
> Definieren "Embeddedwelt"?
Und definiere "lohnen"! :-)
Es ist intellektuell eine Verbesserung wenn man auch Embedded in C++
programmiert, besonders wenn man es schon kann und dann einfacher lernt
was man nicht machen sollte.
Aber 95% aller Programme im Bereich Embedded duerften in C geschrieben
sein, 50% der Programmierer duerften nur C koennen und weitere 40%
duerften behaupten C++ zu koennen, programmieren darin aber nur C. Von
daher scheint es eher lohnenswert nur C zu programmieren weil die du
damit Kollegen und Projektkompatibel wirst.
Olaf
ManuelGast schrieb: > Meine Frage an euch: Lohnt es sich überhaupt in C Welt was zu machen > oder soll ich weiterhin embedded mit C++ programmieren? Kommt auf die Plattform an ... C++ verwendet viel dynamische allozierten Speicher und das funktioniert auf Plattformen ohne richtiger Speicherverwaltung nicht. Außerdem ist zB die STL Library zu groß, als dass man sie sinnvoll auf zB einem ATMEGA8 verwenden könnte. Ich würde sage, sobald man ein richtiges Betriebssystem (wie zB Linux) hat, kann man sich in vollem Umfang in C++ austoben.
Lothar M. schrieb: > Definieren "Embeddedwelt"? Na ganz einfach. Das Gegenteil von ManuelGast schrieb: > in C Welt SCNR
ManuelGast schrieb: > Lothar M. schrieb: >> Definieren "Embeddedwelt"? > > genau gesagt der STM32 Ich vermute daher kein Linux? Wie geschrieben, kannst du machen, du musst aber auf alles verzichten, was dynamisch allozierten Speicher verwendet.
ManuelGast schrieb: > Wie ist eure Erfahrung mit C++ in Embeddedwelt? Bin, als Arduino Fan, eng mit C++ verbandelt. Persönlich, eigentlich eher mit der OOP. Egal, welche Sprache. Nutze die Vorteile von C++ möglichst weitgehend. Trotzdem sehen die Programme am Ende oft sehr C artig aus. Viele Features von C++ (z.B. die STL) huddeln viel mit Speicher rum. Auch new vermeide ich weitestgehend. Also "C++ in Embeddedwelt" ein klares JA, von mir! Die kostenlosen Features mitnehmen. Vorsicht mit der dynamischen Speicherverwaltung! (aber das gilt für c genau so)
Arduino F. schrieb: > Nutze die Vorteile von C++ möglichst weitgehend. Du meinst die Subklasse von C++, die für den Arduino implementiert ist? Oder gibt es da auch Exceptions und Typinformationen zur Laufzeit? Ich verweise mal auf https://www.mikrocontroller.net/articles/C_vs_C%2B%2B
ManuelGast schrieb: > Meine Frage an euch: Lohnt es sich überhaupt in C Welt was zu machen > oder soll ich weiterhin embedded mit C++ programmieren? Ja, allein schon wegen Namespaces und typensichere Enums. Deswegen benutze ich auch für kleine µC den C++-Compiler. Aber ansonsten sehen meine C++-Programme meistens aus wie normales C. C++ bietet einiges was bereits zur Kompilezeit aufgelöst wird und somit keinen negativen Effekt auf die Programmlaufzeit hat.
Lothar M. schrieb: > Du meinst die Subklasse von C++, die für den Arduino implementiert ist? Nein! Es gibt keine "Subklasse von C++, die für den Arduino implementiert ist". Arduino nutzt z.Zt. C++11. Und das ist doch recht aktuell, und recht vollständig implementiert. Aus meiner Sicht ist das fehlen der STL kein Manko der Sprache an sich. Sondern findet seine Ursache in den begrenzten Ressourcen der µC, gegenüber eines PC. Ich meine eher: Templates using statt typedef gleichnamige Funktionen/Methoden, mit unterschiedlicher Parametersignatur Das überladen von Operatoren der weitgehende Verzicht auf defines/Macros Da lassen sich sicherlich noch mehr Punkte aufführen, welche nette Features sind, und dabei keinen Speicher fressen. Und ja, ich stopfe alles in Klassen, soweit mir möglich.
Mampf F. schrieb: > ManuelGast schrieb: >> Lothar M. schrieb: >>> Definieren "Embeddedwelt"? >> >> genau gesagt der STM32 > > Ich vermute daher kein Linux? > > Wie geschrieben, kannst du machen, du musst aber auf alles verzichten, > was dynamisch allozierten Speicher verwendet. Würde ich so nicht sagen. Ich hab hier einen STM32F4 mit 192 kB RAM. Das ist durchaus genug, um auch mit dynamischem Speicher sinnvoll arbeiten zu können. Aber man kann auch schon viele C++-Features verwenden, ohne dazu dynamischen Speicher zu benötigen. Ich finde C++ dort durchaus sinnvoll, allerdings ist es auch richtig, dass in der Praxis kaum jemand µCs in C++ programmiert. Lothar M. schrieb: > Arduino F. schrieb: >> Nutze die Vorteile von C++ möglichst weitgehend. > Du meinst die Subklasse von C++, die für den Arduino implementiert ist? Vermutlich das, was der g++ für den AVR zur Verfügung stellt, denn den nutzt Arduino. > Oder gibt es da auch Exceptions und Typinformationen zur Laufzeit? Eher nicht. Als ich mir das das letzte mal angeschaut habe, ging das nicht, weil die libsupc++ nicht für den AVR geeignet war. Aber man muss ja auch nicht zwingend alle Features von C++ verwenden, um einen Nutzen gegenüber C zu haben.
Lothar M. schrieb: > Definieren "Embeddedwelt"? > Meinst du damit einen Attiny mit 4k Flash oder einen Rechenboliden mit > Linux? Spielt das denn eine Rolle?
Mampf F. schrieb: > Kommt auf die Plattform an ... C++ verwendet viel dynamische allozierten > Speicher Nein. Es ist nicht C++, das dynamische Speicherallokation benutzt, sondern der jeweilige Programmierer benutzt sie -- oder eben nicht. > Ich würde sage, sobald man ein richtiges Betriebssystem (wie zB Linux) > hat, kann man sich in vollem Umfang in C++ austoben. Das ist zwar durchaus richtig, aber man kann viele Vorzüge von C++ auch ohne Betriebssystem nutzen -- auch auf kleinen Controllern.
Sheeva P. schrieb: > Das ist zwar durchaus richtig, aber man kann viele Vorzüge von C++ auch > ohne Betriebssystem nutzen -- auch auf kleinen Controllern. So sehe ich das auch! Man muss ja nicht, nur weil man einen Ferrari unter dem Arsch hat, mit 360km/h durch jedes Wohngebiet preschen. (Tipp: Nicht alles was hinkt, ist ein Vergleich.)
ManuelGast schrieb: > Wie ist eure Erfahrung mit C++ in Embeddedwelt? Ich nutze C++ laufend für z.B. Cortex M / ARM Controller. Man muss wissen, was welches C++ feature kostest und es gibt ein paar Ecken und Kanten mit der Toolchain. Aber nichts was einem daran hindert, C++ sinnvoll einzusetzen. Tipp: https://www.gitbook.com/book/arobenko/bare_metal_cpp/details
Ein mächtiger C++ Werkzeugkasten mit vielen Beispielen für diverse ARM | AVR | XMega | MSP430 - Mikrocontroller ... https://github.com/KonstantinChizhov/Mcucpp
Ich benutze auch lieber C++ / OOP, gerade die Hardwarekomponenten lassen sich sehr schön als Objekte darstellen. Teure Sachen wie RTTI und exceptions lässt man einfach weg, das kann man per Compilerschalter abklemmen. Auch 'new' oder 'malloc' würde ich nicht per se verteufeln, man muss nur aufpassen das man nicht mit hoher Frequenz unterschiedlich grosse Speicherblöcke holt/freigibt. Wenn man in der Initialisierung benötigten Speicher holt und leben lässt ist das überhaupt kein Problem. Dann lassen sich statisch angelegte Arrays mit irgendwelchen Limits vermeiden.
Auf Mikrocontrollern sind wesentliche Teile von C++ nicht empfehlenswert, wegen der Speicherverwaltung und Performance. Templates mag ich persönlich nicht (verwirren mich) und Operatorüberladung nutze ich nur sehr spärlich weil ich sprechende Methoden-namen bevorzuge. Deswegen bleibt für mich von C++ nicht mehr viel brauchbares übrig. Eigentlich nur die Objekte und die meisten davon sind wiederum Singletons. Wobei man auch in C objektorientiert programmieren kann. Manchmal nutze ich C++ auf Mikrocontrollern und es klappt auch gut. Aber C ist auch gut. Libraries für Schnittstellen bevorzuge in C, weil man diese Problemlos in beiden Sprachen einsetzen kann. Die Standard C++ Library ist für mich auf µC jedenfalls Tabu. Für AVR steht sie ohnehin nicht zur Verfügung, soweit ich weiß.
Wenn man in einem Team steckt, wird man sich an die Firmen/Team Ausrichtung halten müssen. Als Hobbybastler ist man da freier. Ich schätze mal, dass die Programme, welche man in seiner Lieblingssprache schreibt, im allgemeinen besser gelingen. Sei es C, oder C++, oder noch ganz was anderes. Das ultimative KO Kriterium ist immer wieder: Erfüllt die Anwendung die gestellten Anforderungen?
Arduino F. schrieb: > Wenn man in einem Team steckt, wird man sich an die Firmen/Team > Ausrichtung halten müssen. > > Als Hobbybastler ist man da freier. > Ich schätze mal, dass die Programme, welche man in seiner > Lieblingssprache schreibt, im allgemeinen besser gelingen. > Sei es C, oder C++, oder noch ganz was anderes. > > Das ultimative KO Kriterium ist immer wieder: > Erfüllt die Anwendung die gestellten Anforderungen? Das sehe ich ganz ähnlich, daher hab ich eigentlich immer C im Einsatz. Ich sehe für mich am Bastler-Tisch keine Notwendigkeit/Vorteil, C++ einzusetzen. Und in der Firma ist es ähnlich. Egal für welche Programmiersprache (ASM, C, C++, Bascom) man sich entscheidet, man muss sich einen roten Faden definieren und dann kommt man eigentlich mit Sprache auch zurecht.
Vielleicht auch einfach mal hier schauen: Beitrag "Informationen zu C vs C++ / aka Futter für die Diskussion"
[1] In C ist es "einfach", Programme zu schreiben, die compiliert werden können, aber sich zur Laufzeit falsch verhalten. [2] In C++ "kann" man so programmieren, dass Programme, die die einfachen Fehler aus [1] enthalten, nicht compiliert werden können. Ich bevorzuge [2]: Compile-Zeit Fehler sind mit lieber als Laufzeit-Fehler ... (... und ohne Overhead zu erzeugen ...)
:
Bearbeitet durch User
C++ fängt vielleicht ein paar Anfängerfehler mehr ab als C aber im Endeffekt sehe ich da keinen großen Gewinn. Besonders wenn man nur statische und automatische Objekte hat.
Die "STL" ist eine von SGI in den 90ern entwickelte Bibliothek für C++. Diese wird kaum noch verwendet. Ihr meint wahrscheinlich die "C++ Standard Library", welche von der STL beeinflusst, aber nicht identisch und viel größer ist. Nur ein kleiner Teil dieser Bibliothek besteht aus Containern, und auch denen könnte man per Allokator die dynamische Speicherverwaltung abgewöhnen. Den Großteil kann man ganz problemlos auch auf Mikrocontrollern verwenden. Was spricht z.B. gegen die Nutzung von "uint32_t"? Oder von "std::numeric_limits"? Oder "std::max"? Letzteres ist z.B. etwas, das in C so nicht möglich wäre. templates ermöglichen ganz neue Arten der Programmstruktur, sind aber etwas schwer lesbar. Ich durfte leider feststellen, dass wenn man Leuten gratis ein Embedded Programm anbietet, die dann nur daran herum kritteln dass es C++ ist. C++ scheint die Emotionen derart hoch kochen zu lassen, dass die Sicht auf die Funktionalität versperrt wird. Das ist ein Nachteil...
:
Bearbeitet durch User
Beruflich programmiere, bzw skripte, ich hauptsächlich objektorientiert. Daher nutze ich diesen Ansatz auch gerne bei privaten Projekten. Objektverschachtelung und Namensräume, wie auch das sinnvolle überladen von Operatoren macht meiner Ansicht nach, das Programm lesbarer. Auch direkt mit Objekten, ohne Zeigerschlacht arbeiten zu können ist von Vorteil. Auch wenn es nur für mich ist, möchte ich den Code später noch ohne große Einarbeitungszeit lesen können. In C muss ich mich hier öfters verrenken. Ich modifiziere aber auch öfters existierenden Code (privat habe ich nicht so viel Zeit, das Programm immer selber komplett neu zu schreiben). Dann verwende ich die Ursprungssprache, was nicht zwingend immer C sein muss. Wenn ein Arduino-Programm meine Bedürfnisse deckt, nehme ich auch das als Grundlage.
Folgende Punkte sind m.E. zu berücksichtigen, und zwar ganz unabhängig von der Sprache: 1) Sattelfestheit in der Sprache Man sollte in der Sprache möglichst sattelfest sein. Wissen über die Sprache stützt sich auf Wissen über die Sprache und deren Spezifikation und nicht auf Reverse-Engineering (Debugging, Simulation, Trial & Error). Das "Man" schließt hier alle Entwickler ein, also auch diejenigen, die Reviewing und Testing durchführen (insbesondere bei White-Box Testing) und schließlich mit der Wartung der Software betraut werden. 2) Verfügbarkeit und Support der Sprache. Wie sieht die Entwicklungsumgebung aus: Gibt es professionellen Support, etwa wenn ein Bug im Compiler oder den Standard-Bibliotheken gibt? Wie sieht es aus mit Debugger, Simulator, Tools zur statischen Analyse? 3) Umfeld Wer wir den Code pflegen und wer führt Reviews durch? Nur dass eine Sprache mehr Features zur Verfügung stellt, bedeutet noch nicht, dass man diese adäquat nutzen kann und daraus wartbarer Code entsteht. Selbst wenn ein Sprachvirtuose die Software komponiert, besteht die Gefahr, dass die Software als "unwartbar" eingestuft wird, in der Tonne landet und neu aufgezogen wird, sobald der Virtuose nicht mehr verfügbar ist. (Manchmal wird das dann so gelesen, Virtuosität sei ein Vehikel, um sich "unersetzlich" zu machen). Kernighan: Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. 4) Wartbarkeit Verfügbarkeit einer Vielzahl von Paradigmen / Features muss nicht unbedingt ein Vorteil sein. Die Wartbarkeit hängt nicht nur von der Sprache ab, sondern vor allem auch vom Design: In einer "alten" Sprache kann man sehr wohl ein guten Design haben, und eine "neue" Sprache schützt nicht vor schlechtem Desig. 5) Embedded Man braucht eine recht konkrete Vorstellung davon, welcher Code generiert wird — je eingeschränkter die Systemresourcen (Laufzeit, Speicherverbrauch) in einer konkreten Situation / Modul sind, desto genauer muss man wissen was man tut, und desto genauer muss man dies kontrollieren können.
batman schrieb: > Besonders wenn man nur > statische und automatische Objekte hat. Warum sollte es weniger Sinn machen statische Objekte zu haben? Wenn ein Gerät z.B. eine Antriebsachse mit Encodern und Endschaltern hat kann ich das als Objekt abbilden und genau das macht Sinn. Da die Achse immer vorhanden ist kann das Objekt auch statisch oder auf dem main Stack gelegt werden, da muss nix dynamisch gemacht werden. Wenn ich zwei Achsen brauche lege ich zwei Instanzen an, auch statisch, fertig. Und auch der C++ Compiler baut da nicht eingenmächtig irgendwelche dynamischen Sachen ein, das in C++ die Speicherveraltung ungeeigneter sein soll ist eine komische Aussage (von anderen hier). Ich kann immer noch selber entscheiden wo ein Objekt liegen soll.
Wilhelm M. schrieb: > [1] In C ist es "einfach", Programme zu schreiben, die compiliert werden > können, aber sich zur Laufzeit falsch verhalten. Öhm, das schafft man mit C++ aber auch wenn man will. Wilhelm M. schrieb: > [2] In C++ "kann" man so programmieren, dass Programme, die die > einfachen Fehler aus [1] enthalten, nicht compiliert werden können. -Wall -Werror kann ich da empfehlen.
ManuelGast schrieb: > Lohnt es sich überhaupt in C Welt was zu machen > oder soll ich weiterhin embedded mit C++ programmieren? Ich würd mal sagen, probiers aus. Wenn Du mit C++ klarkommst, warum nicht. Ich guck da eher rein, wie ein Schwein ins Uhrwerk. Was willst Du denn auf dem µC programmieren. Richtige Harwaresteuerungen oder auch nur PC-Zeugs (GUI, Netzwerk, Datenträger).
Sheeva P. schrieb: > Mampf F. schrieb: >> Kommt auf die Plattform an ... C++ verwendet viel dynamische allozierten >> Speicher > > Nein. Es ist nicht C++, das dynamische Speicherallokation benutzt, > sondern der jeweilige Programmierer benutzt sie -- oder eben nicht. Man sieht doch oft überhaupt nicht, ob ein Template aus der zb STL dynamischen Speicher verwendet, ob er vlt nur einmal alloziert wird oder ob da wild mit new und deletes jongliert wird. New und delete komplett zu vermeiden ist erstaunlich schwer ... ich hatte längere Zeit nach einem zB demarshaller für JSON in C++ gesucht, der mit einem statischen Block RAM.auskommt. Oder auch so simple Sachen wie ein outstream ist dynamisch ... Gibt aber Alternativen (die deprecated sond), die auch mit statischem RAM klar kommen. Ich wollte damit sagen, das ist oft nicht ersichtlich, ob dynamischer Speicher verwendet wird.
Mampf (unterwegs) schrieb: > Ich wollte damit sagen, das ist oft nicht ersichtlich, ob dynamischer > Speicher verwendet wird. Und das ist in C anders? Bei printf() würde man es auch nicht erwarten, aber z.B. das printf() der newlib C library benötigt malloc(). Da hilft bei beiden Sprachen nur, in die Doku zu schauen.
> Nur ein kleiner Teil dieser Bibliothek besteht aus > Containern, und auch denen könnte man per Allokator die > dynamische Speicherverwaltung abgewöhnen. Ja klar, ich meine primär die Container Klassen und Strings. > Nur dass eine Sprache mehr Features zur Verfügung stellt, bedeutet > noch nicht, dass man diese adäquat nutzen kann und daraus wartbarer > Code entsteht. Darüber haben wir gerade im Büro diskutiert. Es kommt darauf an, dass alle Beteiligten mit dem Code und den Tools zurecht kommen. Das bedeutet in der Praxis oft, dass man nicht alle Features verwendet.
Peter D. schrieb: > Was willst Du denn auf dem µC programmieren. Richtige Harwaresteuerungen > oder auch nur PC-Zeugs (GUI, Netzwerk, Datenträger). Es geht eigentlich um beide. Hardwaresteuerung und dann anhand eine GUI(c++ mit Qt oder LabVIEW) bestimmten Messdaten darstellen bzw Befehle ausführen und ....
> Es geht eigentlich um beide.
Meine Erfahrung dazu ist: schlechte Idee
Damit die GUI nicht die Steuerung stört, muss man einiges an
Zusatzaufwand rein stecken. Es ist viel einfacher, diese beiden Teile zu
trennen.
Zum Beispiel könntest du die Hardware mit einem Arduino nano Modul (oder
einem größeren 32bit Controller) realisieren. Daneben baust du einen
ESP8266 oder irgend ein anderes Board mit Ethernet, welches eine
Web-Browser basierte GUI bereit stellt. Die beiden unterhalten sich dann
über irgendein serielles Protokoll.
GUI als Task mit niedrigerer Priorität in einem RTOS mit Hardwareprozessen und schon ist der Drops gelutscht.
Stefan U. schrieb: > Darüber haben wir gerade im Büro diskutiert. Es kommt darauf an, dass > alle Beteiligten mit dem Code und den Tools zurecht kommen. Das bedeutet > in der Praxis oft, dass man nicht alle Features verwendet. Das klingt für mich nach er Anleitung zur Abwärtspirale. Damit orientiert ihr euch doch immer am "schwächsten" Kollegen (im Zweifelsfall, an dem Kollegen, der frisch von der Uni gekommen ist). Jeder muss ständig überlegen, ob sein Kollege dieses Feature nun kennt und versteht, statt seine Aufgaben in maximaler Effektivität zu erledigen. Etwas neues lernt man so auch nicht (zumindest nicht von Kollegen). Und wahrscheinlich gehen die besten Kollegen irgendwann, weil sie keine Lust mehr haben, ausgebremst mit dem rechten Arm auf den Rücken gebunden zu arbeiten.
Stefan U. schrieb: > Darüber haben wir gerade im Büro diskutiert. Es kommt darauf an, dass > alle Beteiligten mit dem Code und den Tools zurecht kommen. Das bedeutet > in der Praxis oft, dass man nicht alle Features verwendet. Man muß ja auch nicht alle Features verwenden. Selbst wenn man nur ein einziges nützliches Feature einsetzt, spricht das schon für C++.
Torsten R. schrieb: > Stefan U. schrieb: > >> Darüber haben wir gerade im Büro diskutiert. Es kommt darauf an, dass >> alle Beteiligten mit dem Code und den Tools zurecht kommen. Das bedeutet >> in der Praxis oft, dass man nicht alle Features verwendet. > > Das klingt für mich nach er Anleitung zur Abwärtspirale. Damit > orientiert ihr euch doch immer am "schwächsten" Kollegen (im > Zweifelsfall, an dem Kollegen, der frisch von der Uni gekommen ist). > Jeder muss ständig überlegen, ob sein Kollege dieses Feature nun kennt > und versteht, statt seine Aufgaben in maximaler Effektivität zu > erledigen. > > Etwas neues lernt man so auch nicht (zumindest nicht von Kollegen). Und > wahrscheinlich gehen die besten Kollegen irgendwann, weil sie keine Lust > mehr haben, ausgebremst mit dem rechten Arm auf den Rücken gebunden zu > arbeiten. Das sehe ich genauso, und das ist genau auch die Antwort, die ich hier schon ab und zu mal im Forum gegeben habe. Man sollte mal über Abhilfe nachdenken: https://www.fluentcpp.com/2017/04/04/the-dailies-a-new-way-to-learn-at-work/
> Das klingt für mich nach er Anleitung zur Abwärtspirale.
Nein, das heißt ja nicht, dass man nichts mehr dazu lernen will. Es ist
eher ein Entgegenkommen und gemeinsames Aufsteigen.
Torsten R. schrieb: > Das klingt für mich nach er Anleitung zur Abwärtspirale. Damit > orientiert ihr euch doch immer am "schwächsten" Kollegen (im > Zweifelsfall, an dem Kollegen, der frisch von der Uni gekommen ist). Nach meiner Erfahrung sind die Kollegen, die frisch von der Uni kommen, ziemlich fit, kennen auch aktuelle Features recht gut und können sich im Zweifelsfall auch schnell in Unbekanntes hinein fuchsen, weil sie jung, ans Lernen gewöhnt und offen für Neues sind. Problematischer ist es oft mit den älteren Kollegen, die schon seit Jahren im Beruf stehen und dies oder jenes "schon immer so gemacht" haben. Das spiegelt sich auch in meinen Erfahrungen bei C++-Diskussionen hier im Forum: es scheinen eher die Älteren zu sein, die sich mit Händen und Füßen gegen neue Trends wehren, während viele Jüngere dem gegenüber offener zu sein scheinen. Möglicherweise liegt das daran, daß das Lernen neuer Sachverhalte mit zunehmendem Alter immer anstrengender wird, oder sich mit steigender Erfahrung auch eine gewisse Eingefahrenheit einstellt.
Mampf (unterwegs) schrieb: > Sheeva P. schrieb: >> Nein. Es ist nicht C++, das dynamische Speicherallokation benutzt, >> sondern der jeweilige Programmierer benutzt sie -- oder eben nicht. > > Man sieht doch oft überhaupt nicht, ob ein Template aus der zb STL > dynamischen Speicher verwendet, ob er vlt nur einmal alloziert wird oder > ob da wild mit new und deletes jongliert wird. In 95% der Fälle ist es offensichtlich, zum Beispiel bei allen Containern, denen zur Laufzeit neue Elemente hinzugefügt werden können. Und bei allen anderen Fällen reduziert es sich darauf, ob man sein Werkzeug beherrscht. > New und delete komplett zu vermeiden ist erstaunlich schwer ... ich > hatte längere Zeit nach einem zB demarshaller für JSON in C++ gesucht, > der mit einem statischen Block RAM.auskommt. Das findest Du dabei aber nicht ernsthaft verwunderlich, oder?
Torsten R. schrieb: > Stefan U. schrieb: > >> Darüber haben wir gerade im Büro diskutiert. Es kommt darauf an, dass >> alle Beteiligten mit dem Code und den Tools zurecht kommen. Das bedeutet >> in der Praxis oft, dass man nicht alle Features verwendet. > > Das klingt für mich nach er Anleitung zur Abwärtspirale. Damit > orientiert ihr euch doch immer am "schwächsten" Kollegen (im > Zweifelsfall, an dem Kollegen, der frisch von der Uni gekommen ist). > Jeder muss ständig überlegen, ob sein Kollege dieses Feature nun kennt > und versteht, statt seine Aufgaben in maximaler Effektivität zu > erledigen. Wenn im Team gearbeitet wird, denn zählt zunächst die Effektivität des Teams als Ganzem. Neues zu lernen ist erstmal eine Bremse. Es braucht Zeit und es braucht Motivation. Wenn jemand bereits flüssig und sicher in einer Sprache ist, und muss oder soll zur Lösung eines neuen Problems eine neue Sprache lernen, in der er unsicher ist und nur langsam voramkommt und womöglich noch Zeitdruck hat, dann ist das höchst unmotiviered. Und zum Lernen gehört auch zu, sich mit anderen Lernenden austauschen zu können, keinen Zeit- oder Projektdruck zu daben, ohne Zweckbindung mit dem Neuen rumspielen zu können und auch Fehler machen zu dürfen. Gerade letzteres ist bei "Learning by Doing" nicht gegeben, denn das Doing ist i.d.R. die Umsetzung eines Projekts. Spätestens wenn die Fehler beim Kunden oder im Feld angekommen sind, kannst man sich ausmalen, dass da nicht mit Milde auf den (damals) Lernenden zurückgeblickt wird, sondern Projekt- und Geschäftsleitung höchst unerfreut sind. Beim nächsten "Experiment" bleibt man dann bei den bewährten olle Kamellen. Wie das genau gehandabt wird häng natürlich von der Unternehmenskultur oder -nichtkultur ab. Ob sich nun die Fitten abgehängt sind oder die weniger Fitten sei dahingestellt und hängt auch von persönlichen Befindlichkeiten und vom Management ab.
Sheeva P. schrieb: > Nach meiner Erfahrung sind die Kollegen, die frisch von der Uni kommen, > ziemlich fit, kennen auch aktuelle Features recht gut und können sich im > Zweifelsfall auch schnell in Unbekanntes hinein fuchsen, weil sie jung, > ans Lernen gewöhnt und offen für Neues sind. Problematischer ist es oft > mit den älteren Kollegen, die schon seit Jahren im Beruf stehen und dies > oder jenes "schon immer so gemacht" haben. Komisch, hab ich immer genau die gegenteiligen Erfahrungen gemacht. Hängt wohl von der Perspektive ab.
Sheeva P. schrieb: > Möglicherweise liegt das daran, daß das Lernen > neuer Sachverhalte mit zunehmendem Alter immer anstrengender wird, oder > sich mit steigender Erfahrung auch eine gewisse Eingefahrenheit > einstellt. Fakt ist eins, wenn man die neuen Features von C++ verwendet kann man nicht auf einmal Programme schreiben die man ohne nicht schreiben könnte. Mit anderen Worten, die alten Hasen haben für die üblichen Problemstellungen längst Lösungen in der Schublade. Und nur zum Selbstzweck macht man das halt nicht eben mal alles neu nur weil es eventuell einen eleganteren Weg gibt. In einem anderen Thread hat gerade jemand eine ltoa-Variante in c++ vorgestellt. Angeblich schneller als die üblichen in den Libs. Kann ja sein. Allerdings ist das nun ein Roman geworden der wenigstens 3-5mal so lang im Quellcode geworden ist. Sorry, aber den Aufwand werde ich nicht treiben. Im Gegenteil, solche Beispiele sind ein klarer Fall dafür, dass die schöne neue Welt so schön auch nicht ist. Ob man das nun Eingefahrenheit nennt oder sonst wie ist egal. Wenn man von Grund auf etwas Neues macht kann man über vieles Nachdenken, allerdings geht es viel häufiger um Weiterentwicklungen. Und in der Industrie lässt sich schon gleich niemand zu einer kompletten Neuentwicklung bewegen nur weil es moderner ist.
Sheeva P. schrieb: >> New und delete komplett zu vermeiden ist erstaunlich schwer ... ich >> hatte längere Zeit nach einem zB demarshaller für JSON in C++ gesucht, >> der mit einem statischen Block RAM.auskommt. > > Das findest Du dabei aber nicht ernsthaft verwunderlich, oder? Da habe ich das hier benuzt: https://os.mbed.com/teams/Night-Crue/code/JSON/ und etwas modifiziert, das Json wird einmal instanziiert und dann eine parse(...) Methode aufgerufen. Es gibt ein new im Konstruktor und zwei im Code, die kann man aber wegoptimieren wenn der json string im Ram liegt. Läuft wunderbar auf einem kleinem Cortex-M0 mit 16 kB Flash. Hat natürlich nicht soooviel Komfort aber immerhin. Der C-Programmierer lässt den C++ Wrapper weg und nimmt das nackte JSMN, aber ich finde den Wrapper brauchbar.
Johann L. schrieb: > Neues zu lernen ist erstmal eine Bremse. Das Erlernen von Neuem ist vor allem eine Investition. Als solche muß sie sich zunächst amortisieren und sollte sich danach rentieren.
Sheeva P. schrieb: > Das spiegelt sich auch in meinen Erfahrungen bei C++-Diskussionen hier > im Forum: es scheinen eher die Älteren zu sein, die sich mit Händen und > Füßen gegen neue Trends wehren, während viele Jüngere dem gegenüber > offener zu sein scheinen. Möglicherweise liegt das daran, daß das Lernen > neuer Sachverhalte mit zunehmendem Alter immer anstrengender wird, oder > sich mit steigender Erfahrung auch eine gewisse Eingefahrenheit > einstellt. Das greift mir zu kurz. Ein unbeschriebenes Blatt ist natürlich flexibler und motivierter, weil es meist eben nicht mit C-Profis mithalten kann. Und nach ein paar Jahren stellt man fest, dass die guten jungen Programmierer C++ Wüsten in Write-only-Style hinterlassen haben. So wie die guten alten in C. Den Produktivcode von heute haben halt die paar sehr guten Programmierer verantwortet, aufgrund derer die Firma heute noch lebt. Und nur wenn bei den jungen auch ein paar sehr gute dabei sind, wird sie die nächsten Jahre mit C, C++ oder auf Rollschuhen ebenfalls überleben. Als Fakt sehe ich aber auch an: Die Sprache C ist einfacher als C++. Einfacher im Sinne des Sprachumfangs. Das erlaubt es bei geschickter Benamung, Kapselung und Toolchain, einfacher zu modellieren, also einfacher die Sachverhalte in einer formalen Sprache zu beschreiben. Die Mähr von der parallel existierenden Spezifikation und der Umsetzung durch ein Programmierfachkraft ist halt nicht überall wahr oder sinnvoll. Es wäre irrsinnig, ein Modell in UML/StateFlow/Charts oder was auch immer zu haben und parallel dazu in einer Programmiersprache.
Achim S. schrieb: > Als Fakt sehe ich aber auch an: Die Sprache C ist einfacher als C++. > Einfacher im Sinne des Sprachumfangs. Wenn das ein Argument wäre, dann wären die meistgenutzten Programmier- sprachen heute Brainfuck oder Whitespace [1]. Sind sie aber nicht. > Das erlaubt es bei geschickter Benamung, Kapselung Oh Ja. Laß uns doch einfach mal bei Kapselung bleiben. Hat C schlicht und ergreifend nicht. Und schon hat C++ gewonnen. Ja, ok ist nur ein Punkt. Aber ein wichtiger. [1] https://de.wikipedia.org/wiki/Kategorie:Esoterische_Programmiersprache
Axel S. schrieb: > Oh Ja. Laß uns doch einfach mal bei Kapselung bleiben. Hat C schlicht > und ergreifend nicht. Und schon hat C++ gewonnen. Ja, ok ist nur ein > Punkt. Aber ein wichtiger. Naja, wenn du alles von der Compilertechnik bzw. Sprache abhängig machst, hast du schon verloren, würde ich sagen. Konstrukte wie Kapselung sind da nur Krücken, um schlechte Konzepte möglichst abzublocken. Man kann aber auch gleich mit gutem Konzepten anfangen, wenn man es gelernt hat.
batman schrieb: > Konstrukte wie Kapselung sind da nur Krücken, > um schlechte Konzepte möglichst abzublocken. Ja, nee, ist klar .... Keine Fragen mehr, alles klar ...
batman schrieb: > Axel S. schrieb: >> Oh Ja. Laß uns doch einfach mal bei Kapselung bleiben. Hat C schlicht >> und ergreifend nicht. Und schon hat C++ gewonnen. Ja, ok ist nur ein >> Punkt. Aber ein wichtiger. > > Naja, wenn du alles von der Compilertechnik bzw. Sprache abhängig > machst, hast du schon verloren, würde ich sagen. Konstrukte wie > Kapselung sind da nur Krücken, um schlechte Konzepte möglichst > abzublocken. Man kann aber auch gleich mit gutem Konzepten anfangen, > wenn man es gelernt hat. Kapselung IST eins der guten Konzepte! Konzepte finden nämlich im Abstrakten statt und das ist doch, so die gängige Haßmeinung, DIE Domäne von C++. (UpToDate)C++ hat vor allem constexpr, was bei kleinen Tiny's den Vorteil hat, daß ein Teil des Programms vorab auf dem Intel/AMD-Boliden gerechnet wird, wo GigaByte und GigaHerz in Hülle und Fülle bereit stehen, dem kleinen AVR unter die Arme zu greifen.
Carl D. schrieb: > Kapselung IST eins der guten Konzepte! > Konzepte finden nämlich im Abstrakten statt und das ist doch, so die > gängige Haßmeinung, DIE Domäne von C++. Es ist ein Konzept der Entwicklung, aus Compilersicht ist es nur ein Unterbinden von bestimmten Zugriffen. Da stellt das Feature also gar keinen Mehrwert für diejenigen dar, die solche Zugriffe gar nicht auf dem Plan hatten.
temp schrieb: > Fakt ist eins, wenn man die neuen Features von C++ verwendet kann man > nicht auf einmal Programme schreiben die man ohne nicht schreiben > könnte. Ja. Man kann aber ähnliche Programme eleganter, wartbarer und in vielen Fällen plattformunabhängig und standardkonform schreiben -- und man muß auch nicht alles sofort ändern, umstellen, oder gar neu machen. Zumindest nicht im Falle von C++, das mit dem etablierten Industriestandard C doch weitgehend kompatibel ist. > Mit anderen Worten, die alten Hasen haben für die üblichen > Problemstellungen längst Lösungen in der Schublade. Ja, genau das meine ich mit "eingefahren": das beliebte "dat hamwer immer so jemacht". Nur: wer immer alles so macht, wie er es immer schon gemacht hat, macht zwar nichts falsch, entwickelt sich aber auch nicht weiter. > Und nur zum > Selbstzweck macht man das halt nicht eben mal alles neu nur weil es > eventuell einen eleganteren Weg gibt. Niemand redet davon, "eben mal alles neu" zu machen -- das geht doch gar nicht, schon gar nicht zum Selbstzweck. Was soll denn das? > In einem anderen Thread hat gerade > jemand eine ltoa-Variante in c++ vorgestellt. Angeblich schneller als > die üblichen in den Libs. Kann ja sein. Allerdings ist das nun ein Roman > geworden der wenigstens 3-5mal so lang im Quellcode geworden ist. Tja... wenn das wirklich schneller ist, kann es je nach Anwendungsfall trotzdem sinnvoll sein, es zu nutzen. Ansonsten ist es eher unklug, Herangehensweisen anhand einzelner Beispiele zu beurteilen. Statistische Betrachtungen mit einer Probengröße von 1 sind eher wertlos. > Und > in der Industrie lässt sich schon gleich niemand zu einer kompletten > Neuentwicklung bewegen nur weil es moderner ist. Meine Güte... von einer kompletten Neuentwicklung redet doch keiner, das ist doch Quatsch. Aber es ist durchaus möglich und eigentlich auch fast immer sinnvoller, schrittweise vorzugehen.
Achim S. schrieb: > Das greift mir zu kurz. Ein unbeschriebenes Blatt ist natürlich > flexibler und motivierter, weil es meist eben nicht mit C-Profis > mithalten kann. Das ist der Handel zwischen Erfahrung einer- und Kreativität andererseits. Ich habe einen jungen Mathematik-Master und eine mathematisch-technische Softwareentwicklerin im Team, und die schreiben C- und auch C++-Code, der einfach zum Niederknien schön ist. > Und nach ein paar Jahren stellt man fest, dass die guten > jungen Programmierer C++ Wüsten in Write-only-Style hinterlassen haben. > So wie die guten alten in C. Den Produktivcode von heute haben halt die > paar sehr guten Programmierer verantwortet, aufgrund derer die Firma > heute noch lebt. Und nur wenn bei den jungen auch ein paar sehr gute > dabei sind, wird sie die nächsten Jahre mit C, C++ oder auf Rollschuhen > ebenfalls überleben. Zu glauben, ein Unternehmen würde wegen seiner Codequalität überleben, ... das würde mir einige Optionen für die nächste Gehaltsverhandlung eröffnen, erscheint mir aber etwas unrealistisch. Dafür überleben nämlich leider zu viele Unternehmen mit einer Codequalität, die mit "unter aller Sau" noch ausgesprochen wohlwollend beschrieben ist. Darüber hinaus finde ich Deine Argumentation etwas inkonsistent. Du sagst ja, daß die "guten alten" "sehr guten Programmierer", eine "Wüste" in C hinterlassen hätten und die jungen das dann eben in C++ tun würden. Dabei ist mir allerdings nicht ganz klar, warum eine Code-Wüste in C besser sei als eine in C++. Möglicherweise siehst Du das ja anders als ich, aber ich persönlich bevorzuge gar keine Code-Wüsten -- in egal welcher Sprache. Vielleicht habe ich ja wirklich Glück gehabt und bisher immer nur gute Jungspunde getroffen, das kann ich natürlich nicht ausschließen. Aber was denen an Erfahrung fehlt, machen sie mit aktuellem Knowledge, Querdenken, neuen Ideen und Engagement wett. Wenn Du solche Leute jemandem zuordnest, der sie mit seiner Erfahrung unterstützen oder sogar führen kann, ist das keine schlechte Kombination. > Als Fakt sehe ich aber auch an: Die Sprache C ist einfacher als C++. Ja, nein, vielleicht. Kommt darauf an. Und die Sprache Python ist einfacher als C. Spricht das gegen C, gegen C++, oder gegen Python? ;-)
batman schrieb: > Konstrukte wie Kapselung sind da nur Krücken, um schlechte Konzepte > möglichst abzublocken. Man kann aber auch gleich mit gutem Konzepten > anfangen, wenn man es gelernt hat. Ja klar. Und Sicherheitsgurte sind auch nur Krücken, um bei Unfällen den Schaden für die Insassen zu reduzieren. Man kann stattdessen aber auch einfach keine Unfälle bauen. Axel S. schrieb: > Oh Ja. Laß uns doch einfach mal bei Kapselung bleiben. Hat C schlicht > und ergreifend nicht. Und schon hat C++ gewonnen. Ja, ok ist nur ein > Punkt. Aber ein wichtiger. Natürlich hat C Kapselung.
Sheeva P. schrieb: >> New und delete komplett zu vermeiden ist erstaunlich schwer ... ich >> hatte längere Zeit nach einem zB demarshaller für JSON in C++ gesucht, >> der mit einem statischen Block RAM.auskommt. > > Das findest Du dabei aber nicht ernsthaft verwunderlich, oder? Nein, aber nichtsdestotrotz hab ich so einen Demarshaller benötigt.
Sheeva P. schrieb: > Du sagst ja, daß die "guten alten" "sehr guten Programmierer", eine > "Wüste" Sorry, die Unterscheidung kommt aus dem bei uns bekannten Statement, dass es nicht nur gute Programmierer gäbe, ... sondern auch sehr gute. Und die strategisch wichtigen Dinge wurden von den wirklich sehr guten Leuten kreiert. Das Problem: während diese Produkte täglich weiterentwickelt werden, damit auch täglich Kosten, Fehler und Aufwand produzieren, erscheinen die "guten" ziemlich solide. Niemand traut sich, hier irgendwas zu verbessern. Wir haben noch Code hier in Assembler, der wartbarer und gekapselten ist, als viele C/C++ Wüsten. Und nein Assembler ist nicht portabel und deshalb seit Jahren raus. Und natürlich ist Code der mit virtuellen Objekten arbeitet, hoch effizient sein soll, GUI, Ethernet, Web in C++ bei uns. Hochkomplexe embedded Steuerung (nicht Regelung, nicht GUI) dagegen in C, obwohl OS und Treiber C++ sind. Wobei C halt immer Lint mit einschließt.
>> Als Fakt sehe ich aber auch an: Die Sprache C ist einfacher als C++. >> Einfacher im Sinne des Sprachumfangs. > Wenn das ein Argument wäre, dann wären die meistgenutzten Programmier- > sprachen heute Brainfuck oder Whitespace [1]. Sind sie aber nicht. Nun, Java erfreut sich einer auffälligen Beliebtheit. Und Java fühlt sich für mich wie ein vereinfachtes C++ an (ich muss es wissen, denn ich verdiene damit seit 15 Jahren mein Brot). > Laß uns doch einfach mal bei Kapselung bleiben. Hat C schlicht > und ergreifend nicht. Und schon hat C++ gewonnen. Dann hast du noch nicht gesehen, wie man in C Objektorientiert programmiert. Namespaces würde man dort vermissen, kann man in der Praxis jedoch durch eine Namenskonvention ersetzen. Und objektorientierte Programmierung ist dort durchaus möglich. Kleiner Tipp dazu: Schau Dir man an, was der C++ Compiler bei Methoden-Aufrufen mit dem SELF Pointer macht. Dann wirst du sofort sehen, dass man genau das Gleiche auch in C machen kann - ohne großartige Tricks. Nur mal um ein konkretes Beispiel zu nennen: Für eine Datenmigration von einem alten Cobol System sollte ich eine HashMap für einen sehr alten IBM Server programmieren. Die Verwendung von Libraries war dort verboten, es stand nur die Programmiersprache und die Standard C Library zur Verfügung. Ich habe das in 2 Tagen unter CygWin umgesetzt - nachdem ich mich bei Wikipedia erstmal einlesen musste, wie das eigentlich funktioniert. Denn bis dahin hatte ich HashMaps einfach nur benutzt. Ich gab meine generische HashMap ab und sie hat auf Anhieb sauber auf dem Zielsystem funktioniert. Dabei habe ich dieses IBM Betriebssystem und dessen uralten C Compiler bis heute nie gesehen, geschweige denn erfahren, welche Daten in der HashMap gespeichert werden. Ja, C++ hat ein paar coole Features, die C nicht hat. Aber das heißt noch lange nicht, dass man nur in C++ sauber objektorientiert programmieren kann.
Mampf (unterwegs) schrieb: > Man sieht doch oft überhaupt nicht, ob ein Template aus der zb STL > dynamischen Speicher verwendet, ob er vlt nur einmal alloziert wird oder > ob da wild mit new und deletes jongliert wird. ... > Ich wollte damit sagen, das ist oft nicht ersichtlich, ob dynamischer > Speicher verwendet wird. Das siehst du in der Template Deklaration (Allocator = std::allocator<T>). Du kannst dir auch deinen eigenen Allocator schreiben. Oder du nimmst static Boost Versionen, bspw. boost::static_vector.
Stefan U. schrieb: > Aber das heißt noch lange nicht, dass man nur in C++ sauber > objektorientiert programmieren kann. OOP ist in c++ auch ein recht kleiner Teil. Auf der anderen Seite kann OOP in c sehr ekelhaft werden und damit schlecht wartbar.
Stefan U. schrieb: > Dann hast du noch nicht gesehen, wie man in C Objektorientiert > programmiert. Namespaces würde man dort vermissen, kann man in der > Praxis jedoch durch eine Namenskonvention ersetzen. Und > objektorientierte Programmierung ist dort durchaus möglich. Ich hab das mal gesehen, bei Gtk - und fand es nicht grad schön. Ellenlange Funktionsnamen, um Namespaces, Klassen und Überladung zu ersetzen und viel fehlerträchtige Makro-Magie, um das dynamische Typsystem zu ersetzen. Mikro 7. schrieb: > Oder du nimmst static Boost Versionen, bspw. boost::static_vector. Oder halt gleich den Standard-Typ: std::array.
Rolf M. schrieb: > Mikro 7. schrieb: >> Oder du nimmst static Boost Versionen, bspw. boost::static_vector. > > Oder halt gleich den Standard-Typ: std::array. Ein Vector kann seine Größe ändern, ein Array nicht. Das wird bspw. dann interessant, wenn du keinen Default Constructor für deine Elemente hast.
Stefan U. schrieb: > Ja, C++ hat ein paar coole Features, die C nicht hat. Aber das heißt > noch lange nicht, dass man nur in C++ sauber objektorientiert > programmieren kann. Ja, unter anderem Hashmaps ;-) Also 2 Tage in den Sand gesetzt, weil flasches Werkzeug verwendet.
:
Bearbeitet durch User
avr schrieb: > OOP ist in c++ auch ein recht kleiner Teil. Auf der anderen Seite kann > OOP in c sehr ekelhaft werden und damit schlecht wartbar. Wenn man sich keine Gedanken dazu vorher macht kann OOP auch in C++ sehr hässlich werden. Aber mal ernsthaft: Der Thread driftet IMO zu sehr ins C/C++ gebashe ab. Das führt doch zu nichts. Beide Sprachen haben, auch im Embedded Bereich, ihre Berechtigung.
So siehts aus. Wenn C++ generell die beste Wahl wäre, gäbe es keine MCU wie Tiny10, der damit inkompatibel ist. Man muß leider etwas differenzieren können.
Torsten R. schrieb: > Ja, unter anderem Hashmaps ;-) Also 2 Tage in den Sand gesetzt, weil > flasches Werkzeug verwendet. Eine der Anforderungen war: "es stand nur die Programmiersprache und die Standard C Library zur Verfügung".
Nop schrieb: > Torsten R. schrieb: > >> Ja, unter anderem Hashmaps ;-) Also 2 Tage in den Sand gesetzt, weil >> flasches Werkzeug verwendet. > > Eine der Anforderungen war: "es stand nur die Programmiersprache und die > Standard C Library zur Verfügung". Naja, wenn er C++ genommen hätte, wären die Anforderungen halt: nur die Programmiersprache und die zugehörige Standard Library...
C hat gegenüber C++ den generellen Vorteil, daß die Sprache kompakter ist. Die Beziehung zwischen C-Code und dem rausfallenden Maschinencode ist deutlich einfacher. Das spielt für Anwendungen auf dem PC nicht unbedingt eine Rolle, aber wenn man hardwarenah programmiert, wird Abstraktion schnell zu Obfuscation. Dann ist sie nicht hilfreich, sondern nervig. Zudem ist C++ wesentlich kontextabhängiger, allein schon wegen Überladung, so daß man Patches nicht mehr differentiell reviewen kann. Ein wesentlicher Grund, wieso es im Linuxkernel nicht eingesetzt wird. Nicht zuletzt gibt es eine Menge C++-Programmierer, die unter "ich kann C++" verstehen, daß sie wissen, was der Code inhaltlich bewerkstelligt, aber nicht, was tatsächlich in etwa an Maschinencode herausfällt. Eine Programmierkultur, wie man sie eher von Java kennt. Diese Art von Programmierern hält man sich aus seinen Projekten, wenn man C verwendet.
Stefan U. schrieb: >>> Als Fakt sehe ich aber auch an: Die Sprache C ist einfacher als C++. >>> Einfacher im Sinne des Sprachumfangs. > >> Wenn das ein Argument wäre, dann wären die meistgenutzten Programmier- >> sprachen heute Brainfuck oder Whitespace [1]. Sind sie aber nicht. > > Nun, Java erfreut sich einer auffälligen Beliebtheit. Und Java fühlt > sich für mich wie ein vereinfachtes C++ an (ich muss es wissen, denn ich > verdiene damit seit 15 Jahren mein Brot). Sprich mich lieber nicht auf Java an. Das ist eine der grauenhaftesten Programmiersprachen, die ich gesehen habe. Und ich habe viel gesehen. >> Laß uns doch einfach mal bei Kapselung bleiben. Hat C schlicht >> und ergreifend nicht. Und schon hat C++ gewonnen. > > Dann hast du noch nicht gesehen, wie man in C Objektorientiert > programmiert. Bedauerlicherweise habe ich das schon gesehen. Genau daher kommt meine Beobachtung, daß C keine Kapselung hat. Wenn ich in C++ ein Member einer Klasse als private deklariere, dann erlaubt mir der Compiler nicht, von außerhalb darauf zuzugreifen. Das ist Kapselung. In C kann ich vielleicht einen Kommentar an ein "privates" struct-Member schreiben. Oder im Bezeichner die Silbe "privat" unterbringen. Aber der Compiler wird mir nicht mal eine Warnung geben, wenn jemand unbefugt darauf zugreift. Das ist die Abwesenheit von Kapselung. Versteh mich recht: ich habe nicht gesagt daß es unmöglich wäre, in C objektorientiert und strukturiert und mit Kapselung und was auch immer gerade Mode ist, zu programmieren. Das geht immer. Auch in Assembler oder Brainfuck (Herr Turing läßt grüßen). Aber es ist doch deutlich komfortabler und vor allem viel weniger fehlerträchtig, wenn die Toolchain einen dabei unterstützt.
Axel S. schrieb: > Sprich mich lieber nicht auf Java an. Das ist eine der grauenhaftesten > Programmiersprachen, die ich gesehen habe. Und ich habe viel gesehen. Und dennoch hält sich diese Sprache hartnäckig über Jahrzehnte und wird immer erfolgreicher. Soo schlecht kann diese Sprache also auch nicht sein. Axel S. schrieb: > In C kann ich vielleicht einen Kommentar an ein "privates" struct-Member > schreiben. Oder im Bezeichner die Silbe "privat" unterbringen. Aber der > Compiler wird mir nicht mal eine Warnung geben, wenn jemand unbefugt > darauf zugreift. Das ist die Abwesenheit von Kapselung. Dass es nicht wie in C++ funktioniert ist schon klar, man kann es aber schon so aufbauen, dass es auch eine Kapselung gibt. Dazu muss man natürlich erstmal klar definieren, was man unter Kapselung versteht.
Beitrag #5233423 wurde von einem Moderator gelöscht.
Torsten R. schrieb: > Naja, wenn er C++ genommen hätte Stand nicht zur Verfügung. Genau das war Teil der Anforderungen.
Axel S. schrieb: > Versteh mich recht: ich habe nicht gesagt daß es unmöglich wäre, in C > objektorientiert und strukturiert und mit Kapselung und was auch immer > gerade Mode ist, zu programmieren. Ich möchte diesen Punkt aber gerne nochmal ausführen. Private, geschützte Elemente sind sicher sinnvoll, vor allem wenn man in Schichten und mit unterschiedlichen Teams programmiert. Ein allgemeines OS mit offenen Internas wird sicher schnell missbräuchlich verwendet, was dann bei kleinsten Änderungen fehlschlägt. Es gibt aber auch mächtige Softwaresysteme, bei denen ein globaler Kontext (aktoren/sensoren) den Rahmen vorgibt, und bei denen alle Beteiligten wissen, was sie tun und zu lassen haben. Hier kann selbst ein "alles ist global"-Ansatz sinnvoll sein. Vergleiche es mit einem Magazin: Natürlich ist es einfacher und sicherer, einen Verwalter davor zu setzen, der jede Entnahme prüft und protokolliert und ggf. nachbestellt. Wenn jedoch alle beteiligten diszipliniert sind, kann ein offenes Magazin, wo sich jeder bedienen kann, genauso gut sein.
Axel S. schrieb: > In C kann ich vielleicht einen Kommentar an ein "privates" struct-Member > schreiben. Oder im Bezeichner die Silbe "privat" unterbringen. Aber der > Compiler wird mir nicht mal eine Warnung geben, wenn jemand unbefugt > darauf zugreift. Das ist die Abwesenheit von Kapselung. Ich kann verstehen wenn viele Leute so ein Monstrum wie QT entwickeln, dass sie die Internas vor dem Anwender verstecken und schützen wollen. Da ist Kapselung gut und das Mittel der Wahl. Aber im embedded Bereich? Gut, in Zukunft ja. Aber nur deshalb weil die Controller immer dicker werden und die Leute die sich wirklich damit auskennen immer weniger. Ich wage zu behaupten, dass die Hälfte der Leute die hier im Forum STM32 programmieren das Programmiermanual nie gelesen haben. Anders ist jedenfalls der exzessive Einsatz der STM-Libs nicht zu erklären. Fakt ist aber auch eins, solange die Tendenz da ist, dass jede Zeile des gehypten C++ Codes ungefähr doppelt so lang ist wie mit C läuft was verkehrt. Ziel ist nicht nur kleinen und effizienten Binärcode zu erzeugen, sondern auch der Quelltext muss kompakt und lesbar sein. Leider sehe ich hier immer den Faktor 3 wenn jemand was von C auf C++ umstellt. Ein positives Beispiel ist in meinen Augen mbed. Hier wird C++ in einer vernünftigen Art und Weise verwendet. Selbst beim core von Arduino sehe ich eine sinnvolle Verwendung. Glaubt wirklich jemand die Codebasis von mbed lässt sich so einfach jedes Jahr neu auf den neusten C++ Stand bringen? Und wenn ja von frischen Leuten von der Uni? Es darf gelacht werden! Wenn man aber mal eine Anwendung hat die über ein blinky hinausgeht, dann sind meistens auch fremde Libs im Spiel. Da reicht schon ein Tcp/Ip-Stack und schon haben wir wieder ein Konglemerat aus den verschiedensten Programmieransätzen. Also macht am Ende ein kleiner moderner C++ Anteil das Ergebnis noch lange nicht um relevante Größen schneller, kleiner oder besser wartbar. Deshalb nicht C++ in allen Facetten um jeden Preis, sondern in vernünftiger Dosierung.
temp schrieb: > Da ist Kapselung gut und das Mittel der Wahl. Aber im embedded Bereich? > Gut, in Zukunft ja. Aber nur deshalb weil die Controller immer dicker > werden Zwar sind M4 verfügbar, aber die wird man professionell eher nicht einsetzen, wenn es auch ein M0 täte. Für Hobby ist es ja egal. Abgesehen davon ist es möglich, in C++ Code zu schreiben, der weder umfangreicher noch langsamer ist als in C. Das Problem daran ist allerdings, daß dies nur solchen Programmierern real möglich ist, die eben nicht nur wissen, was man wozu gebrauchen kann, sondern auch, wie es unter der Haube implementiert ist. Das ist eine Minderheit. Diese Programmierer gibt es, klar. Aber die industrielle Realität ist eine vollkommen andere, nämlich daß die Entwickler bereits mit dem UB in C überfordert sind und man genau deswegen MISRA-C geschaffen hat. Daß diese Leute in C++ genauso performanten und kompakten Code abliefern wie in C, halte ich für vollkommen illusorisch. > Ich wage zu behaupten, dass die Hälfte der Leute die hier im Forum STM32 > programmieren das Programmiermanual nie gelesen haben. Anders ist > jedenfalls der exzessive Einsatz der STM-Libs nicht zu erklären. Die STM-Libs sind aber nicht in C++, insofern sehe ich hier keine Verbindung zwischen diesen beiden Phänomen. Wenn überhaupt, dann ist mein Eindruck, daß gerade die hier schreibenden C++-Programmierer ihre Hardware gut kennen - jedenfalls, wenn man mal z.B. die Fans der Arduino-IDE abzieht.
temp schrieb: > Fakt ist aber auch eins, solange die Tendenz da ist, dass jede Zeile des > gehypten C++ Codes ungefähr doppelt so lang ist wie mit C läuft was > verkehrt Das halte ich für ein unsinniges Argument! Natürlich ist ein C++ Quellcode alleine durch solche Token, wie public, private, virtual, using, constexpr usw. länger. Nein kurze Quellcodes, ist kein primäres Ziel bei der OOP. Eher Wiederverwendbarkeit. Lass den Quellcode doch ruhig aufgebläht aussehen... Meist verbessert es sogar die Lesbarkeit und damit auch die Wartbarkeit. Dem Kompilat tut das nicht weh.
Nop schrieb: > jedenfalls, wenn man mal z.B. die Fans der > Arduino-IDE abzieht. Was soll das denn jetzt?
Arduino F. schrieb: > Nop schrieb: >> jedenfalls, wenn man mal z.B. die Fans der >> Arduino-IDE abzieht. > Was soll das denn jetzt? Was, das ist doch Tatsache. Wer Sketches für Arduino macht, tut das genau, um sich nicht mit der Hardware zu befassen. Es ist der ganze Zweck dieser IDE, µC-basierte Basteleien einem fachfremden Publikum wie Künstlern, Modell-Eisenbahnern usw. zu ermöglichen. Da hat man zwar C++ dann, aber keine Hardwarekenntnisse, und außerdem ist das nichtmal richtiges C++, und obendrein auch noch schlechtes (Projektstruktur von Sketchen.. haha). Für kleine Hackereien langt es aber. Deswegen zähle ich Fans der Arduino-IDE hier nicht zu den C++-Programmierern, von denen ich den Eindruck habe, daß sie sich auch auskennen. Auf die IDE habe ich das eingegrenzt, weil man die Arduino-HW natürlich auch ohne IDE als bare board programmieren kann. Jetzt klarer?
Nop schrieb: > Jetzt klarer? Ja! Es ist klar geworden, dass du dich offensichtlich gut/besser dabei fühlst, wenn du versuchst deinen Standpunkt zu erhöhen, dadurch, dass du mich abwertest. Ja, nehme das persönlich!
Arduino F. schrieb: > Es ist klar geworden Ist es nicht. Zu der Erklärung, daß die Arduino-IDE sich eben an Laien richtet und naturgemäß eben solche anzieht, hast Du auch nichts zu sagen. Stattdessen machst Du jetzt einen auf persönlich. Das sagt eigentlich auch schon genug aus.
M. K. schrieb: > Axel S. schrieb: >> Sprich mich lieber nicht auf Java an. Das ist eine der grauenhaftesten >> Programmiersprachen, die ich gesehen habe. Und ich habe viel gesehen. > > Und dennoch hält sich diese Sprache hartnäckig über Jahrzehnte und wird > immer erfolgreicher. Soo schlecht kann diese Sprache also auch nicht > sein. Dafür gibt es viele Gründe, aber sicher nicht, daß Java eine großartige Programmiersprache wäre. Zum einen hat Java zur Zeit seiner Entstehung durchaus eine Lücke gefüllt. Es war - der damaligen Mode entsprechend - objektorientiert [1]. Außerdem plattformunabhängig (was sich in der Praxis allerdings relativiert hat). Es erlaubt (wichtig!) Code in Binärform weiterzugeben und damit vor unauthorisierter Nutzung auszuschließen. Es enthielt (im Gegensatz zum damaligen Hauptkonkurrenten C++) Bibliotheken für GUI und Threads im Standard-Sprachumfang. Und mittlerweile ist die Codebasis so groß, daß sich ein Wechsel weg von Java aus rein praktischen Gründen verbietet. Der Vergleich mit VHS oder Microsoft Windows/Office drängt sich auf. Auch jeweils kein großer Wurf. Aber irgendwie "good enough" und "wir hatten ja nichts anderes" und schließlich "jetzt können wir nicht mehr wechseln" bzw. "alle anderen nutzen es, da müssen wir mit". [1] Sogar zu objektorientiert, wenn du mich fragst. Daß z.B. eine Funktion wie max() oder main() nicht eigenständig sein darf, sondern als statische Methode einer ansonsten leeren Klasse implementiert werden muß, empfinde ich als sprachdesignerische Fehlleistung. Zumal wenn die totale Objektorientierung an anderer Stelle ganz zwanglos aufgehoben wird, z.B. um einen Datentyp (kein! Objekt) int neben der Klasse Integer zuzulassen. Und damit man sich auch ja unwohl fühlt, werden die Operationen die man typischerweise für Zahlen braucht, hübsch zwischen beiden aufgeteilt.
Axel S. schrieb: > Dafür gibt es viele Gründe, aber sicher nicht, daß Java eine großartige > Programmiersprache wäre. Hab ich auch nicht behauptet, dass Java eine großartige Programmiersprache wäre. Ich sagte nur, dass sie nicht so schlimm sein kann Axel S. schrieb: > Und mittlerweile ist die Codebasis so groß, daß sich ein Wechsel weg von > Java aus rein praktischen Gründen verbietet. Dieser Grund ist IMO, ich sag mal, Unsinn. Wollte man davon weg wäre die Codebasis ziemlich egal. Aber auf der anderen Seite: Wenn man eine Codebasis hat, die man für OK findet, warum sollte man zu was anderem wechseln wollen? Man würde dann ja keinen Vorteil erringen. Und da sind wir eigentlich am Punkt der Sache: Wenn man vernünftig programmiert, sich klare Strukturen erarbeitet hat, dann hat auch keine Programmiersprache einen klaren Vorteil. Daher wird sich die Diskussion auch stets nur im Kreis drehen können.
M. K. schrieb: > Wollte man davon weg wäre die Codebasis ziemlich egal. Nein. Das alles in einer anderen Programmiersprache nochmal neu zu machen kostet Zeit und Geld, ohne daß die Kunden davon was hätten. Schlimmer noch, mann wirft Jahre an Reiftesten weg. Dafür bezahlt keiner. Im Übrigen hätte man bei einer entsprechend alten Codebasis in C++ fast dasselbe Problem, weil C++98 erheblich anders war als heutiges und das heutige allgemein als wesentlich besser angesehen wird.
Diese Diskussion hier verläuft eigentlich wie immer, wenn es um das Thema C vs C++ geht. Man kann sich da gelassen zurück lehnen, und dem Treiben belustigt zusehen ... es ist immer das gleiche ;-) Was allerdings m.E. dabei nie genügend beachtet wird, ist die Tatsache, das C++ eine Multiparadigmen-Sprache ist: - man kann OOP nutzen - man kann auch rein prozedural formulieren - man kann meta-programmatisch arbeiten - man kann funktional schreiben Zudem kann man noch Laufzeit- und Compilezeit-Kontext unterscheiden. Und kann auch noch C-Code einbinden ... Und bei allem ist man genauso effizient (manchmal effizienter) als im direkten Vergleich zu C. Wenn wir jetzt noch den "starship"-Operator und "unified function call syntax" bekommen, wird es wohl noch schlimmer mit der Diskussion. Dabei geht es ja wohl nur um die Vorlieben oder Kenntnisstand der einzelnen Entwickler bzw. das Einsatzgebiet des Softwareartefakts: auf Maschinen mit vielen Ressourcen wird man wohl eher gerne zu OOP inkl. Laufzeitpolymorphie greifen. Auf Maschinen mit wenig Ressourcen eher prozedural bleiben und die Vorteile der Meta-Programmierung nutzen. Wer gerne abstrakt formuliert, mag sicher den funktionalen Ansatz. Und eine lange Tool-Kette zum Bauen kann man teilweise verkürzen durch einen Compilezeit-Kontext. Das das alles den ein oder anderen verwirrt, kann ich verstehen. Für mich ist es eher eine Bereicherung, denn ich kann das Paradigma wechseln ohne eine neue Sprache benutzen zu müssen. Aber man sollte bei dem Thema C vs C++ nicht vergessen, das es keinen Zwang gibt, sich so oder so auszurichten. Der Zwang entsteht durch äußere Einflüsse wie etwa Firmenpolitik oder Team-Skills. Wobei man beides durchaus weiter entwicklen kann ;-)
Nop schrieb: > Nein. Das alles in einer anderen Programmiersprache nochmal neu zu > machen kostet Zeit und Geld, ohne daß die Kunden davon was hätten. Deswegen war bei mir ja auch der Konjunktiv drin: "Wollte man davon weg" Dann beachtet man auch was es einen kostet "alles noch mal neu zu machen" ;)
Wilhelm M. schrieb: > Was allerdings m.E. dabei nie genügend beachtet wird, ist die Tatsache, > das C++ eine Multiparadigmen-Sprache ist: > > - man kann OOP nutzen > - man kann auch rein prozedural formulieren > - man kann meta-programmatisch arbeiten > - man kann funktional schreiben Und wenn dann in einem größeren Team kein Subsetting betrieben UND auch durchgesetzt wird, kriegt man eine Codebasis, in der jeder Beteiligte seine 30% Vorlieben eingebracht hat. Die arme Sau von Maintenance-Programmierer, die da drei Jahre nach Projektende ransoll.
Nop schrieb: > Die arme Sau von > Maintenance-Programmierer, die da drei Jahre nach Projektende ransoll. Ach ja - rekrutiert in einem Umfeld, in dem MISRA-C v.a. deswegen notwendig wurde, weil UB in C praktisch gesehen schon zu schwierig ist.
Ich kann nicht nachvollziehen, warum in der Diskussion auch immer über die STL geredet wird, außer dass sie groß und mit dynamischer Allozierung arbeitet. Die ist zunächstmal im Gegensatz zu -Überladung -virtual -Vererbung -enums kein Paradigma von C++ und daher auch kein Argument für oder gegen. Auch darauf beschränkt lässt sich das Denken in SW-Modulen und ggf. Pattern leichter aufteilen.
Nop schrieb: > Wilhelm M. schrieb: > >> Was allerdings m.E. dabei nie genügend beachtet wird, ist die Tatsache, >> das C++ eine Multiparadigmen-Sprache ist: >> >> - man kann OOP nutzen >> - man kann auch rein prozedural formulieren >> - man kann meta-programmatisch arbeiten >> - man kann funktional schreiben > > Und wenn dann in einem größeren Team kein Subsetting betrieben UND auch > durchgesetzt wird, kriegt man eine Codebasis, in der jeder Beteiligte > seine 30% Vorlieben eingebracht hat. Die arme Sau von > Maintenance-Programmierer, die da drei Jahre nach Projektende ransoll. Also am besten eine Sprache, die weniger kann als C ... am besten eine, die gar nichts kann, dann passieren keine Fehler und es entsteht kein Know-How-Problem ...
>>> Ja, unter anderem Hashmaps ;-) Also 2 Tage in den Sand gesetzt, weil >>> flasches Werkzeug verwendet. >> Eine der Anforderungen war: "es stand nur die Programmiersprache und die >> Standard C Library zur Verfügung". > Naja, wenn er C++ genommen hätte, wären die Anforderungen halt: nur die > Programmiersprache und die zugehörige Standard Library... C++ stand nicht zur Verfügung. Die Kiste war so alt, da gab es womöglich C++ noch nicht. jedenfalls war es nicht installiert und wir durften nichts installieren und keine Fremdsoftware einbringen.
Wilhelm M. schrieb: > Also am besten eine Sprache, die weniger kann als C ... am besten eine, > die gar nichts kann, dann passieren keine Fehler und es entsteht kein > Know-How-Problem ... Reductio ad absurdum nennt sich diese rhetorische Stilfigur. Logisch ist sie natürlich nicht zu halten, weil aus "etwas kann zuviel sein" nunmal nicht folgt "zuwenig ist nicht möglich". Eine inhaltliche Antwort auf die realen Probleme ist das jedenfalls nicht.
Wilhelm M. schrieb: > Was allerdings m.E. dabei nie genügend beachtet wird, [...] > > - man kann [...] > - man kann [...] > - man kann [...] > - man kann [...] > > Zudem kann man noch [...] > Diese Diskussion hier verläuft eigentlich wie immer, wenn es um das > Thema C vs C++ geht. Weil es m.E. garnicht um C vs. C++ geht, sondern um die Frage, wie man als nicht-C++ Programmierer den Graben zu C++ überwinden kann. > Der Zwang entsteht durch äußere Einflüsse wie etwa Firmenpolitik > oder Team-Skills. Wo hast du denn C++ gelernt? Bist du in der Industrie in ein Team gekommen und hast es dort gelernt und auf dein heutiges Niveau gebracht? Wievel Monate oder Jahre hat das gedauert? Und zurückblickend: Gibt es Code, von dem du sagen würdest "OMG! Heute würd ich das viel besser machen und statt XXX besser YYY verwenden?". Oder war alles je ausprogrammierte "zum niederknien schön", hat tadellos und ohne Reklamation funktioniert? Allein in diesem Thread könnte ich 2 Duzend Buzz-Words (oder Paradigmen oder wie auch immer) von dir zusammenkratzen, wo ich keinen blassen Schimmer hab, was das ist und wozu ich das brauchen könnte. Und von C++ weiß ich genug, um zu wissen, dass ich diese Sprache niemals auf einem Niveau beherrschen werde, welches meinen eigenen Maßstäben und Ansprüchen auch nur annähernd entsprechen würde — und mit jedem Buzz-Word wird meine Gewissheit darüber größer und nicht etwa kleiner. Und ja, ich verwende C++, aber nur in einem durch Coding-Rules definierten Subset, das im Endeffekt "C with Classes" ist; oder in Fun-Projekten oder irdenwelchen Nerd-Tools. Wenn ich mir anschaue, wie Qt ein QObject::connect implementiert, dann ist das weiß Gott nicht zum niederknien schön. Wenn PeDa oben schreibt, er blickt bei C++ wie'n "Schwein ins Uhrwerk", dann spricht das Bände. Man steht eben nicht nach einer C++ Convention über einem Gläschen Sekt mit anderen Akademikern zusammen und fachsimpelt über das neueste C++ Feature. Der harte Alltag sieht anders aus. Folgende Analogie: Nimm einen Mediziner, etwa einen sehr guten Zahnarzt. Bei wem würdest du dich für eine Herz-OP unters Messer legen? Einem Kardiologen, der Kardiologie und Chirurgie an der Uni vertiefte und als Harzchirurg erfolgreich gearbeitet hat, oder einem Dentisten, der Zahnmedizin an der Uni vertiefte, erfolgreich darin gearbeitet hat, und sich denn per Google und selbst gekaufter Bücher in Kardiologie und Chirurgie reingestrampelt hat? Einen solchen Dentisten, der ablehnt dich zu operieren, würde ich nicht als rückständig oder lernfaul oder nicht-innovativ bezeichnen. Sondern er kennt einfach seine Grenzen und unterliegt nicht der Hybris zu glauben, etwas zu können, was er nicht von der Pike auf studiert hat. Und um wieviel besser oder cooler — gleich in welcher Metrik bemessen — Kardiologie und Chirurgie im Vergleich zur Zahnmedizin auch sein mögen, wieviel erfüllender die Arbeit oder auch sein mag; spielt schlicht und einfach keine Rolle. > Kenntnisstand der einzelnen Entwickler Ja. Genau darum geht es. Und wie man über das Uncanny Valley rüber kommt, oder eben nicht. > Auf Maschinen mit wenig Ressourcen eher prozedural bleiben und die > Vorteile der Meta-Programmierung nutzen. Wer gerne abstrakt formuliert, oder verwenden graphische Tools oder Code-Generatoren. > Tool-Kette zum Bauen Oder so: Anstatt Software fit zu machen, lässt man die Tools für 200€-500€ pro Zeile aufbohren weil: Die Software ist ja zertifiziert und abgenommen, die Toolchain wird's richten. Willkommen in der Realität.
:
Bearbeitet durch User
Johann L. schrieb: > Weil es m.E. garnicht um C vs. C++ geht, sondern um die Frage, wie man > als nicht-C++ Programmierer den Graben zu C++ überwinden kann. Da kann ich keinen Graben zwischen Basis und Erweiterung erkennen. Jeder nutzt die Features, die er jeweils für sinnnvoll hält. Kann es nicht noch einen anderen Grund geben, eine handvoll Bytes nicht in der komplexesten Hochsprache zu programmieren?
Johann L. schrieb: > Weil es m.E. garnicht um C vs. C++ geht, sondern um die Frage, wie man > als nicht-C++ Programmierer den Graben zu C++ überwinden kann. Naja, wie würdest Du denn vorgehen, um Haskell zu erlernen (sofern das noch nicht zu Deinen Lieblingssprachen gehört)? > Wievel Monate oder Jahre hat das gedauert? Und zurückblickend: Gibt es > Code, von dem du sagen würdest "OMG! Heute würd ich das viel besser > machen und statt XXX besser YYY verwenden?". Selbstvertsändlich. Leider gibt es davon immer mehr, je mehr ich lerne ;-) > Oder war alles je > ausprogrammierte "zum niederknien schön", hat tadellos und ohne > Reklamation funktioniert? Mmh, kann mich nicht daran erinnern, das behauptet zu haben. > Allein in diesem Thread könnte ich 2 Duzend Buzz-Words (oder Paradigmen > oder wie auch immer) von dir zusammenkratzen, Echt, nur zwei Dutzend ... wusste doch, dass ich das Computerwoche Abo nicht hätte kündigen sollen. Vielleicht kannst Du sie mir gerade nochmal zusammenstellen, damit ich mich beim nächsten Mal nicht wiederholen muss. > wo ich keinen blassen > Schimmer hab, was das ist und wozu ich das brauchen könnte. Und von C++ > weiß ich genug, um zu wissen, dass ich diese Sprache niemals auf einem > Niveau beherrschen werde, welches meinen eigenen Maßstäben und > Ansprüchen auch nur annähernd entsprechen würde — und mit jedem > Buzz-Word wird meine Gewissheit darüber größer und nicht etwa kleiner. Das finde ich doch gar nicht schlimm - dann lass es doch einfach, wenn es Dich unglücklich macht ;-) > Und ja, ich verwende C++, aber nur in einem durch Coding-Rules > definierten Subset, das im Endeffekt "C with Classes" ist; Wunderbar, wenn Du damit nichts vermisst und auch keine Zeile, kein Design siehst, die Du besser machen möchtest, ist das für mich auch absolut ok. > oder in > Fun-Projekten oder irdenwelchen Nerd-Tools. Wenn ich mir anschaue, wie > Qt ein QObject::connect implementiert, dann ist das weiß Gott nicht zum > niederknien schön. Kann mich auch nicht erinnern, dass das hier in den Raum gestellt wurde. Ich glaube auch, dass würde sogar Lars Knoll, et. al. nicht unbedingt sagen. > Wenn PeDa oben schreibt, er blickt bei C++ wie'n "Schwein ins Uhrwerk", > dann spricht das Bände. Das verstehe ich ja nun gar nicht !? > Folgende Analogie: Nimm einen Mediziner, etwa einen sehr guten > Zahnarzt. Bei wem würdest du dich für eine Herz-OP unters Messer legen? > Einem Kardiologen, der Kardiologie und Chirurgie an der Uni vertiefte > und als Harzchirurg Harzchirurg ist jetzt aber kein Wortspiel, oder? > Einen solchen Dentisten, der ablehnt dich zu operieren, würde ich nicht > als rückständig oder lernfaul oder nicht-innovativ bezeichnen. Absolut: ich wollte Dich auch gar nicht bitten, für mich C++-Code zu schreiben ;-) >> Kenntnisstand der einzelnen Entwickler > > Ja. Genau darum geht es. Und wie man über das Uncanny Valley rüber > kommt, oder eben nicht. Da sind wir uns ja einer Meinung, denn ich gehe davon aus, dass auch Du Stillstand nicht als Lösung ansiehst. Übrigens hatte ich etwas weiter oben mal ein Maßnahme dazu erwähnt. > Willkommen in der > Realität. Genau, es gibt auch schon wieder Spekulatius 8-()
Wenn man bedenkt in welchen vielfältigen Bereichen man C++ verwenden kann würde ich einer Privatperson der die Wahl hat empfehlen C++ zu bevorzugen. Ich entwickle beispielsweise Desktop Anwendungen mit Qt und programmiere mit C++ in der Unreal Engine 4. Für reine 2D Spiele nutze ich gerne die SFML Bibliothek (C++). Wenn man vielfältige Interessen im IT Bereich hat dann kann man C++ wirklich nur empfehlen. Das gelernte lässt sich in unterschiedlichen Bereichen nutzen. Finde ich persönlich besser als C für Embedded, Java oder C# für Desktop Anwendungen zu lernen. Und bei komplexeren Anwendungen wo es doch sehr auf die Performance ankommt käme dann auch noch C++ dazu. Womit ich aber nicht sagen will dass man auf Krampf alles mit C++ machen sollte. Manchmal sind andere Programmiersprachen besser geeignet.
Beitrag #5238859 wurde von einem Moderator gelöscht.
Moby schrieb im Beitrag #5238859: > aller Eigenwerbung der ach so eingängigen > Objektorientierung zum Trotz. OOP: 1 Pin = 1 Objekt. 1 Timer = 1 Objekt. 1 externer Portexpander = 1 Port-Expander-Objekt bestehend aus 1 I²C-Slave-Objekt + 8 Pin-Objekte. Prozedural: 1 Pin = Zwei Integer plus 23 Funktionen? 1 externer Portexpander = Zwei Funktions-Ebenen + 3 Integer? Super intuitiv. Es hat schon einen Grund warum OOP von den meisten Programmiersprachen unterstützt wird.
Ach, das musst du nicht so ernst nehmen... Manche spielen eben gerne mit Bauklötzen, und andere lieber mit Fischer Technik.
Beitrag #5238894 wurde von einem Moderator gelöscht.
Nichts gegen kleine Laufställe und Bauklötzchen! Alles zu seiner Zeit, und an seinem Ort. Moby schrieb im Beitrag #5238894: > Manche mögens einfach, die anderen kompliziert :) Nunja, ich bin recht zufrieden mit meinem "komplizierten" Kram. Immerhin läufts auf ESP, AVR und STM32/ARM. Meist ohne große Portierungswehwehchen. Selbst auf den großen Kesseln, wie Win/Linux zuckt es, wie es soll.(naja) Und wie ist es da mit deinem Assembler Dingens?
Beitrag #5238943 wurde von einem Moderator gelöscht.
Niklas G. schrieb: > Moby schrieb im Beitrag #5238859: >> aller Eigenwerbung der ach so eingängigen >> Objektorientierung zum Trotz. > OOP: 1 Pin = 1 Objekt. 1 Timer = 1 Objekt. 1 externer Portexpander = 1 > Port-Expander-Objekt bestehend aus 1 I²C-Slave-Objekt + 8 Pin-Objekte. > Prozedural: 1 Pin = Zwei Integer plus 23 Funktionen? 1 externer > Portexpander = Zwei Funktions-Ebenen + 3 Integer? Super intuitiv. Es hat > schon einen Grund warum OOP von den meisten Programmiersprachen > unterstützt wird. Da es eher selten ist, dass ein z.B. Portexpander zur Laufzeit die verwendeten Pins wechselt, macht es keinen Sinn, die Info zu den Pins oder des verwendeten I2C-Moduls zur Laufzeit zu repräsentieren. So etwas gehört in den Typ und damit wird dafür auch kein Ram verbraucht.
:
Bearbeitet durch User
Wilhelm M. schrieb: > So etwas > gehört in den Typ und damit wird dafür auch kein Ram verbraucht. Dann müssen aber alle anderen Klassen & Funktionen, die darauf zugreifen, ebenfalls templates sein. Je nach Programmgröße wird das ziemlich umständlich.
Niklas G. schrieb: > Wilhelm M. schrieb: >> So etwas >> gehört in den Typ und damit wird dafür auch kein Ram verbraucht. > Dann müssen aber alle anderen Klassen & Funktionen, die darauf > zugreifen, ebenfalls templates sein. Je nach Programmgröße wird das > ziemlich umständlich. Nein, warum?
Niklas G. schrieb: > Wilhelm M. schrieb: >> Nein, warum? > Bezieht sich jetzt worauf genau? Auf das umständlich.
Wilhelm M. schrieb: > Auf das umständlich. Wenn der Pin-Zugriff die unterste Architektur-Ebene ist und mehrere weitere Ebenen drauf aufsetzen, müssen alle deren Klassen templates sein. Wenn an einer Stelle ein Array von Pins, die per I²C oder direkt angesteuert werden können, angelegt werden soll, wird es auch interessant wenn jedes Element einen anderen Typ hat je nach Hardware-Interface. Auch dass praktisch immer alles neu kompiliert werden muss wenn sich ein Detail der untersten Ebene ändert macht es nicht einfacher.
Niklas G. schrieb: > Wilhelm M. schrieb: >> Auf das umständlich. > > Wenn der Pin-Zugriff die unterste Architektur-Ebene ist und mehrere > weitere Ebenen drauf aufsetzen, müssen alle deren Klassen templates > sein. Ja klar. Aber wo ist das umständlich? > Wenn an einer Stelle ein Array von Pins, die per I²C oder direkt > angesteuert werden können, angelegt werden soll, wird es auch > interessant wenn jedes Element einen anderen Typ hat je nach > Hardware-Interface. Variadische templates. > Auch dass praktisch immer alles neu kompiliert > werden muss wenn sich ein Detail der untersten Ebene ändert macht es > nicht einfacher. Da ist mir unklar, was Du meinst.
Wilhelm M. schrieb: > Ja klar. Aber wo ist das umständlich? Man schreibt sehr oft "template". Plötzlich sind Klassen templates, die gar nichts mehr mit einzelnen Pins zu tun haben. Wilhelm M. schrieb: > Variadische templates. Ja. Super kompliziert. Iteration und wahlfreie Zugriffe sind schwierig. Generiert sehr viel Code. Wilhelm M. schrieb: > Da ist mir unklar, was Du meinst. Wenn sich die template-Parameter an die Pin-Instanzen ändern und daraufhin auch die Parameter an alle darauf aufbauenden Instanzen, müssen die komplett neu kompiliert werden. Man hat eine sehr enge Kopplung.
Niklas G. schrieb: > Wilhelm M. schrieb: >> Variadische templates. > Ja. Super kompliziert. Wen interessiert schon der nachfolgende Maintenance-Programmierer? Reicht doch, wenn man write-only-Code schreibt, den man nur noch selbst durchblickt. Das sichert den Arbeitsplatz.
Niklas G. schrieb: > Wilhelm M. schrieb: >> Ja klar. Aber wo ist das umständlich? > Man schreibt sehr oft "template". Plötzlich sind Klassen templates, die > gar nichts mehr mit einzelnen Pins zu tun haben. Was ist daran umständlich, ein std::array<std::byte, 10> zu verwenden? > > Wilhelm M. schrieb: >> Variadische templates. > Ja. Super kompliziert. Iteration und wahlfreie Zugriffe sind schwierig. Mit fold-expressions m.E. einfacher. > Generiert sehr viel Code. Gegenüber was? > Wilhelm M. schrieb: >> Da ist mir unklar, was Du meinst. > Wenn sich die template-Parameter an die Pin-Instanzen ändern und > daraufhin auch die Parameter an alle darauf aufbauenden Instanzen, > müssen die komplett neu kompiliert werden. Dafür haben wir doch den Compiler ;-) > Man hat eine sehr enge > Kopplung. Die Koppelung zwischen generischen Typen ist m.E. i.a. geringer als bei anderen Arten der Polymorphie.
Beitrag #5239023 wurde von einem Moderator gelöscht.
Moby schrieb im Beitrag #5239023: Nen Papagei verschluckt?
Beitrag #5239029 wurde von einem Moderator gelöscht.
Arduino F. schrieb: > Moby schrieb im Beitrag #5239023: > > > Nen Papagei verschluckt? Dem Typ zu antworten ist das Falsche. Für ihn gibt es den "Beitrag melden"-Link.
Beitrag #5239080 wurde von einem Moderator gelöscht.
Beitrag #5239128 wurde von einem Moderator gelöscht.
Ein Aspekt wurde hier noch nicht betrachtet den ich mal mit in die Runde werfe. Macht man sich z.B. eine Template-Klasse für Gpio-Ports ala GpioPort<PORTA, 5> LedRed; und hat alle Funktionen der Klasse schön als inline declariert, handelt man sich während des Debuggens Unannehmlichkeiten ein. Während des Debuggens mit der Optimierung -O0 macht der Compiler richtige Funktionsaufrufe und keine inline Funktionen. Klar kann man jetzt beim Debuggen z.B. -O1 benutzen, damit kann man aber häufig nicht mehr richtig Debuggen. Hätte man die in C üblichen Makros für die Gpio-Ports benutzt wäre das Problem nicht vorhanden. Gerade in Interrupt-Routinen ist so ein Verhalten nervig. Klar kann man das Umschiffen oder Optimierungs-Pragmas in den Code einbauen, aber schön ist das trotzdem nicht. Alles in allem muss man bei C++ als Effekt immer im Auge haben, dass die Laufzeitunterschiede -O0 zu -O2 in der Regel deutlich größer sind als unter C. Vielfach stört das nicht, aber wenn dann verflucht man es.
temp schrieb: > Ein Aspekt wurde hier noch nicht betrachtet den ich mal mit in die Runde > werfe. Macht man sich z.B. eine Template-Klasse für Gpio-Ports ala > > GpioPort<PORTA, 5> LedRed; . > und hat alle Funktionen der Klasse schön als inline declariert, handelt > man sich während des Debuggens Unannehmlichkeiten ein. Während des > Debuggens mit der Optimierung -O0 macht der Compiler richtige > Funktionsaufrufe und keine inline Funktionen. Klar kann man jetzt beim > Debuggen z.B. -O1 benutzen, damit kann man aber häufig nicht mehr > richtig Debuggen. Hätte man die in C üblichen Makros für die Gpio-Ports > benutzt wäre das Problem nicht vorhanden. Gerade in Interrupt-Routinen > ist so ein Verhalten nervig. Klar kann man das Umschiffen oder > Optimierungs-Pragmas in den Code einbauen, aber schön ist das trotzdem > nicht. > Alles in allem muss man bei C++ als Effekt immer im Auge haben, dass die > Laufzeitunterschiede -O0 zu -O2 in der Regel deutlich größer sind als > unter C. Vielfach stört das nicht, aber wenn dann verflucht man es. Man kann natürlich auch speziell für's Debuggen vorgesehene Option -Og benutzen, dann wird das Programm nicht "entstellt", aber auch nicht wie bei -O0 Registerinhalte immer wieder ohne Grund stupide neu geladen.
Carl D. schrieb: > Man kann natürlich auch speziell für's Debuggen vorgesehene Option -Og > benutzen, dann wird das Programm nicht "entstellt", aber auch nicht wie > bei -O0 Registerinhalte immer wieder ohne Grund stupide neu geladen. Allerdings hilft es nicht bei dem oben genannten Problem mit dem Inlining.
Beitrag #5242474 wurde von einem Moderator gelöscht.
Beitrag #5242610 wurde von einem Moderator gelöscht.
Beitrag #5242750 wurde von einem Moderator gelöscht.
Beitrag #5243575 wurde von einem Moderator gelöscht.
Beitrag #5243732 wurde von einem Moderator gelöscht.
Beitrag #5243772 wurde von einem Moderator gelöscht.
Beitrag #5243804 wurde von einem Moderator gelöscht.
Beitrag #5243812 wurde von einem Moderator gelöscht.
Beitrag #5243817 wurde von einem Moderator gelöscht.
Beitrag #5243832 wurde von einem Moderator gelöscht.
Beitrag #5244017 wurde von einem Moderator gelöscht.
Beitrag #5244356 wurde von einem Moderator gelöscht.
Beitrag #5244784 wurde von einem Moderator gelöscht.
Beitrag #5244826 wurde von einem Moderator gelöscht.
Beitrag #5245003 wurde von einem Moderator gelöscht.
Beitrag #5245303 wurde von einem Moderator gelöscht.
Beitrag #5245314 wurde von einem Moderator gelöscht.
Beitrag #5250600 wurde von einem Moderator gelöscht.
Beitrag #5250607 wurde von einem Moderator gelöscht.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.