Forum: PC-Programmierung Migrieren von C auf C++ in einer bestehenden Legacy(Uralt)-Software


von exfhler (Gast)


Lesenswert?

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
von Oliver K. (okraits)


Lesenswert?

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

von Atmi (Gast)


Lesenswert?

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.

von exfhler (Gast)


Lesenswert?

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

von Arne (Gast)


Lesenswert?

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.

von Sven P. (Gast)


Lesenswert?

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

von bloat (Gast)


Lesenswert?

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

von bloat (Gast)


Lesenswert?

in fefes talk:

You get an error message? You start fudging the code until it compiles.

haha das kommt mir bekannt vor

von Mark B. (markbrandis)


Lesenswert?

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.

von Oliver K. (okraits)


Lesenswert?

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.

von Rufus Τ. F. (rufus) Benutzerseite


Lesenswert?

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.

von Karl H. (kbuchegg)


Lesenswert?

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.

von Vlad T. (vlad_tepesch)


Lesenswert?

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.

von Loonix (Gast)


Lesenswert?

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)

von Mark B. (markbrandis)


Lesenswert?

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

von exfhler (Gast)


Lesenswert?

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++?

von exfhler (Gast)


Lesenswert?

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.

von Karl H. (kbuchegg)


Lesenswert?

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.

von hagbard (Gast)


Lesenswert?

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.

von Mark B. (markbrandis)


Lesenswert?

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.

von D. I. (Gast)


Lesenswert?

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 :>

von Loonix (Gast)


Lesenswert?

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.

von Vlad T. (vlad_tepesch)


Lesenswert?

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

von Arc N. (arc)


Lesenswert?

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

von Simon B. (nomis)


Lesenswert?

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

von Matthias H. (experimentator)


Lesenswert?

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
Noch kein Account? Hier anmelden.