Zitat:
Ein Integer ist je nach Plattform 16,32 oder in Zukunft 64-Bittig
Falsch (liegt aber nicht an dir)
Microsoft hat sich gedacht, sie lassen den Integer in ihrem 64 Bit-Compiler einfach 32 Bit klein und führen stattdessen einen neuen 64-Bit-Integer-Typen ein.
Und Emba wird das vermutlich genauso bescheuert nachmachen.
Aha? Solche Halbwahrheiten kann ich nicht stehenlassen:
Zitat von
http://de.wikipedia.org/wiki/Integer_(Datentyp)#H.C3.A4ufige_Speicherformen:
Ein Integer besteht in der Regel aus 8, 16, 32, 64 oder 128 Bits (also 1, 2, 4, 8 oder 16 Bytes) – entsprechend der Wortbreite der jeweiligen CPU. Historisch wurden auch andere Werte (12, 48, … Bit) verwendet. In Programmiersprachen sind die Bezeichnungen dieser Zahlen teilweise genormt: In Java werden sie als byte (8), short (16), int (32) und long (64 Bit) bezeichnet. In C gibt es dieselben Bezeichnungen, jedoch sind die Größen architekturabhängig, mit C99 wurden architekturunabhängige Typen definiert (stdint.h). Dafür unterstützt C auch die vorzeichenlose (unsigned) Variante, die von den meisten Mikrocontrollern und Mikroprozessoren in Hardware unterstützt werden.
Also mach dich mal locker und mach nicht MS für alles Schlechte in der Welt verantwortlich ...
Selbst ein Byte ist nicht auf allen Architekturen 8 Bit breit, nur um mit diesem Vorurteil auch aufzuräumen. Aus diesem Grund wird in Protokollen oder anderen Spezifikationen gern der Begriff "Oktett" (engl. octet) verwendet.
Aber wie willst Du eine Neuentwicklung ohne 64Bit Compiler durchführen?
Ein erster Schritt hätte sein können, daß die Spezifikation für den Compiler schon bei Ankündigung veröffentlicht worden wäre und daß entsprechende Warnungen hätten aktiviert werden können (wäre auch für die
Unicode-Umstellung m.M.n. notwendig gewesen).
Ich zum Beispiel habe mir eine
Unit gemacht und schreibe mir meine eigenen Datentypen da rein, die ich dann anschließend in den Projekten nur einbinde, ob das sinnvoll ist weis ich nicht, aber es schont die Nerven. Solange ich keine sicheren Informationen habe wie die einzelnen Datentype später aussehen sollen.
Das ist ohnehin immer besser, obwohl sicherlich in der behüteten Monokultur "Delphi" der Bedarf für diese Abstraktion selten sichtbar wurde. Wenn man aber obige Aussagen zu den Datentypen nimmt, sollte klar sein, wieso viele Leute Headerdateien pflegen in denen
für spezielle Compiler und Platformen die jeweilige ("korrekte") Typisierung mit einem bestimmten Namen belegt wird und innerhalb des eigenen Codes benutzt wird. Gut, mit C++ ist das nun überflüssig, aber leider gibt es auch noch eine Menge C-Code der durch den Compiler gejagt wird ...
Das Problem ist, dass man sich entschlossen hat Integer bei 32Bit einzufrieren und den festen Typ NativeInt dynamisch zu machen, weil wohl VS/
WinAPI das auch macht.
Die lahmste Ausrede überhaupt. Wenn man betrachtet, daß PChar (oder aufgrund der Unabhängigkeit von Groß-/Kleinschreibung: PCHAR) für lange Jahre in Delphi als einziger Typ war welcher Pointerarithmetik zuließ (ja, bei PBYTE ging das nicht immer ... ich sag nur Delphi 4) und sich dann betrachtet, daß die "tolle" Unicodeumstellung PChar einfach mal locker flockig umdefiniert hat und damit jeglichen älteren Code der sich auf Pointerarithmetik verließ mal schön versaut (siehe
hier: "Use of PChar() casts to enable pointer arithmetic on non-char based pointer types") ... dann ist die Ausrede "MS hat das so gemacht" an Dreistigkeit kaum zu überbieten.
Und ja, dumm gelaufen daß PCHAR in Turbo Pascal schon existierte und dann zufällig auch als
Win32-Typ existierte. Aber die Hauptplattform war und ist Windows.