Da hier ja immer wieder herumgemeckert wird, dass verschiedene C-Ausdrücke oder Schreibweisen nicht allgemeiner Standard und deshalb nicht portierbar und deshalb BÖSE seien, behaupte ich mal provokant: Portierbarer Code ist Käse. Ich schreibe ein Programm IMMER für eine ganz bestimmte Hardware. Ich schreibe Code IMMER so, dass ihn ein ganz bestimmter Compiler versteht. Warum soll ich verschiedene Compiler-spezifische Besonderheiten, die mir möglicherweise die Arbeit erleichtern, einfach ignorieren, bloss damit der Code !PORTIERBAR! bleibt und die heilige Kuh ANSI nicht entehrt wird? Ich behaupte mal, dass man bei einem Compiler-Wechsel sowieso immer irgend was anpassen muss. Wenn ich Code für einen bestimmten Controller schreibe, kann ich auch nicht erwarten, dass der unveränderte Code auf einem anderen Controller ohne Probleme funktioniert, weil die Hardware halt anders aussieht, andere spezifische Register da sind etc. 100% portierbaren Code gibt's nicht. Warum soll ich mir irgendwelche Krämpfe antun, bloss damit ich den selben Code mit mehreren verschiedenen Compilern verwursten kann?
was willst du uns damit sagen? heul doch einfach....vellei wirds besser..
> Ich schreibe ein Programm IMMER für eine ganz bestimmte Hardware. Ich > schreibe Code IMMER so, dass ihn ein ganz bestimmter Compiler versteht. Und? - Ich schreibe dennoch weiterhin portierbaren Code :)
Nur weil man Code nicht immer 100% verwenden kann, bedeutet das doch nicht, dass man alle "Richtlinien" gleich über den Haufen schmeißen muss. Wenn möglich sollte man sich nunmal an Standards halten. Es geht ja nicht darum genau dieses Projekt jetzt auf einer anderen Hardware laufen zu lassen. Man muss ja vlt. auch mal Teile davon in einem anderen Projekt wieder verwenden. Aber was willst du nun eigentlich mit diesem Thread? Niemand zwingt dich dazu. Allerdings können einem dann deine Kollgen leid tun (wenn du das beruflich machst)
>was willst du uns damit sagen?
Ich will dir gar nichts sagen. Ich habe zwei Fragen gestellt. Wenn du
meinen Artikel bis zum Ende liest, wirst du sie vielleicht auch
entdecken.
Hinweis: Eine Frage ist ein Satz mit einem Fragezeichen am Ende. Ein
Fragesteller erhofft sich meistens eine Antwort auf eine Frage.
Unportierbar wrote: > 100% portierbaren Code gibt's nicht. Wüßte nicht, daß jemand mal behauptet hätte, es gäbe ihn. > Warum soll ich mir irgendwelche > Krämpfe antun, bloss damit ich den selben Code mit mehreren > verschiedenen Compilern verwursten kann? Ich krieg dabei keine Krämpfe, wenn ich mal ein bischen überlege, ob das Geschriebene auch später noch verstehbar ist. Und ich sehe ich einen großen Unterschied, ob ich bei neuen Projekten 1..5% anpassen muß oder jedesmal 95% komplett neu schreiben. Ich hab einigen Code aufm 8051 und auf AVR laufen mit nur wenigen Anpassungen. Peter
> Warum soll ich verschiedene Compiler-spezifische Besonderheiten, die mir > möglicherweise die Arbeit erleichtern, einfach ignorieren, bloss damit > der Code !PORTIERBAR! bleibt und die heilige Kuh ANSI nicht entehrt > wird? > Warum soll ich mir irgendwelche > Krämpfe antun, bloss damit ich den selben Code mit mehreren > verschiedenen Compilern verwursten kann? a) Weil eine Software-Lebenszyklus nicht zwingend bei einer neuen Hardware/Plattform zu ende sein muss (sollte, je nach Produkt). b) Weil eventuell mal ein Anderer deinen Code weiterpflegen muss.
> Ich schreibe ein Programm ... Ja, du. Andere Leute schreiben Tools, Bibliotheken. RTOSse, Dateisysteme, Netzwerkstacks, Grafik-Kits. Und die freuen sich, wenn ihr Code mit vielleicht 2 % Anpassung von einem LPC auf einen STR9 übertragbar ist, oder mit 5-10 % Anpassung auf einen PowerPC oder AVR32. Oder, nachdem er mit gcc kompiliert, auch mit Keil oder IAR verträglich gemacht werden kann. Wenn man sich mal die Arbeit macht, spezifischen und allgemeinen Code zu trennen, stellt man fest, dass der allergrößte Teil allgemein ist (außer bei Trivialprogrammen). Also lohnt es sich, diese Trennung zu vollziehen.
Unportierbar wrote: > Warum soll ich mir irgendwelche > Krämpfe antun, bloss damit ich den selben Code mit mehreren > verschiedenen Compilern verwursten kann? Weil der Aufwand bei einem sauberen Design vielleicht 10 % höher wird (man kann die Compilerabhängigkeiten ja bspw. auch in einer Headerdatei kapseln), während es bei einem einmal verkorksten Design und der später dann doch (natürlich völlig ,,unerwartet'') auftretenden Notwendigkeit einer Portierung gleich 50 % oder mehr an Zusatzarbeit sind. Es ist natürlich eine Frage, ob ich mir schnell irgendwas für mich privat zusammenhacke, dass ich jetzt und hier und heute als Testprogramm brauche, oder ob das Ganze ein richtiges Projekt wird, bei dem das Ende des Lebensdauerzyklus nicht ohne weiteres absehbar ist.
> 100% portierbaren Code gibt's nicht. >>Wüßte nicht, daß jemand mal behauptet hätte, es gäbe ihn. hihi, //trollmode on natürlich gibts den... jeder Code ist 100% portierbar! Portieren heißt doch: etwas von hier nach dort bewegen dafür braucht man -das etwas -genügend Kraft -hier und dort nach Fertigstellung hat man dann Kraft*(dort-hier) verrichtet und die alles entscheidende Frage ist nur noch: Wie groß darf Kraft*(dort-hier) für mich persönlich werden? //trollmode off ernsthaft: tictactoe und "hello world" läßt sich wohl ohne großen Aufwand überall hin portieren, aber je größer das etwas und je länger das (dort - hier) desto umfangreicher wird doch der Aufwand. Da kann ich jetzt Peter und Jörg oben nur beipflichten: vernünftig dokumentieren und vernünftig "lesbaren, nachvollziehbaren" Code schreiben, dann hat auch keiner was zu meckern :-)
Unportierbar wrote: > 100% portierbaren Code gibt's nicht. Warum soll ich mir irgendwelche > Krämpfe antun, bloss damit ich den selben Code mit mehreren > verschiedenen Compilern verwursten kann? Ein 4KB C-Programm besteht meist in wesentlichen Teilen aus hardwareabhängigem Code. Da ist diese Stragie vertretbar. Ein 40KB Programm besteht grösstenteils aus Programmteilen, die bei sauberer Programmiertechnik kaum noch oder garnicht mehr von der verwendeten Hardware abhängen. So wird beispielsweise die unterste Ebene eines CAN APIs vom verwendeten Controller abhängen, aber darüber hat man es schon mit CAN Messages zu tun. Es kann sogar sein, dass der hardwareabhängige Teil sich auf ein paar Zeilen SPI beschränkt, weil der externe MCP2515 aus Sicht eines AVR und eines ARM7 ziemlich gleich aussieht. Ähnliches gilt für die üblichen LCDs, DS18B20, SHT11 usw. Portierbarer Code erleichtert also die Übernahme solcher Codemodule erheblich. Man muss schon was ändern. Aber wenig und eng begrenzt.
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.