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