Hallo, wir haben ein größeres Softwareprojekt laufen, welches in (ANSI) C programmiert ist. Das Projekt ist für eine Steuereinheit, besteht etwa aus 125 Programm-Modulen mit jeweils einer mittleren Größe von 300 Programmzeilen pro Modul. Ich war vor kurzem auf einem Vortrag, in dem die Vorteile von C++ gegenüber C aufgezeigt wurden, unter anderem sollen dies sein: - Optimal wiederverwendbare Software-Komponenten ohne jeglichen Laufzeit-Overhead zu entwickeln. - C++ läßt sich wesentlich ökonomischer entwickeln als mit der Programmiersprache C. Denn selbst auf 8-Bit-Mikrocontrollern lassen sich mit C++ realisierte wiederverwendbare Software-Komponenten praktisch ohne Overhead gegenüber derselben in C implementierten Funktionalität nutzen. Da ich diesbezüglich keine Erfahrung habe, würde mich eure Meinung dazu interessieren.
Mal kurz die Diskussion zusammen fassen: C ist Scheiße C++ ist Scheiße Alles Beide Scheiße Pascal/Delphi ist das Wahre Basic machst besser Alles Schrott außer Java Warum nicht perl/python/lua
Nachdem ich mittlerweile D kenne, frage ich mich, was ich an C++ je gut gefunden habe. C++ bringt zwar viele neue Konzepte mit sich, ist aber im Kern ein einziges zusammengebasteltes Desaster. Wenn ich z.B. an Templates oder Streams denke... Wenn ihr euch mit C wohl fühlt und ihr die Strings im Griff habt, dann würde ich dabei bleiben.
C++ ist generell sehr umfangreich und es macht keinen Sinn die komplette Funktionalität auf einem kleinen Controller nutzen zu wollen. Persönlich stand ich vor einem ähnlichen Problem und habe die Software in C++ neu strukturiert und umgesetzt. Teilweise ist es viel schöner geworden, teilweise aber deutlich nicht. Manche Funktionalitäten konnte ich nicht wieder umsetzen, weil dann das Durcheinander (alles ist ein Objekt) zu groß geworden wäre. Natürlich kann man sagen, "Trottel, lern halt gescheites C++" und hätte damit auch Recht, aber das hilft mir nicht weiter. Meine Quintessenz ist, dass C++ schwerer richtig (TM) zu benutzen ist als C und man noch mehr falsch machen kann. Ob es Sinn macht umzusteigen würde ich an folgenden Kriterien festmachen: 1. Es stehen fähige Leute zur Verfügung, die C++ können und wollen 2. C steht mir im Weg bzw. gibt es mehrere Stellen die man in C++ viel besser lösen könnte 3. Das Design des C-Codes ist so, dass ich schrittweise portieren kann oder einfach neue Funktionalitäten in C++ erstellen kann Den Bullshit von der Wiederverwendbarkeit kannst Du bei allem was ich in meinem Berufsleben im Embedded-BEreich erleben musste getrost vergessen. Wer Code in C schreibt der nicht wiederverwendbar ist, schreibt auch in C++ eben solchen Code. Right tool for the right people.
Karl schrieb: > Den Bullshit von der Wiederverwendbarkeit kannst Du bei allem was ich in > meinem Berufsleben im Embedded-BEreich erleben musste getrost vergessen. > Wer Code in C schreibt der nicht wiederverwendbar ist, schreibt auch in > C++ eben solchen Code. Right tool for the right people. Das ist auch meine Erfahrung! Man sagt so über den Daumen, dass zwischen Code, den man für sich selbst schreibt und Code, der wirklich wiederverwendbar ist, Faktor 10 liegt. Ich würde einfach mal versuche, den bestehenden Code mit einem C++ compiler zu übersetzen, bzw. ihn übersetzbar zu machen und von da aus Starten und C++ entdecken. (class enums, function overloads, etc.). Ein Problem könnte sein, wenn Ihr viel designated initializer verwendet, die gibt es in C++ leider nicht, aber die meisten C++ compiler unterstützen es wahrscheinlich. Viel Spaß! Torsten
Wiederverwendbarkeit setzt eine gewisse Generizität der Softwaremodule voraus. Diese Generizität bekommt man nicht geschenkt, sondern man muss sie sich hart erarbeiten. C++ stellt dafür einige Hilfmittel bereit, als wichtigstes davon die Template-Programmierung. Um ein Modul generisch (und damit wiederverwendbar) zu machen, muss man sich vorher schon der potentiellen zuküftigen Anwendungsfälle bewusst sein. Sonst läuft man Gefahr, das Modul mit viel Aufwand in 100 Eigenschaften variabel zu halten, am Tag der Wiederverwendung stellt man aber fest, dass die Eigenschaft 101 nicht passt. Man kann dann zwar versuchen, die nicht passende Eigenschaft nachträglich ebenfalls variabel zu machen, muss dafür aber u.U. das Modul komplett überarbeiten und das Ergebnis ausgiebig auf seine Konformität mit allen bisherigen Anwendungen testen. Das ist alles mit einem großen Aufwand verbunden, der mit dem Aufwand für das "klassische" Vorgehen (bei der Wiederverwendung Quellcode kopieren und an die neuen Gegebenheiten anpassen) gegengerechnet werden muss. Leider ist sind die Aufwände der beiden Vorgehensweisen im Voraus nur sehr schwer abschätzbar. Beispiele für guten generischen Code findet man in der Standarbibliothek von C++ (bspw. die Container-Klassen) und in den Boost-Bibliotheken. Aber mal ganz ehrlich: So programmiert kein gewöhnlicher Entwickler. Die allermeisten können das nicht einmal, selbst wenn sie wollten und genügend Zeit dazu hätten. Generischer Code ist i.Allg. auch sehr viel schwerer verständlich und wartbar. Das heißt jetzt nicht, dass C++ bzgl. der Wiederverwendbarkeit keine Vorteile hat. Wenn man aber nach dem Motto "Wir machen ab heute C++, dann wird in Zukunft alles ganz toll" konzeptlos an die Sache herangeht, wird das ganz schnell zu einem Fass ohne Boden. Wenn man aber sicher weiß, dass ein bestimmtes Modul zuküftig zig-mal wiederverwendet wird und den Kontext der Wiederverwendung schon recht genau kennt, kann man durch generische Programmierung in Summe schon einiges an Arbeit einsparen. BTW: Eine Programmiersprache, die eine wesentlich bessere Unterstützung bei der generischen Programmierung bietet als C++, ist Haskell. Generizität auf dem Level wie in der Standarbibliothek von C++ bekommt man dort tatsächlich praktisch geschenkt, ist auch von wenig erfahrenen Programmierern problemlos beherrschbar, und macht den Quellcode überhaupt nicht unübersichtlich oder aufgebläht. Leider zielt Haskell bisher vor allem auf die PC-Anwendungsentwicklung und weniger auf Embedded-System ab.
Dirk B. schrieb: > Mal kurz die Diskussion zusammen fassen: da fehlt noch Assembler als einzig wahre Religion :-) Das wurde hier schon reichlichst diskutiert, nutze die Suchfunktion und du bekommst buchfüllende Threads. Wenn es nicht gerade ein µC mit 2 kB Flash und 512 Byte RAM ist dann kann man C++ gut einsetzen. Gerade die Hardwareeinheiten bieten sich ja an als Objekt betrachtet zu werden. Ein Beispiel findest du in Arduino Code. In Programmen die das nutzen hört C++ und OO allerdings sehr oft sofort nach diesen Objekten wieder auf, du findest da oft meterlangen Spaghetticode. Es kommt also darauf an erstmal einen Plan zu machen welche Objekte es geben soll und wie die miteinander agieren. Da gibt es meist mehrere Lösungen und das ist für den Anfang schon nicht so einfach. Ich hatte schon mit TurboPascal in OO angefangen und den Fehler gemacht zu grosse und komplexe Objekte zu bauen. Die Wiederverwendbarkeit ist auch ein hohes Ziel, ein neues Projekt hat andere Anforderungen und die Komponenten aus einem alten Projekt werden nie zu 100% das können was jetzt gebraucht wird. Bei einigen Sachen geht es gut, bei anderen schlechter. Gut finde ich z.B. eine Displayansteuerung mit gemeinsamen Zeichenfunktionen und der Hardwareschnittstelle als austauschbare Basis.
Holger B. schrieb: > - Optimal wiederverwendbare Software-Komponenten ohne jeglichen > Laufzeit-Overhead zu entwickeln. > > - C++ läßt sich wesentlich ökonomischer entwickeln als mit der > Programmiersprache C. Denn selbst auf 8-Bit-Mikrocontrollern lassen sich > mit C++ realisierte wiederverwendbare Software-Komponenten praktisch > ohne Overhead gegenüber derselben in C implementierten Funktionalität > nutzen. Typisches Bullshit-Bingo Gesülze von jemandem, der wahrscheinlich nie beides in echten größeren Projekten benutzt hat. Karl, Thorsten und Yalu haben es ja schon schön zusammengefasst, was vieleicht noch fehlt: Wenn ihr umsteigen wollt, dann gehe ich davon aus, daß die Entwickler bis jetzt hauptsächlich C programmiert haben. Bis ein erfahrener C-Entwickler in C++ besseren Code schreibt wie vorher in C vergehen Jahre an mühsamen und teils schmerzhaftem Erfahrung sammeln.
Der Andere schrieb: > Bis ein erfahrener C-Entwickler in C++ besseren Code schreibt wie vorher > in C vergehen Jahre an mühsamen und teils schmerzhaftem Erfahrung > sammeln. Oder es passiert nie. Es muss meiner Meinung nach jemand im Team sein, der es schon kann (und nicht nur meint, es zu können. Von außen oft schwer einzuschätzen). Durch Selbststudium und viel Lesen auf Stackoverflow etc ist es schon seeeehr mühsam und nicht immer von Erfolg gekrönt :(
Holger B. schrieb: > Da ich diesbezüglich keine Erfahrung habe, würde mich eure Meinung dazu > interessieren. Meine Meinung: Wenn der bestehende Code von einer guten Qualität ist, dann gewinnst Du nicht viel oder auch gar nichts wenn Du ihn zu einer anderen Programmiersprache hin portierst. Mal abgesehen davon: In der Regel zahlt kein Kunde dafür, die Sprache zu wechseln. Der Kunde will dass seine Anforderungen erfüllt werden. Ob das nun in C oder C++ geschieht ist ihm völlig Schnuppe. Falls der existierende Code aber grottig ist, dann kann es sich sehr wohl lohnen ihn wegzuwerfen und nochmal neu anzufangen. Dabei kann man dann gerne auch die Programmiersprache wechseln. Dann gilt allerdings wie oben gesagt: Wer in C schlechten Code schreibt, der schreibt auch in C++ schlechten Code.
:
Bearbeitet durch User
Man kann ja erst mal den gleichen Code nehmen, und mit dem g++ übersetzen. Und bei Erweiterungen dann Teile auf C++ umstellen. Ob man für alles Vererbung braucht.. meistens nicht. Aber auf std::string und vector-Klassen möchte ich nicht mehr verzichten. Auch die Konstruktoren mit der Kapselung und sauberer Initialisierung sind ein großer Gewinn. Ich nehme auch auf kleinen Embedded Prozessoren C++, weil der Code dann wartbarer wird.
Die Wiederverwendbarkeit würde ich wie Viele hier nicht als schlagendes Argument ansehen. Das ist eigentlich in jeder auch noch so "hohen" Programmiersprache ein Mythos, der durch (legitim) verschiedenen Auffassungen von strukturiertem Code in der Praxis schnell widerlegt wird. Ich bin trotzdem ein glühender Fan von C++ in Embedded, hauptsächlich wegen der natürlicheren Einkapselung von zusammengehörigen Daten in Objekte. Klar, logisch kann man das in C genau so erreichen - wenn man denn diszipliniert genug ist und sich Programmiertechniken angewöhnt, die am Ende des Tages dann wieder stark an C++ erinnern. Ich würde es mal so ausdrücken: C++ (solange man sich auf einen Subset beschränkt) legt dem Entwickler ohne nennenswerte Einbussen in Footprint und Laufzeitverhalten einen disziplinierten Programmierstil näher als C. Was man genau daraus macht, ist dann Jedem seine eigene Entscheidung. Der Lackmustest kommt dann nach 5 Jahren, wenn man alten Code wieder ansehen muss: Erfahrungsgemäss ist auch nur halbwegs sauber geschriebener C++ Code wesentlich besser versteh- und wartbar als (auch sehr gut geschriebener) C Code. Ich widme dem Thema einen guten Teil von Kapitel 10 in meinem Buch. Btw, blöd, habe vergessen noch vor dem Aufkommen des xten threads zu diesem Thema Aktien der Popcornindustrie zu kaufen...
PittyJ schrieb: > Ich nehme auch auf kleinen Embedded Prozessoren C++, weil der Code dann > wartbarer wird. das hat aber wenig mit C++ oder C zu tun. Sonst würde der Linux Kernel auch nicht wartbar sein. Man kann in C genauso wartbaren code schreiben.
PittyJ schrieb: > Ob man für alles Vererbung braucht.. meistens nicht. Kann aber in einzelnen Fällen auch im µC nützlich sein. So lassen sich beispielsweise verschiedene Sensortypen vereinheitlichen. Wenn man vorsichtshalber sowohl DS18x20 als auch LM335 verwendet hat.
M.E. erlaubt C++ bei einem Neudesign (bei vernünftiger Planung und durch Erfahrung erworbene Zurückhaltung bezüglich "Featuritis") eine deutliche Verbesserung, was die Modularität und Wiederverwendbarkeit angeht. M.E. sind diese Voraussetzungen aber leider in den wenigsten Fällen erfüllt. Das erste Projekt wird bei einem Team, das noch nie was mit C++ gemacht hat, mit ziemlicher Sicherheit in die Hose gehen.
Markus F. schrieb: > Das erste Projekt wird bei einem Team, das noch nie was mit C++ gemacht > hat, mit ziemlicher Sicherheit in die Hose gehen. Es sei denn man schult seine Leute vorher vernünftig.
Mark B. schrieb: > Es sei denn man schult seine Leute vorher vernünftig. Das muß dann aber schon ein sehr vernünftige Schulung sein. Es gibt kaum was gefährlicheres als menschlichen Enthusiasmus.
Naja, sein Leben lang bei ein und derselben Programmiersprache festzuhängen kann es aber auch nicht sein.
Markus F. schrieb: > M.E. erlaubt C++ bei einem Neudesign (bei vernünftiger Planung und > durch Erfahrung erworbene Zurückhaltung bezüglich "Featuritis") eine > deutliche Verbesserung, was die Modularität und Wiederverwendbarkeit > angeht. > > M.E. sind diese Voraussetzungen aber leider in den wenigsten Fällen > erfüllt. > > Das erste Projekt wird bei einem Team, das noch nie was mit C++ gemacht > hat, mit ziemlicher Sicherheit in die Hose gehen. Dem würde ich vorsichtig zustimmen, die Frage ist aber, welchen Schluss man daraus zieht - das klingt so win bisschen wie "das erste selbstgebaute Haus ist zur Übung, das Zweite zum Wohnen." Oder anders ausgedrückt - wenn man es nicht riskiert, eines in den Sand zu setzen, wird man niemals ein zweites, drittes... richtig gutes hinbekommen.
Yalu X. schrieb: > Haskell [...] ist auch von wenig erfahrenen > Programmierern problemlos beherrschbar Du beliebst zu scherzen.
Bernd K. schrieb: > Yalu X. schrieb: >> Haskell [...] ist auch von wenig erfahrenen >> Programmierern problemlos beherrschbar Bernd K. schrieb: > ………………i………………………ch……………… Bernd K. schrieb: > ………b……i………………………………………n… Bernd K. schrieb: > …………e…i………………………………………n… Bernd K. schrieb: > …………e…………s……………………e…………… Bernd K. schrieb: > ……………l……………………………………………. So? Na gut, wenn du meinst :)
Holger B. schrieb: > Das Projekt ist für eine Steuereinheit, besteht etwa aus 125 > Programm-Modulen mit jeweils einer mittleren Größe von 300 > Programmzeilen pro Modul. Wir reden also von 40.000 Zeilen Code. Es wäre völlig idiotisch, nach C++ zu migrieren, wenn da nicht jeder Beteiligte im Mittel 1-2 Jahre intensive C++-Erfahrung hat. Bei einem neuen, relativ kleinen Projekt mit *intrinsischemn Willen zur Einarbeitung* spräche hingegen nichts dagegen.
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.