Hi Leute, ich wollte mal eure Meinung dazu hören. Ich entwickle als Außenstehender in einem Projekt in einer Firma - die Automatisierungssoftware entwickelt und fast alles in C geschrieben wurde - das wächst nun seit schon 10 Jahren so (ca Millionen Zeilen Code alles zusammen). Nun wird daran gedacht neue Implementierungen in C++ durchzuführen. Obwohl man will nicht viel Geld in Schulungen für C++ investieren. In C sind die Leute fit, C++ ist für die meisten Neuland. Und obwohl der Kunde denen eh schon aufsitzt und er diesen Aufwand nicht bezahlen würde, denken die doch ernsthaft bald mal neuere Sachen mit C++ zu beginnen. Ein paar spezielle Dinge sind aber schon in C++ realisiert worden, da kennen sich 2 Leute in dem Team momentan aus. Ich denke das wird 2 Schwierigkeiten haben: Man will die Zeit für Schulungen nicht zahlen udn außerdem in der Projektzeit ist man eh schon hintendran. Wenn man C++ einsetzen will soll man fähige Leute haben und gleich eine neue Software realisieren von der grünen Wiese aus (aber dann am besten eh gleich Java). Ich werde denen sagen, dass ein Mischbetrieb von C und C++ keinen Sinn hat. Wenn dann gleich ordentlich und neu aber dann mit Java. Was meint ihr?
:
Verschoben durch Admin
Da fehlt die wichtigste Information: um welche Plattform geht es überhaupt? Welcher Prozessor, evtl. welches OS, wieviel Programmspeicher?
exfhler schrieb: > Ich werde denen sagen, dass ein Mischbetrieb von C und C++ keinen Sinn > hat. Wenn dann gleich ordentlich und neu aber dann mit Java. Was meint > ihr? Ohne die Anforderungen zu kennen, kann man hier leider garnichts sagen. C++ ist eine sehr komplizierte Programmiersprache, da der Sprachumfang wirklich gigantisch ist (sobald man von den grundlegenden OOP Funktionen weggeht, erstickt man in den Spezifikation). Die Lernkurve für Neulinge ist sehr, sehr flach - man muss viel lesen, bevor man eine Aufgabe im C++-Stil elegant gelöst hat. Leute die C++ können, wissen das in der Regel und lassen sich fürstlich dafür bezahlen, nahezu gescheiterte Projekte zu retten. Es würde eher mehr Sinn machen, das Projekt in C sauber zu strukturieren. Das dies funktioniert, zeigt ja der Linux-Kernel (dieser ist zwar das Gegenteil von sauber dokumentiert, aber dank Git gibt es einen sehr sauberen Entwicklungsprozess). Einen Mischbetrieb von C und C++ sollte man zwingend vermeiden. C++ meidet die klassischen C-Pointer, das gibt ein endloses Chaos mit den Compilern und Makefiles. Frohes Debuggen.
Oliver K. schrieb: > Da fehlt die wichtigste Information: um welche Plattform geht es > überhaupt? Welcher Prozessor, evtl. welches OS, wieviel > Programmspeicher? Bin erst frisch dabei..ich weiß nur der Kunde der diese Software einsetzt hat immer die neuesten IBM-Server und Prozessoren laufen.. Entwickelt usw und kompiliert wird auf einer IBM AIX 5 oder so
Atmi schrieb: > Einen Mischbetrieb von C und C++ sollte man zwingend vermeiden. C++ > meidet die klassischen C-Pointer, das gibt ein endloses Chaos mit den > Compilern und Makefiles. Frohes Debuggen. Kann ich bestätigen. Musste ich zweimal erleben bisher, dass mit C++ ein C Projekt kaputt gemacht wurde. War dann in der letzten Firma auch mein Grund den Vertrag nicht zu verlängern.
Gibt es einen triftigen Grund, auf C++ zu migrieren, also außer dass das Management es für 'ganz toll' hält? <Metapher> C++ ist kompliziert, fehleranfällig und schwer wartbar. Die meisten Leute behaupten das Gegenteil, als ob C++ all diese Probleme lösen würde. Dass liegt dann oft (oft, nicht immer!) daran, dass sie C++ nicht beherrschen. Diejenigen, für die C++ diese Probleme zu lösen vermag, und die gleichzeitig tief in der Materie stecken wollen, sind entweder Lügner oder ernstlich gute Programmierer (sic). </Metapher> In den meisten Fällen taucht diese Metapher beim Debuggen auf. Man sieht einem Stück C++-Text leider viele Dinge nicht mehr an, der Text wird schnell undurchsichtig. Klar, solange man oben drauf herumschwimmt, ist das alles ganz toll und einfach. Muss man aber mal tiefer rein, steht man alsbald oft in einem Klassenwald. Fefe hatte da mal einen amüsanten Vortrag gehalten: http://www.fefe.de/c++/ Auch: http://www.horstmann.com/cpp/pitfalls.html
man kann in c++ alles das machen, was in c auch geht mit kleinen Versüßungen. Man mus also nicht den vollen Umfang der Sprache nutzen, um effektiv zu programmieren. Ob das Programm unübersichtlich wird, obliegt doch nur dem Geschick des Programmierers und kann in c sicherlich genauso schnell passieren
in fefes talk: You get an error message? You start fudging the code until it compiles. haha das kommt mir bekannt vor
Es stimmt zwar, dass man in C++ manches eleganter lösen kann als in C, vor allem wenn man sich mit Entwurfsmustern gut auskennt. (an dieser Stelle folgt der obligatorische Verweis auf das Buch "Design Patterns") Aber: Ein Entwickler, der gut in C ist, muss noch lange nicht gut in C++ sein. C++ ist einfach sehr viel komplexer und objektorientierte Programmierung ist nun mal etwas anderes als prozedurale Programmierung. Wobei man in C++ beides machen kann, aber wenn man nicht OOP machen will, wozu dann C++? Eines gilt immer: Die Programmiersprache soll zur Aufgabenstellung passen. Wenn man die Aufgabe in C gut lösen kann, und es noch dazu eine vorhandene sehr große Codebasis gibt, dann sehe ich zunächst mal keinen vernünftigen Grund für einen Wechsel der Programmiersprache. Ein solcher Wechsel müsste schon erhebliche Vorteile mit sich bringen, damit der Aufwand gerechtfertigt ist. Hoffentlich kapieren die Entscheidungsträger - wenn das reine BWLer sind, dann sollten sie diese Entscheidung nicht oder zumindest nicht alleine treffen, sondern auf die Empfehlung der Leute hören, die etwas von Softwareentwicklung verstehen.
Ich würde ähnlich wie mein Vorredner Mark sagen: Solange die Anwendung nicht wirklich objektorientierte Programmierung erfordert oder nicht unerheblich viele Funktionen der STL oder von Boost benutzt werden sollen, dann gibt es keinen Grund, auf C++ umzusteigen.
exfhler schrieb: > Ich werde denen sagen, dass ein Mischbetrieb von C und C++ keinen Sinn > hat. Das ist gelinde gesagt Unfug. Selbstverständlich ist ein Mischbetrieb von C und C++ möglich, und gerade bei der Migration einer "legacy"-Anwendung sinnvoll. Das fängt damit an, daß vorhandene C-Libraries sich mit minimalem Aufwand auch aus C++ heraus verwenden lassen, und endet nicht zuletzt damit, daß auch C-Teilanwendungen in einem C++-Wrapper verpackt werden können. Wichtig ist hierbei natürlich, daß die damit beauftragten Entwickler wissen, was sie tun, daß sie wissen, wie sie ihre vorhandenen Strukturen sinnvoll migrieren. Ein Jungspund frisch aus der Uni, der mal ein paar Vorlesungen in objektorientierter Programmierung besucht hat, der wird hierbei gnadenlos scheitern. Die Komplexität real existierender Anwendungen übersteigen die Möglichkeiten des eher theoretischen Wissens bei weitem, wie auch die nächste Frage zeigt: > Wenn dann gleich ordentlich und neu aber dann mit Java. Was meint > ihr? Für Automatisierungssoftware? Halte ich für keine sonderlich gute Idee. Wie deterministisch ist denn das Laufzeitverhalten von Java bzw. anderen GC-basierten Umgebungen? Abgesehen davon würde das bedeuten, sämtlichen vorhandenen Code in die Tonne zu kloppen. Das kann man sich vielleicht im akademischen Kämmerlein leisten, nicht aber, wenn man mit dem Zeug, was man da macht, auch noch Geld verdienen will und in diesem Jahrzehnt auch mal wieder 'ne neue Version herausgeben will.
Ich möchte noch auf etwas eingehen. Natürlich sind Schulungen super. Wenn du aber denkst, du brauchst nur 5 Leute auf eine 3-Wochen Schulung zu schicken und dann können sie in C++ objektorientiert arbeiten, dann täuscht du dich. Eine Schulung ist sicherlich nicht schlecht um erst mal das Grundgerüst zu bekommen, aber wenn ihr in der Firma 2 Leute habt, die OOP können, dann sollen die erst mal das Grundgerüst aufsetzen an das sich dann die anderen halten. Denn ansonsten kommt da etwas raus, was sich zwar C++ schimpft, auch so aussieht, aber letztendlich eine Sache für die Tonne ist. Und nein. Das wäre in Java auch nichts anders. OOP lernt man nicht innerhalb von 2 Wochen. Und wenn einem der Kunde ohnehin schon im Nacken sitzt und man daher Termindruck hat, dann ist der Wechsel der Programmiersprache mit einem Suizid gleichzusetzen. Wenn ihr heute auf OOP und C++ umsteigt, könnt ihr frühestens in 3 bis 4 Jahren mit einer vernünftig umstrukturierten Codebasis rechnen, bei der sich dann der Wechsel ausgezahlt hat und ab wo alles einfacher wird. In der Zwischenzeit werdet ihr mit einem Mischmasch aus C und C++ leben müssen und erst mal wird alles komplizierter. Wobei es in den meisten Firmen in den Sternen steht, ob die Firma bereit ist, die Komplettumstellung zu bezahlen. Einzelne Bereiche werden höchst wahrscheinlich immer so weiterexistieren, dass mehr schlecht als recht Wrapper-Klassen um Funktionssammlung herumgelegt werden und man des öfteren die Krot schlucken muss, etwas zu tun, was den Prinzipien von OOP völlig zuwiederläuft.
kann mich meinen Vorrednern nur anschließen. c++ bietet tolle Vorteile zB durch die STL Auch sieht der Code teilweise sauberer aus, da der Compiler intern sich um Objektpointer und vTables kümmert. allerdings kann man durch übertreibene Vererbungen und wirre Klassenstrukturen auch den Code sehr kompliziert machen. Außerdem kann man sich auch sehr fiese Fallen einbauen. Wenn man meint ein Objekt schön programiert zu haben und irgend was funktioniert dann nicht, ist ie Fehlersuche kompliziert, wenn man sich durch mehrere Ebenen überladener Operatoren, Copyconstruktoren, virtuellen Destruktoren etc. kämpfen muss. Mein Fazit: Ich programmiere recht gern in c++, aber bei bestehender Codebasis würde ich lieber bei der Sprache bleiben. In Embedded-Anwendungen ist es sowieso ratsamer sehr bedacht mit c++ Features umzugehen, da zB eine virtuell überschriebene Funktion schon eine signifikante Verlangsamung einbringen kann. Edit: Was natürlich trotzdem nie schaden kann, ist, bei einem gewachsenen Projekt mal eine Refaktorisierungsrunde einzulegen und ein wenig Struktur hereinzubringen.
Arne schrieb: > Kann ich bestätigen. Musste ich zweimal erleben bisher, dass mit C++ ein > C Projekt kaputt gemacht wurde. War dann in der letzten Firma auch mein > Grund den Vertrag nicht zu verlängern. Hallo Arne, bitte nicht persönlich nehmen, aber ich kann mir nur vorstellen, dass hier eine Ausrede zu lasten des C-Supersets C++ vorgeschoben wurde. Es ist rein auf mangelndes Verständnis zurückzuführen wenn man behauptet ein C-Projekt wäre durch Migration zu C++ "kaputt gegangen". Die einzigen beiden Sprachen, die in einem "Mischbetrieb" sinnvoll funktionieren können, sind meiner Meinung nach genau C und C++. exfhler schrieb: > Ich werde denen sagen, dass ein Mischbetrieb von C und C++ keinen Sinn > hat. Wenn dann gleich ordentlich und neu aber dann mit Java. Was meint > ihr? Wie hier eine Umstellung auf Java den vorher in C ausgebildeten Leuten die Arbeit vereinfachen soll, würde ich mir gerne erklären lassen. PS. Gerade gesehen dass sich schon einige Beiträge pro C/C++ angesammelt haben - never mind. (War zwischenzeitlich nicht am Platz)
Rufus Τ. Firefly schrieb: >> Wenn dann gleich ordentlich und neu aber dann mit Java. Was meint >> ihr? > > Für Automatisierungssoftware? > Halte ich für keine sonderlich gute Idee. Wie deterministisch ist denn > das Laufzeitverhalten von Java bzw. anderen GC-basierten Umgebungen? Dass Java für solche Dinge generell ungeeignet ist, gehört eher in den Bereich der Mythen und Legenden ;-) Freilich braucht man für technische Steuerungen etc. eine geeignete Virtual Machine. Solche existieren, auch für Echtzeitanforderungen. Zu dem Thema siehe auch den folgenden Link: http://www.sigs-datacom.de/fileadmin/user_upload/zeitschriften/js/2010/05/walter_JS_05_10.pdf Natürlich bleibt dann immer noch das Problem, die vorhandene Codebasis weitgehend wegschmeißen zu können. Das macht man nicht mal eben so, nur weil irgend jemand (am besten noch einer ohne echte Ahnung von Softwareentwicklung :-/) sagt "Programmiersprache X ist ganz toll, die nehmen wir jetzt".
Vielen Dank für eure guten Kommentare, bei mir ist es eben auch so, erst frisch die FH bzw Uni absolviert, erst 1 Jahr Berufserfahrung und es kam zu diskutieren ob neue Implementierungen an der alten Software in C++ vorgenommen werden sollen oder nicht, da tu ich mir ein bisschen schwer. Also ist der Mischbetrieb von C/C++ doch sinnvoll? Kann ich mir aber nicht vorstellen - das sind ja zwei ganz verschiedene Paradigmen. Einerseits prozedural andererseits objektorientiert. Die werden sich doch wohl ob kurz oder lang in die Quere kommen.. und dann beim debuggen? Welche Entwicklertools braucht man zB für C++?
Das is es eben.. in der Praxis geschieht eben leider vieles anders als auf der Uni :( Da hat man noch Software refactoren dürfen, Sachen ausprobieren können, etwas experimentieren.. in der Praxis soll alles nur Geld bringen, man ist in einem Zeitdruck, usw jeder Arbeitstag ist ein verfluchter Tag. Glaub werd wieder zurück auf die Uni gehen, doch vorher sammmel ich ein paar Jahre Praxiserfahrung.
exfhler schrieb: > Also ist der Mischbetrieb von C/C++ doch sinnvoll? Aus ökonomischer Sicht: natürlich Aus technischer Sicht: auf keinen Fall > Kann ich mir aber > nicht vorstellen - das sind ja zwei ganz verschiedene Paradigmen. Man muss ja in C++ nicht OOP programmierern. C++ geht prozedural genausogut wie C. > doch wohl ob kurz oder lang in die Quere kommen.. Wenn man es kann, dann nicht. > und dann beim > debuggen? Ist kein Problem. > Welche Entwicklertools braucht man zB für C++? Die Frage ist eher: Welche Entwicklertools für C++ gibt es, die nicht gleichzeitig auch C beherrschen.
Ich muss erstmal sagen das C durchaus für den Mischbetrieb mit anderen Sprachen geeignet ist (mir fallen da neben C++ noch Ada, MATLAB und Fortran ein). Das setzt aber erstmal vorraus dass die C Quellen einigermaßen sauber strukturiert sind, so dass man einfach entsprechende Wrapper-Klassen drumherum bauen kann. Damit bleibt die alte Codebasis erhalten und neue Funktionen werden dann in C++ direkt realisiert. Die entsprechenden Wrapper sollte aber jemand schreiben der von SW-Architektur einen Plan hat und beide Sprachen wirklich beherrscht. Um aber auf die Frage des Openers zurück zu kommen: Ich würde es sein lassen solange ein Projekttermin drängelt. Weil zu Verzögerungen wird es garantiert durch so eine Umstellung kommen.
Karl heinz Buchegger schrieb: > Man muss ja in C++ nicht OOP programmierern. C++ geht prozedural > genausogut wie C. Muss man nicht, aber dann kann man C++ im Prinzip auch sein lassen. Wobei Exceptions schon nett sind, nur wenn man sie in vollem Umfang nutzen und von der Basisklasse "exception" ableiten will braucht man halt doch wieder OOP... Also C++ haben wollen und ganz auf OOP verzichten wollen - gibt es dafür einen sinnvollen Anwendungsfall? Mir fällt grad keiner ein.
Mark Brandis schrieb: > Also C++ haben wollen und ganz auf OOP verzichten wollen - gibt es dafür > einen sinnvollen Anwendungsfall? Mir fällt grad keiner ein. ICPC :>
Mark Brandis schrieb: > Muss man nicht, aber dann kann man C++ im Prinzip auch sein lassen. Das ist eine sehr eingeschränkte Sicht, fast schon dogmatisch. ;) > Wobei Exceptions schon nett sind, nur wenn man sie in vollem Umfang > nutzen und von der Basisklasse "exception" ableiten will braucht man > halt doch wieder OOP... > > Also C++ haben wollen und ganz auf OOP verzichten wollen - gibt es dafür > einen sinnvollen Anwendungsfall? Mir fällt grad keiner ein. Mir schon. Datenkapselung. Dafür braucht es kein OOP und prinzipiell auch kein C++, klar. Stell dir vor, ANSI-C hätte Namespaces und zumindest die Möglichkeit einfache Klassen zu verwenden. Die Notation wäre klarer und eine ganze Reihe gefährlicher Leichtsinnsfehler könnte so vermieden werden. P.S. Diese Sichtweise gefällt mir eigentlich auch nur im Embedded-Bereich, dem TE ist damit natürlich nicht geholfen.
Mark Brandis schrieb: > Also C++ haben wollen und ganz auf OOP verzichten wollen - gibt es dafür > einen sinnvollen Anwendungsfall? Mir fällt grad keiner ein. definitv: die STL mit ihrer String- und den Container-Klassen
Vlad Tepesch schrieb: > Mark Brandis schrieb: >> Also C++ haben wollen und ganz auf OOP verzichten wollen - gibt es dafür >> einen sinnvollen Anwendungsfall? Mir fällt grad keiner ein. > > definitv: > die STL mit ihrer String- und den Container-Klassen Solange alles funktioniert... Funktioniert's nicht, debuggt man u.U. durch die STL... aber man kann C++-Compiler auch nehmen, um nur den Code besser überprüfen zu lassen... Bspw. die implizite Umwandlung von void* in was anderes geht nur in C, nicht in C++ da muss explizit gecastet werden oder Funktionsprototypen ohne Argumente (sind in C Funktionen, die mit beliebig vielen Argumenten aufgerufen werden können).
Ich möchte der Diskussion eigentlich nur noch hinzufügen, dass man in C durchaus objektorientiert programmieren kann. Es fehlt zwar einiges an syntaktischem Zucker, aber das hindert einen ja nicht daran, das Konzept der objektorientierten Programmierung umzusetzen. Es gibt übrigens einige Free-Software Projekte, die das erfolgreich umsetzen, dann meistens auf der Basis der glib/gobject-Bibliothek. Viele Grüße, Simon
Ich muß ehrlich sagen, eine Neuimplementation einer großen, bestehenden Codebasis in Java erscheint mir als ziemlicher Blödsinn. Java ist (außer mit speziellen, teuren JVMs - und alles, was erst mal viel Zeit und Geld kostet, ohne große, sichtbare Fortschritte zu bringen, ist üblicherweise Firmen schwer vermittelbar) nicht echtzeitfähig und damit für Steuerungszwecke weitestgehend ungeeignet. Und der Glaube, vorhandenen, jahrelang gewachsenen Code "mal eben so" in einer anderen Sprache neu implementieren zu können, ist extrem naiv und nur durch mangelnde Erfahrung zu erklären. Zumal damit das Problem, daß die Entwickler nur C können, noch nicht gelöst ist. Eine schrittweise Umstellung auf Java wäre allerdings möglich, indem bestehender C-Code durch JNI angesprochen wird. Das würde aber erst mal eine sorgfältige Strukturierung des alten Codes verlangen, oder eine aufgesetzte neue Schnittstelle, ... Integration von C-Code und C++-Code ist in der Regel kein Problem, wenn man es systematisch angeht, da C++, von wenigen, exotischen Ausnahmen abgesehen, eine echte Obermenge von C ist. Die Verwendung von C in C++ ist weitestgehend problemlos (Ausnahme: Bezeichner, die in C++ reserviert sind), wenn man den C-Code so weit ändern darf, daß die üblichen "#ifdef __cplusplus extern "C" {..."-Blöcke eingefügt werden können. Die Verwendung von C++-Code in C-Code ist ekelig und manchmal fast nicht praktikabel, da man Wrapper-Funktionen mit C-Aufrufkonvention schreiben muß, speziell aufwendig, falls Klassen verwendet werden, und sollte daher vermieden werden, wo möglich. Es ist schwer, etwas zu dem Problem zu sagen, ohne den bestehenden Code und die Umgebung zu kennen. Wahrscheinlich würde ich einen Umstieg auf C++ folgendermaßen angehen: - Es wird festgelegt, welche Programmteile vorläufig in C bleiben, damit die C-Programmierer etwas zu tun haben. - Neue Programmteile werden in C++ geschrieben, wobei erst einmal prozeduraler C-Stil beibehalten werden kann. - Es wird ein Style Guide festgelegt, mit dem C++-Features für die C-Programmierer in mehreren Stufen eingeführt werden. Das kann man dann in internen Schulungen machen, um die Programmierer nicht auf unerwünschte und überteuerte externe Schulungen schicken zu müssen. Anfangen sollte man mit Features, die leicht verständlich sind, etwas nutzen und Fehler vermeiden können, aber niemandem wehtun, z. B. echte Konstantendefinitionen anstelle von #define-Makros, erleichterte Typdefinitionen, Call by reference, ... Der Style Guide muß auch festlegen, welche Features von C++ und der STL noch nicht oder normalerweise überhaupt nicht benutzt werden sollten, da C++ eine große und zerbrechliche Sprache ist. Auch würde ich in so einer Umgebung z. B. wahrscheinlich auf die Verwendung von STL-iostream verzichten und weiter die printf()-Familie und Konsorten verwenden, da Mischbetrieb hier extrem fehleranfällig ist und iostream außer stark verbesserter, aber immer noch nicht perfekter Typsicherheit kaum Vorteile, aber einige Nachteile bietet. Man könnte auch überlegen, auf die STL weitgehend zu verzichten und andere Bibliotheken zu benutzen. Wenn z. B. GUIs geplant sind, dann evtl. QT. - C++-Features wie Klassen dürfen von "neuen" Programmierern nur mit regelmäßigen Besprechungen und Code Reviews mit erfahrenen C++-Programmierer verwendet werden. - Man sollte nicht glauben, daß es nötig oder sinnvoll wäre, jedes Problem mit "esoterischen" C++-Sprachfeatures wie komplizierten Klassenhierarchien, womöglich noch Template-Klassen, Operator Overloading usw. zu lösen, nur weil es möglich ist, und Entwickler, die darauf bestehen, sehe ich eher als Hacker denn als Softwareingenieure. - Man sollte ebenfalls nicht glauben, daß objektorientierte Programmierung oder Design Patterns (ausgenommen natürlich Patterns, die Probleme objektorientierter Programmiersprachen adressieren ;-)) zwingend eine objektorientierte Programmiersprache erfordern. Allerdings ist diese sehr empfehlenswert, um unnötige Komplexität zu vermeiden. Viel mehr kann ich zu den Problem nicht sagen, ansonsten müßte ich es mir erst einmal ansehen und konkreter ausarbeiten (zum im Freiberuflermarkt branchenüblichem Tagessatz, versteht sich ;-)).
Bitte 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.