C-Sources ---> C++
-
Auf Deutsch, du will deinen alten C-Code in C++ protieren, damit du nur noch eine technologie hast??
-
Gründliches review wird so oder so gemacht, aus verschiedenen gründen, unterdessen weil
altes an manchen stellen nicht mehr gut genug ist
oder die funktionalität statt selber zu machen aus C++-libs geholt werden soll
oder die resourcenverwaltung einheitlich werden soll u s w ...und die C++technologie kann man gut gebrauchen, um das ganze übersichtlicher und kontrollierbar zu machen
Gruß
-
Deine Frage impliziert aber genau das Gegenteil. Dort stand dass du möglichst viel von dem alten C-Code wiederverwenden willst.
Grudsätzlich solltest du bei solchen Änderungen in kleinen Schritten vorgehen. Wenn du in etwa im Kopf hast wie das Design hinterher aussehen soll, fang an in kleinen Schritten Änderungen in die richtige Richtugn zu machen, und zwar so dass dein programm nach den einzelnen Schritten wieder compiliert und immernoch alle Tests besteht. Der Aufwand ist dann zwar etwas größer als wenn man den alten Kram einfach wegwirft und alles neu schreibt, dafür ist die Fehlersuche sehr viel einfacher, wenn mal einer auftaucht.
-
sorry, habe mich falsch ausgedrückt
Danke für den Tipp!
-
pumuckl schrieb:
Der Aufwand ist dann zwar etwas größer als wenn man den alten Kram einfach wegwirft und alles neu schreibt, dafür ist die Fehlersuche sehr viel einfacher, wenn mal einer auftaucht.
Da widerspreche ich mal.
-
volkard schrieb:
pumuckl schrieb:
Der Aufwand ist dann zwar etwas größer als wenn man den alten Kram einfach wegwirft und alles neu schreibt, dafür ist die Fehlersuche sehr viel einfacher, wenn mal einer auftaucht.
Da widerspreche ich mal.
Ich weiß zwar nicht welchem Teil du da mal widersprichst, aber:
- Der Aufwand ist größer, wenn man ständig neu compiliert und die Tests durchlaufen lässt.
- Die Fehlersuche ist deutlich einfacher. Wenn ich weiß dass der Fehler durch die einzelne kleine Änderung erfolg ist die ich grade vorgenommen hab ist der Code in dem ich suchen muss begrenzt und die möglichen Fehlerursachen überschaubar. Wenn ich aber mal eben das komplette Modul neugeschrieben habe viel Spaß beim Suchen.
-
pumuckl schrieb:
volkard schrieb:
pumuckl schrieb:
Der Aufwand ist dann zwar etwas größer als wenn man den alten Kram einfach wegwirft und alles neu schreibt, dafür ist die Fehlersuche sehr viel einfacher, wenn mal einer auftaucht.
Da widerspreche ich mal.
Ich weiß zwar nicht welchem Teil du da mal widersprichst, aber:
- Der Aufwand ist größer, wenn man ständig neu compiliert und die Tests durchlaufen lässt.
- Die Fehlersuche ist deutlich einfacher. Wenn ich weiß dass der Fehler durch die einzelne kleine Änderung erfolg ist die ich grade vorgenommen hab ist der Code in dem ich suchen muss begrenzt und die möglichen Fehlerursachen überschaubar. Wenn ich aber mal eben das komplette Modul neugeschrieben habe viel Spaß beim Suchen.Zwei Fehlerklassen führen mich auf diese merkwürdigen Gedanken: Die verdammt-schwierig-zu-findenden-Fehler, die so gemein sind, daß sie den Vorgängern schon unterlaufen sind, und die ich beim Reimplementieren gar nicht erst mache. Natürlich tauchen sie auch in der spzialgemeinen Version auf, daß ein Fehler bloß durch das Umschreiben nach C++ auftaucht, und ich denke, das Umschreiben wäre fehlerhaft gewesen.
Und die frühen Designfehler, welche Folgedesignfehler und Folgefolgedesignfehler zur Folge hatten und am Ende der wahre Grund für den ganzen Bloat sind, und die ich beim Reimplemetieren gar nicht erst mache.
-
Ich denke es kommt drauf an wie groß das Projekt ist. Bei sehr großen Projekten sollte man meiner Meinung nach in kleinen Schritten umstellen, so dass immer ein Funktionsfähiger Zwischenstand vorhanden ist. Also quasi ein Kompromiss zwischen volkards und pumuckls Meinung.
-
volkard schrieb:
Zwei Fehlerklassen führen mich auf diese merkwürdigen Gedanken: Die verdammt-schwierig-zu-findenden-Fehler, die so gemein sind, daß sie den Vorgängern schon unterlaufen sind, und die ich beim Reimplementieren gar nicht erst mache. Natürlich tauchen sie auch in der spzialgemeinen Version auf, daß ein Fehler bloß durch das Umschreiben nach C++ auftaucht, und ich denke, das Umschreiben wäre fehlerhaft gewesen.
Diese extraätzenden Fehler gibts natürlich in jedem Code. In dem bereits vorhandenen Code sind aber allein durch die längere Lebenszeit schon einige dieser Fehler aufgefallen und behoben worden. Keine Frage dass da vermutlich noch einige (wenige) schlummern über die du stolperst beim Umbau und die auch erstmal behoben sein wollen. Und auch keine Frage dass du beim Neuschreiben des Codes mindestens ebenso viele extraätzende Fehler einbauen wirst, die irgendwann in der Folge auftauchen und gefunden und behoben werden wollen. Ob du also jetzt die noch nicht behobenen Fehler deiner Vorgänger ausmerzen musst oder deine Nachfolger deine neu erzeugten Fehler ausmerzen müssen, die Zahl der Fehler wird sich bei komplett neuem Code tendenziell nicht verringern sondern eher erhöhen.
Und die frühen Designfehler, welche Folgedesignfehler und Folgefolgedesignfehler zur Folge hatten und am Ende der wahre Grund für den ganzen Bloat sind, und die ich beim Reimplemetieren gar nicht erst mache.
Die frühen Designfehler fallen dir beim Umbauen auf und führen so dazu, dass du sie beheben kannst, während du die bewährten Designelemente beibehalten kannst. Die neuen Designfehler, die du machst während du alles neu schreibst, fallen dir aber nicht auf und bleiben der Nachwelt erhalten und sorgen dann eben später für Mehraufwand.
-
pumuckl schrieb:
die Zahl der Fehler wird sich bei komplett neuem Code tendenziell nicht verringern sondern eher erhöhen.
Hier liegt der Unterschied.
Meine Erfahrung sagt mir, daß die Fehlerdichte durch Neubauen sich ganz enorm rapide vermindert. Wenn Du andere Erfahrungen hast, ist damit auch vollständig erklärt, weshalb Du hier kleckerst und ich klotze.
-
volkard schrieb:
pumuckl schrieb:
die Zahl der Fehler wird sich bei komplett neuem Code tendenziell nicht verringern sondern eher erhöhen.
Hier liegt der Unterschied.
Meine Erfahrung sagt mir, daß die Fehlerdichte durch Neubauen sich ganz enorm rapide vermindert. Wenn Du andere Erfahrungen hast, ist damit auch vollständig erklärt, weshalb Du hier kleckerst und ich klotze.Das hängt vermutlich sehr stark von der Erfahrung und den Fähigkeiten der beteiligten Entwickler ab (Erzeuger des Altcodes und Neubauer/Umbauer), aber eben auch davon, wie gepflegt und bugfrei der Altcode schon ist. Ein erfahrener Entwickler kann vermodernden Uraltcode sicherlich schnell durch neuen, besseren Code ersetzen, während ein weniger erfahrender Entwickler gut gepflegten Code, der lediglich ein neues Design braucht, besser schrittweise umstrukturiert als alles in die Tonne zu treten und in einem Wurf neu aus dem Ärmel zu schütteln
sava kann am Besten selber beurteilen wie erfahren er ist und wie gut der Code ist. Wenn es sich um gut funktionierenden C-Code handelt, der weitgehend fehlerfrei ist und nur in C++ portiert werden muss würde ich tatsächlich schrittweise vorgehen, z.B. erst Arrays durch Container ersetzen, soweit sinnvoll, dann zusammen gehörende Funktionalität in Klassen zusammenfassen usw.
-
pumuckl schrieb:
Das hängt vermutlich sehr stark von der Erfahrung und den Fähigkeiten der beteiligten Entwickler ab (Erzeuger des Altcodes und Neubauer/Umbauer), aber eben auch davon, wie gepflegt und bugfrei der Altcode schon ist. Ein erfahrener Entwickler kann vermodernden Uraltcode sicherlich schnell durch neuen, besseren Code ersetzen, während ein weniger erfahrender Entwickler gut gepflegten Code, der lediglich ein neues Design braucht, besser schrittweise umstrukturiert als alles in die Tonne zu treten und in einem Wurf neu aus dem Ärmel zu schütteln
sava kann am Besten selber beurteilen wie erfahren er ist und wie gut der Code ist. Wenn es sich um gut funktionierenden C-Code handelt, der weitgehend fehlerfrei ist und nur in C++ portiert werden muss würde ich tatsächlich schrittweise vorgehen, z.B. erst Arrays durch Container ersetzen, soweit sinnvoll, dann zusammen gehörende Funktionalität in Klassen zusammenfassen usw.Jo.