Migrieren von C auf C++ in einer bestehenden Legacy(Uralt)-Software

Da fehlt die wichtigste Information: um welche Plattform geht es 
überhaupt? Welcher Prozessor, evtl. welches OS, wieviel 
Programmspeicher?

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.

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".

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.

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.

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 ;-)).