spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Zitat von »Spiele Programmierer«

Zitat

Portabilität ist überhaupt erst der Grund wieso int gerade keine feste Größe hat;

Es war der Grund. Heutzutage gibt es praktisch keine Architektur mehr, die damit Schwierigkeiten hätte.
Sehr wohl gibt es aber unterschiedliche Ansichten auf der selben Architektur, woran die Größe der Typen bemessen werden kann.

Zitat von »dot«

erst recht ist es kein "Phänomen der Vergangenheit".

Dann nenn mir mal wenigstens eine aktuelle Architektur für die das nicht zutrifft.

Motorola 68000
Freescale HCS12
Infineon C166
Texas Instruments MSP430
...

Dir ist klar, dass die Welt nicht nur aus PCs besteht und C und C++ als Systemsprachen insbesondere auch für Dinge wie Embedded Systeme gedacht sind, wo du teilweise 8-Bit CPUs vorfinden wirst...!?

Zitat von »Spiele Programmierer«

Zitat von »dot«

int hat sowohl in C als auch in C++ eine ganz klar definierte Semantik und auch einen klar definierten Wertebereich.

Nö hat er nicht. Der C99-Standard und damit auch der C++11 Standard schreibt wortwörtlich nur folgende Dinge über den Wertebereich:
"minimum value for an object of type int INT_MIN -32767 // −(2 15 − 1)"
"maximum value for an object of type int INT_MAX +32767 // 2 15 − 1"
"A ‘‘plain’’ int object has the natural size suggested by the architecture of the execution environment"
"For any two integer types with the same signedness and different integer conversion rank, the range of values of the type with smaller integer conversion rank is a subrange of the values of the other type"
Ein int soll also mindestens so groß sein wie ein short oder ein signed char und der Größe entsprechen, die die Architektur vorschlägt.

Und was genau ist daran unklar?

Zitat von »Spiele Programmierer«

Diese Aussage ist extrem vage und lässt viel Interpretationsspielraum für Entscheidungen nach Bedarf, Lust und Laune (Siehe Datenmodell). Insbesondere sind 32 Bit inzwischen eigentlich gar nicht mehr die native Größe der x64 Architektur.
Man könnte jetzt natürlich behaupten, dass die Typen trotzdem eine Semantik besitzen. Diese beschränkt sich aber auf sehr vage Formulierungen und deckt sich mit kaum einen Bedarf der Praxis. Ich wüsste beim besten Willen nicht in welchen Zusammenhang jemand einen Typ (int) brauchen könnte, der auf 32 Bit MSDOS 16 Bit groß ist und auf 32 Bit NT Windows 32 Bit. Oder ein Typ (long) der auf 64 Bit Windows 32 Bit groß ist und auf 64 Bit Linux 64 Bit. Das ist doch Schwachsinn.

Du kannst den Typ ganz ausgezeichnet verwenden wann immer du Ganzzahlen brauchst, die nicht größer als 32767 und nicht kleiner als -32767 sein müssen. Das tolle ist, dass du einfach int hinschreibst und es kompiliert sowohl für deinen 10 MHz 16-Bit RISC Mikrocontroller als auch für deinen superskalaren 4 GHz x64 Hexacore als auch für deine GPU mit 32-Bit Registern und 64-Bit Addressraum zu optimalem Code...

Aus irgendeinem Grund scheinst du implizit davon auszugehen, dass die Größe eines Datentyps in Byte irgendwie generell eine Rolle spielt, was aber einfach nicht der Fall ist. Es spielt manchmal (selten) eine Rolle. Meistens ist es aber vollkommen irrelevant. Was meistens relevant ist, ist nicht, wie die Repräsentation eines Datentyps im Speicher genau aussieht, sondern wie die Menge der darstellbaren Werte und die möglichen Operationen auf diesen Werten aussehen (aka die Semantik des Typs). Und genau darum ist int in C und C++ so definiert, wie es definiert ist. Einer der Grundgedanken von C und C++ ist, eine maximal nützliche Programmierumgebung unter minimalen Abhängigkeiten von konkreten architektonischen Merkmalen zu schaffen. Bei genauerem hinschauen wird beispielsweise auffallen, dass C und C++ nicht einmal Zweierkomplementdarstellung für signed-Typen fordern. Diese Philosophie sorgt dafür, dass nicht nur der Code portabel ist, sondern insbesondere auch die Effizienz des Code.

Was genau hättest du davon, wenn die Sprache dir garantieren würde, dass ein int immer und überall genau N-Bit in Zweierkomplementdarstellung ist? Die Antwort ist: In der Regel absolut rein garnichts. Wenn du irgendwas rechnest, interessiert dich nur, ob die Wertemenge des verwendeten Typs alles, was in deinen Berechnungen so vorgehen kann, abdeckt. Das einzige, das die Fixierung auf N-Bit int erreicht, ist, dass der Compiler öfter gezwungen wird, ineffizienten Code zu generieren. Nehmen wir das Beispiel von oben. Für N = 16 kann ein Compiler optimalen Code für den Mikrocontroller erzeugen, auf der x64 CPU wird's aber ineffizient, weil zwischen Rechenoperationen immer wieder die unteren 16 Bit in den Registern maskiert oder partial Register Accesses verwendet werden müssen, und auf der GPU dasselbe. Mit N = 32 kann ein Compiler zwar für x64 und GPU effizienten Code erzeugen, nicht aber für den Mikrocontroller. Mit N = 64 wird es auf allen drei Architekturen unnötig ineffizient (x64 CPUs haben 64-Bit Register, das heißt aber noch lange nicht, dass es keinen Unterschied macht, ob man dort mit 32 Bit oder mit 64 Bit rechnet. 64-Bit Werte brauchen mehr Speicher und damit insbesondere auch mehr Speicherbandbreite, 64-Bit Instructions haben ein weniger kompaktes Encoding, ... genau aus diesen Gründen rät Intel, auch auf x64 immer mit 32-Bit Arithmetik zu arbeiten, wenn diese ausreichend ist...). Für den Code war dabei an keiner Stelle jemals die exakte Anzahl an Bits in einem int relevant oder gar wie diese Bits von der Hardware als Zahlenwert interpretiert werden. Das einzige, was für den Code jemals relevant war, ist die Semantik des verwendeten Datentyps. Wie diese Semantik auf verschiedener Hardware umgesetzt wird, ist Sache des Compilers. Und je mehr Annahmen über die Natur der konkreten Implementierung eine Sprache macht, desto weniger Freiheit bleibt dem Compiler, zu optimieren und eine portable, effiziente Implementierung zu gewährleisten. Die Semantik eines Integertyps kann wunderbar ohne die Festlegung auf eine konkrete Anzahl an Bits in Zweierkomplementdarstellung definiert werden. Und da das "you don't pay for what you don't use" Prinzip der goldene Grundsatz von C und C++ ist, fangen diese Sprachen beim Minimum an nützlicher Semantik aus einer minimalen Menge an Axiomen an. Semantisch stärkere Typen existieren selbstverständlich für die Fälle, wo sie tatsächlich gebraucht werden, aber wieso sollte man rein prinzipiell immer den mit der Garantie einer bestimmten Eigenschaft verbundenen Overhead herumschleppen, wenn selbige Eigenschaft in 90% der Fälle irrelevant ist?

Zitat von »Spiele Programmierer«

Zitat von »dot«

Inwiefern der "long-Typ" "in der Praxis problematisch" sein soll entzieht sich gerade meiner Vorstellungskraft, aber ich kann dir mit Sicherheit sagen, dass, wenn die Präsenz von int dich in deinem Code zu "unnötigen Casts" zwingt, weil "nirgendwo was zusammenpasst", mit deinem Code was nicht ganz in Ordnung sein kann...

Du willst mir also sagen, dass du noch nie mit einer Bibliothek zu tun hattest, die falsche Annahmen zu long gemacht hat und ihn als 64 Bit angenommen hat?

Könnte mich gerade nicht an einen solchen Fall erinnern. Rein prinzipiell: Wenn eine Bibliothek ungeeignete Datentypen verwendet, dann ist das ein Problem mit der Bibliothek und nicht ein Problem mit dem Datentyp...

Zitat von »Spiele Programmierer«

Das kann ich mir irgendwie nicht vorstellen. Sogar der C-Standard selbst ist betroffen, indem zum Beispiel die C-Dateifunktionen wie ftell auf Windows nicht mit großen Dateien auskommen. Auf Windows muss man dann die Extension _ftelli64 verwenden. Soetwas finde ich ganz große Klasse. Diese Probleme haben ihren Ursprung in den falschen Annahmen über die Größe von Typen. Hätte man nicht einen eingebauten Typen verwendet sondern einen Typedef für den entsprechenden Bedarf, hätte es nie ein Problem gegeben. Die eingebauten Typen decken sich nunmal sehr selten mit dem Bedarf der Realität.

Nun, das konkrete Beispiel zeigt, dass auch beim Design der C Standardbibliothek Fehler gemacht werden. Wäre nicht das erste Mal gewesen (wer erinnert sich noch an gets()?). Wobei man im konkreten Fall von ftell() sich eigentlich die Frage stellen muss, ob es hier überhaupt eine richtige Antwort geben kann oder ob das Problem nicht vielmehr in der Existenz der Funktion an sich zu suchen ist, denn eigentlich ist das Konzept eines Stream rein prinzipiell mit der Idee einer absoluten Position nicht wirklich vereinbar. Mit fgetpos() und fsetpos() gibt es zumindest ein minimal sinnvolleres Interface...

Inwiefern die eingebauten Typen sich "nicht mit dem Bedarf der Realität decken" sollen, kann ich angesichts der Tatsache, dass ebendiese "Realität" fast ausschließlich auf den Grundfesten von C und C++ errichtet ist und diese eingebauten Typen die Primitive sind, aus denen dort alles gebaut wird, nicht ganz nachvollziehen...

Zitat von »Spiele Programmierer«

Zitat von »dot«

wenn die Präsenz von int dich in deinem Code zu "unnötigen Casts" zwingt, weil "nirgendwo was zusammenpasst", mit deinem Code was nicht ganz in Ordnung sein kann...

Bei der Verwendung im Zusammenhang mit Speicher als Indices oder Größenangaben, gibt es andauerend Casts in size_t oder ptrdiff_t.

size_t und ptrdiff_t gibt es doch gerade erst genau für diese Dinge; wenn du irgendwo von einem size_t oder ptrdiff_t zurück nach int casten musst, dann liegt sehr wahrscheinlich wohl ein konzeptionelles Problem vor.

Zitat von »Spiele Programmierer«

Außerdem entstehen sie an allen Stellen, an dem Kontakt zur Außenwelt aufgenommen wird. Serialisierung oder WinAPI seien mal als Beispiele genannt.

Die Interaktion mit fremden ABIs ist eine der wenigen (!) Situationen, wo man tatsächlich oft Datentypen fixer Größe braucht, die es sowohl in C als auch C++ selbstverständlich auch gibt...

Zitat von »Spiele Programmierer«

Ich wüsste nicht wie solche Casts vermieden werden sollen. Die Ursache liegt einfach darin, dass ein Typ verwendet wird, der nicht dem tatsächlichen Bedarf entspricht.

Wenn ein Programmierer einen Datentyp verwendet, der "nicht dem tatsächlichen Bedarf entspricht", dann ist also der verwendete Datentyp schuld, weil er sich nicht an diesen "tatsächlichen Bedarf" angepasst hat?

Sie müssen ja nicht als int32_t deklariert werden. Der Typ passt allerdings zur Anwendung und zum benötigten Wertebereich und ist somit am besten geeignet.

Wie alt jemand sein kann, ist ja nicht davon abhänig wie groß ein Typ gerade bei einem bestimmten Compiler ist. Alter ist eine abstrakte Eigenschaft dessen Wertebereich meiner Meinung nach überall gleich sein sollte. Es ist ja nicht so, dass Leute die einen Linux Rechner(sizeof(long) == 8) benutzen älter werden, als Leute die einen Windows Rechner benutzen (sizeof(long) == 4). Deshalb int32_t als Standard. Das hängt natürlich vom Kontext ab, so wie auch die anderen Beispiele, die du genannt hast. In einem gewöhnlichen Anwendungsfall würde ich die als size_t einstufen, weil Anzahlen und Array Indices im Zusammenhang mit Arrays stehen und size_t somit insgesamt am besten passt. Es ist auch praktisch sinnvoll, denn ein 64 Bit Rechner kann theoretisch tatsächlich mehr Sprites in den Arbeitsspeicher laden als ein 32 Bit Rechner.

EDIT @Dot:

Zitat von »Dot«

Dir ist klar, dass die Welt nicht nur aus PCs besteht und C und C++ als Systemsprachen insbesondere auch für Dinge wie Embedded Systeme gedacht sind, wo du teilweise 8-Bit CPUs vorfinden wirst...!?

Das ist mir durchaus klar. Ich habe mich schließlich bereits selbst mit der Programmierung von solchen Mikrocontrollern auseinander gesetzt. (besonders PIC)
Alle Beispiele die du genannt hast, basieren allerdings mehr oder weniger als Bytes als kleinste Informationseinheit und sind mit der Definition von Typen fester Größen wie in stdint.h absolut kompatibel.

Ich sehe nicht, wie das Beispiele dafür sind, dass die Typen aus C in der heutigen Welt portabler sind im Vergleich zu festen Typen. Tatsächlich behaupte ich, dass ein Großteil moderner Software auf solchen Architekturen nicht problemlos laufen würden, weil häufig versehentlich irgendwo implizit an vielen Stellen davon augegangen wird, dass ein int 32 Bit groß ist bzw. Werte bis 2^31-1 speichern kann, bevor wieder jemand unzufrieden wird, weil ich nicht explizit vom Wertebereich spreche.

Zitat von »Dot«

Und was genau ist daran unklar?

Es ist unklar wie der Typ den nun tatsächlich beschaffen ist. Siehe long im Vergleich Linux - Windows.

Zitat von »Dot«

Du kannst den Typ ganz ausgezeichnet verwenden wann immer du Ganzzahlen brauchst, die nicht größer als 32767 und nicht kleiner als -32767 sein müssen. Das tolle ist, dass du einfach int hinschreibst und es kompiliert sowohl für deinen 10 MHz 16-Bit RISC Mikrocontroller als auch für deinen superskalaren 4 GHz x64 Hexacore als auch für deine GPU mit 32-Bit Registern und 64-Bit Addressraum zu optimalem Code...

Naja, eben nicht (mehr). Das war ursprünglich die Idee, allerdings sich die Typen durch ihre vage Definition inzwischen von der Architektur gelöst. Siehe long im Vergleich Linux - Windows.

Der C Standard hat das auch erkannt und dann zu diesem Zweck neue Typen wie int_fast32_t eingeführt.

Zitat von »Dot«

aber wieso sollte man rein prinzipiell immer den mit der Garantie einer bestimmten Eigenschaft verbundenen Overhead herumschleppen, wenn selbige Eigenschaft für 90% des Code irrelevant ist?

Weil int32_t tatsächlich überall so effizient wie ein long dargestellt werden kann und ich mich in der Regel nicht überall mit der Frage auseinander setze, wie lange nun ein int16_t(das was ein int garantiert ist) noch ausreichen würde.

Zitat von »Dot«

Könnte mich gerade nicht an einen solchen Fall erinnern. Rein prinzipiell: Wenn eine Bibliothek ungeeignete Datentypen verwendet, dann ist das ein Problem mit der Bibliothek und nicht ein Problem mit dem Datentyp...

Man hätte die Typen halt so benennen sollen, dass das klar ist. Insofort gebe ich der Sprache eine Teilschuld. int verleitet viele Programmierer zur Annahme, das es ein 32 Bit Typ ist. long verleitet Linux-Programmierer zur Annahme, dass sie es überall mit einem 64 Bit Typen zu tun haben.

Zitat von »Dot«

size_t und ptrdiff_t gibt es doch gerade erst genau für diese Dinge, wenn du irgendwo von einem size_t oder ptrdiff_t zurück nach int casten musst, dann liegt sehr wahrscheinlich wohl ein konzeptionelles Problem vor.

Das sehe ich genauso. Deshalb sollte man Array-Indices auch als size_t speichern und eben nicht als int. (Was viele tun)

Zitat von »Dot«

Wenn ein Programmierer einen Datentyp verwendet, der "nicht dem tatsächlichen Bedarf entspricht", dann ist also der verwendete Datentyp schuld, weil er sich nicht an den Bedarf angepasst hat?

Der Datentyp ist nicht "schuld". Allerdings heißt dieser Datentyp nunmal oft int oder long wenn ein anderer Datentyp passen würde.

Nochmal: Ich spreche mich nicht partout gegen variable Typen aus. Die eingebauten Typen werden allerdings häufig falsch verwendet und meiner Erfahrung passen Typen fester Größe besonders gut. Ein int_fast32_t könnte vielleicht auch passen. Allerdings unterstützen selbst die kleinen Controller in eingebeteten System Bytes und 32 Bit Integer. Außerdem wäre der heutzutage 64 Bit groß und würde damit außerhalb von Registern auf 64 Bit System sogar auch noch Speicher verschwenden.

Zitat von »Spiele Programmierer«

Die Modelle kommen ja auch aus Dateien und wandern in OpenGL.
Das sind allerdings floats. In meinem Terrain-Renderer habe ich das Highfield als Festkomma. Das wird mit 32 Bit in einer Datei gespeichert und auch mit 32 Bit Ints an OpenGL geschickt.

Dort sehe ich zum Beispiel keinen Grund, warum ich im Zwischenschritt alles in einem Dateitypen umwandeln sollte, der in beide Richtungen inkompatibel ist.

Ich sehe auch keinen Grund wieso du das tun solltest, allerdings fasst dein C bzw. C++ Code diese Daten dann ja auch gar nicht an, sondern kopiert sie nur; ein konkreter Typ muss für diese Daten dort also überhaupt gar nicht erst deklariert werden...

Zitat von »Spiele Programmierer«

Wie alt jemand sein kann, ist ja nicht davon abhänig wie groß ein Typ gerade bei einem bestimmten Compiler ist. Alter ist eine abstrakte Eigenschaft dessen Wertebereich meiner Meinung nach überall gleich sein sollte. Es ist ja nicht so, dass Leute die einen Linux Rechner(sizeof(long) == benutzen älter werden, als Leute die einen Windows Rechner benutzen (sizeof(long) == 4). Deshalb int32_t als Standard.

Wenn es egal ist, wie groß der Datentyp eigentlich ist, wie kommst Du da zu dem logischen Schluss, dass man ihn fest auf 32 Bit definieren müsste? Ist das nicht ziemlich unlogisch? Aus meiner Sicht ist das jedenfalls ein Widerspruch.
"Es ist egal, wie groß er letztlich sein müsste, also setze ich ihn mal fest auf 32 Bit"
Wät?
Lass den Compiler sein Ding machen, er weiß es besser als Du. Speziell, da Dir eh egal sein kann, wie groß der Typ tatsächlich ist.

@BlueCobold
Naja, man könnte ihn schon als long oder int_fast32_t speichern. Das stimmt.
Allerdings wird damit Speicherplatz verschwendet und es besteht damit wieder die Gefahr, das jemand falsche Annahmen macht. Und so eine falsche Annahme reduziert die Portabilität leider auch in der Praxis.

@dot
Die Daten sind editierbar. Sie werden nicht nur durchkopiert.

Sind wir jetzt schon bei dem "Es wird Speicherplatz verschwendet"-Spruch als ernsthaftes Argument angekommen? Wer macht denn außerdem falsche Annahmen? Schlechte C++ Programmierer? Ein Alter ist ein int. Da gibt's gar nichts drüber zu diskutieren. int_fast32_t, ich glaub' es wird langsam sogar etwas albern.

Das kann ein ernsthaftes Argument sein. Zum Beispiel bei meinen Höhendaten, von denen ich vorher sprach war das ein wichtiger Teil für die Entscheidung für den Datentyp und es geht durchaus insgesamt um hunderte von MB, die gespart werden. Sonst hätte man ja auch double nehmen können.

Und ein historisches Alter oder ein menschliches Alter in Tagen wäre aber eben eigentlich zum Beispiel schon zu groß für int (> 32767). Das ist ein für heutige Verhältnisse schon ein kleiner Wertebereich den man leicht erreicht. Und ja, es sind teilweise schlechte Programmier. Aber teilweise auch einfach Spieleprogrammierer und BlueCobolde, die mal einen schlechten Tag haben und mal versehentlich einen zu großen Wert zuweisen und das nicht bemerken. Oder Leute die zu Tippfaul für den richtigen Typ sind und dann einfach int nehmen. Schon ist es nicht mehr Standardkonform und tatsächlich problematisch bei Portierungen auf andere Plattformen bei denen int aufeinmal kleiner ist.

Zitat von »Spiele Programmierer«

Zum Beispiel bei meinen Höhendaten, von denen ich vorher sprach war das ein wichtiger Teil für die Entscheidung für den Datentyp und es geht durchaus insgesamt um hunderte von MB, die gespart werden. Sonst hätte man ja auch double nehmen können.

Was? Vergleichst Du jetzt Äpfel mit Birnen? Mal ganz langsam. Eines ist ganze Zahl, das andere Fließkomma. Bitte, bitte, bitte sag mir nicht, dass nur Du deswegen einen 32-Bit-int genommen hast, weil Dir double zu groß, float unbekannt und Ganze Zahl oder Fließkomma pupsegal war.

Alter in Tagen? Jetzt wird's auch ernsthaft esoterisch und wirklich mal albern. Hast Du sonst noch ernsthafte Argumente für die Verwendung von int32_t?

Zitat von »Spiele Programmierer«

Aber teilweise auch einfach Spieleprogrammierer und BlueCobolde, die mal einen schlechten Tag haben und mal versehentlich einen zu großen Wert zuweisen und das nicht bemerken.

Letzteres nicht, nein.

Zitat von »Spiele Programmierer«

und dann einfach int nehmen. Schon ist es nicht mehr Standardkonform

Natürlich ist ein int Standard-konform. Sonst stünde er wohl kaum im C++ Standard.

Zitat von »BlueCobold«

Was? Vergleichst Du jetzt Äpfel mit Birnen?

Es ist ein sehr ähnlicher Fall.

Zitat von »BlueCobold«

Eines ist ganze Zahl, das andere Fließkomma. Bitte, bitte, bitte sag mir nicht, dass nur Du deswegen einen 32-Bit-int genommen hast, weil Dir double zu groß, float unbekannt und Ganze Zahl oder Fließkomma pupsegal war.

In dem Fall ging es darum die Höhe abzuspeichern. Mir war es eben nicht egal, deshalb habe ich mich für den 32 Bit Integer entschieden. Warum? Weil ich keine Fließkommaeigenschaften brauche. Wenn mir der Speicherplatz egal gewesen wäre, hätte ich aber double nehmen können. Fließkommazahlen schaden nämlich auch nicht (außer teilweise dem Speicher/Performance) und es lässt sich einfacher mit ihnen rechnen.

Zitat von »BlueCobold«

Alter in Tagen? Jetzt wird's auch ernsthaft esoterisch und wirklich mal albern. Hast Du sonst noch ernsthafte Argumente für die Verwendung von int32_t?

Das ist überhaupt nicht esoterisch. Du glaubst doch nicht, dass du in deiner Software keine Ganzzahlen hast, die größer als 32737 sind. Das würde ich dir nämlich nicht glauben. Esoterisch ist ein Alter in Tagen auch nicht im geringsten. Es ist bloß eine Frage des Einsatzortes und welche Zeitspannen und Unterteilungen dort notwendig sind. Dot.Net speichert Zeitspannen als Vielfaches von 100 Nanosekunden.

Zitat von »BlueCobold«

Letzteres nicht, nein.

Das glaube ich dir nicht.
Das ist genauso wie die Unmengen an Undefined Behavior und sonstigen subtilen Fehler die sich in jeder Software finden lassen. Menschen sind fehlbar. Da kommt es vor, dass Werte zugewiesen werden, die auf anderen Plattformen dann gar nicht existieren. Und wenn es keinen Fehler gibt, fällt es nicht auf.

Zitat von »BlueCobold«

Natürlich ist ein int Standard-konform. Sonst stünde er wohl kaum im C++ Standard.

Hast du gelesen, was ich geschrieben habe? Wenn einem int ein Wert größer als 32767 zugewiesen wird, ist es nicht mehr standardkonform. Dieser Wertebereich ist Implementation-defined und nicht Teil des C Standards.

Ich habe jetzt dann aber keine Lust mehr. Die Diskussion wird mir zu unsachlich.
Wenn die Verwendung von int nicht hinterfragt werden darf und das einfach so sein muss, wird es zwecklos.
Ich wünsche euch bloß, dass ihr keinen Linux Only Code schreibt und ihr niemals euren Code auf einer Compiler/Architektur kompilieren wollt, bei dem int auf einmal nur 16 Bit groß ist.

EDIT:
Ups, sorry. Ich habe die Zitate korrigiert.
Sagen tu zu der Aussage allerdings nichts mehr. Für und Wider wurden ja schon erläutert.

Wenn Dir die Diskussion zu unsachlich ist, dann zitiert doch bitte wenigstens richtig. Die Aussagen da stammen nämlich von mir und nicht von dot.

Mein Code ist übrigens nicht Linux-only. Er läuft auf Windows (32+64Bit), Linux (32+64Bit), Android (in 5 verschiedenen Architectures), OS X und iOS (5 verschiedene Architectures) - insgesamt also in 15 verschiedenen Varianten über 5 Betriebssysteme hinweg. Er wurde mit 3 verschiedenen Compilern gebaut. Ich habe nicht einen einzigen int32_t und wüsste auch nicht wofür.