Meine Erfahrung:

• Software läuft lange. Teile von Software wurden vor zig Jahren geschrieben und sind immer noch irgendwo drin.
• Ich gestalte Software (C/C++) gern so, dass sie von JEDEM Compiler möglichst verarbeitet werden kann, und in jedem System läuft, keine Nutzung von Sonder-Features. Viele Programmierer machen genau das Gegenteil. Immer die Spezialfeatures nutzen.
• Ich bin der Meinung, dass das höchste Gut ist, Software, die unter Windows geschrieben ist, sollte einfach so auch unter Linux laufen (da ich keine Mac habe, weiß ich dazu nichts zu sagen, ansonsten sollte diese Software auch unterm Mac laufen.).
• Positive Erfahrungen sind diesbezüglich zu Java zu nennen, läuft einfach so, Windows, Linux, egal. Java ist ja gerade wegen der Portabilität erfunden worden.
• Es gibt einige Tricks, um Software in C/C++ so zu schreiben, das sie Compiler-/Laufzeitsystem-unabhängig ist. Der Haupt-Trick ist der, alle abhängigen Teile in einer Headerdatei zu sammeln, diese überall zu includieren und für jedes System/Compiler die richtige Version zu haben. Ich nutze ein solches System schon langjährig. Diese system/compilerspezifische Headerdatei heißt bei mir complctr.h. Alle anderen Sourcefiles nutzen Definitionen aus complctr.h und sind damit systemunabhängig.
• Ein wichtiges Thema bei C/C++ ist das alignment-Thema. Ich arbeite grundsätzlich mit Byte-Alignment, gestalte aber alle Strukturdefinitionen so, dass jedes Element auf einer solchen teilbaren Adresse beginnt, wie es seiner Größe entspricht, also ein float auf einer durch 4 teilbaren Adresse, double durch 8 teilbar usw. Dazu muss man in Strukturen entweder geschickt anordnen oder dummies zwischensetzen, Beispiel:

 struct Beispiel
 { int16 a;
   int32 b;  //das ist nicht gut!!!
 }

 struct Beispiel
 { int16 a;
   int16 reserve;
   int32 b;
 }

Die definitionen für int16, int32 stehen übrigens in complctr.h, für die 32-bit-Systeme meist mit

 typedef short int16;  //short ist in diesem System 16 bit breit
 typedef int int32;    //int ist bei diesem System (nicht überall!!) 32 bit breit.

Das Arbeiten mit diesem Alignment schafft Kompatibilität zu allen Systemen (abgesehen von big/little endian). Die Zusatzarbeit ist nicht aufwändig.

ThreadAnlageWiederverwendbar

Also ich finde, "wiederverwendbare Software" ist sogar ein sehr großes Thema. Die entscheidenden Stichworte sind hier FreieSoftware und OpenSource. Siehe auch GnuSoftware. Oder geht es hier eher darum, wie man möglichst portabel programmiert?-- akf

Warum? Aus Geschwindigkeitsgründen - das fällt ganz klar unter "Premature Optimization". Aus Zugriffsgründen - das weiß der jeweilige Compiler sehr viel besser als ich. Kompatibilitätsprobleme mit solchen Sachen bekommt man meistens dann, wenn man viel auf der Implementationsebene arbeitet, anstatt auf der abstrahierten Repräsentations-/Werteebene. Dasselbe bei der Endianness - da handelt man sich die meisten Probleme bei binären Streams ein, z.B. Netzwerkverkehr oder Dateiformate. Der Trick besteht darin, die Streams als das zu behandeln, was sie sind (Octet-Sequenzen), nicht als das was sie beinhalten (z.B. Integerwerte).

memcpy(&uint32, uint8arr, 4); Implementationsebene, erfordert systemspezifische Anpassungen und man landet bei signed-Werten schnell im Undefined Behaviour.

uint32 = (uint32_t)uint8arr[0] | (uint8arr[1] << 8) | (uint8arr[2] << 16) | (uint8arr[3] << 24); Repräsentations-/Werteebene, voll portabel ohne weitere Anpassungen.

Vielleicht findest du zum Thema Wiederverwendung so wenig, weil es dir hier mehr um das Thema Plattformunabhängigkeit geht?

HartmutSchorrig: OK, beides hängt aber zusammen. Folgende Kurz-Statements:

* OpenSource ist Wiederverwendung pur. Das ist OK und gut, wird aber von vielen Programmierern nicht so gesehen.

* In Java gibts auch kaum Probleme mit Wiederverwendung. Auch das Theme Byte-Anordnungen, alignment usw. gibt es da nicht (außer auf Hardwarezugriffsebene usw.). Alles, was ich oben geschrieben habe ist ausschließlich auf C (C++) bezogen. Ich werden diesen Artikel also demnächst umräumen, Überschrift etwa 'portable Programmierung in C'.

* Die Alignment-Problematik hat sehr wenig mit Geschwindigkeit zu tun, sondern sehr viel mehr damit, dass eine Datenstruktur (C struct) in einem beliebigen System ohne Änderung compiliert werden kann und die Daten gleichartig abbildet. Zu denken dabei ist beispielsweise an einen Datenabzug, aus einem embedded System, auf dem PC ausgewertet. Das embedded System ist vielleicht nur 16 bit breit, der PC ist zufällig auf 4-Byte-Alignment geschaltet, (weil das an anderen Stellen so vorgesehen ist), und die Suche nach falschen Daten oder die 'Anpassung' des Headerfiles beginnt. Mir ist schonmal ein Compiler über den Weg gelaufen, der hat zwar Bytestrukturen dicht gepackt (struct{ char a,b; short c;} belegte also 4 Bytes), aber Werte, die von Haus aus 4 Byte lang waren (long), auf durch 4 teilbare Adressen gepackt. Und das notwendigerweise, weil die CPU das nicht anders verarbeiten konnte (kein Intel-Prozessor mit byteorientierten Zugriffen). Das ganze war aber nicht so ganz gut dokumentiert und auch nicht so gut bekannt. ..... Daher von mir der Hinweis, Strukturen so zu schreiben dass alles gepackt ist aber jedes Element auf einer durch soviel teilbaren Adresse beginnt wie es seiner Länge entspricht. Das ist zwar etwas mehr Denkarbeit beim Programmieren, aber ist immer die optimale Variante bzgl Rechenzeit und funktioniert immer kompatibel. --2006-05-27-HartmutSchorrig.