Delphi 64

[Assarbad]

Zitat von himitsu:

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.

Zitat von Chemiker:

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

Zitat von Chemiker:

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

Zitat von mkinzler:

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.

[himitsu]

Zitat von Assarbad:

Aha?

Zitat von mkinzler:

weil wohl VS/WinAPI das auch macht.

VS und die WinAPI kommen doch von MS,
also haben die es doch (im Windowssystem) so eingeführt?

Nja, da Emba es nur nachmacht und sie garantiert nicht mit diesem Integer-Chaos, durch ihr (noch) nichtvorhandenes 64-RAD, angefangen haben, sind sie zur Abwechlung mal an nichts Schuld, außer am Mitläufersyndrom.

Zitat von Wikipedia:

jedoch sind die Größen architekturabhängig

Hmm, also sind nun Intel dran Schuld?
Ich wußte nicht, daß die CPU-Hersteller die "Bezeichnungen" der Typen vorgeben.

Oder heißt das einfach nur "32 Bit-CPU/Architektur = 32 Bit-Integer" und "64 Bit-CPU/Architektur = 64 Bit-Integer" ?
Demnach müßte der Integer ja auf 64 Bit anwachsen.

[Assarbad]

Zitat von himitsu:

VS und die WinAPI kommen doch von MS,
also haben die es doch (im Windowssystem) so eingeführt?

Architektur -> PowerPC, MIPS, x86, x64, IA-64 ...

Zitat von himitsu:

sind sie zur Abwechlung mal an nichts Schuld, außer am Mitläufersyndrom.

Sehe ich anders, siehe meine Antwort auf Markus' apologetisches Argument

Zitat von himitsu:

Hmm, also sind nun Intel dran Schuld?
Ich wußte nicht, daß die CPU-Hersteller die "Bezeichnungen" der Typen vorgeben.

Intel ist auch ein Compiler-Hersteller, wenn's recht ist

Aber: Nein, es heißt alles nur, daß du die vorige Aussage absolut verneint hast, obwohl diese absolute Verneinung weder angebracht noch korrekt war. Ich habe nicht mehr getan als dies zu berichtigen ... deswegen von meiner Seite auch der Begriff "Halbwahrheiten", weil du um das Argument einzufahren eben die andere "Hälfte" unterschlagen hast ...

Zitat von Bernhard Geyer:

Der fehlende 64-Bit Compiler verursacht aber auch schon Supportaufwand da für einen Oracle-Zugriff jeder Admin erstmal den 64 NET-Client auf Win64-Systemen installiert und es damit erstmal nicht geht.

Ließe sich das nicht mit Marshaling über ein COM-Objekt beheben, wenn's denn notwendig ist?

Zitat von Bernhard Geyer:

Das Borland den "normalen" Weg geht und int bei 32-Bit lässt ist m.E. vollkommen ok. Damit muss man sich bei Kommunikation mit .NET/Java/WinAPI nicht jedesmal fragen ob nun integer ein 32-Bit oder 64-Bit darstellt.

Ganz richtig. Heimatplattform von Delphi ist und bleibt Win32 (wobei das 32 im Namen nicht als Hinweis auf die Bittigkeit verstanden werden sollte).

[Bernhard Geyer]

Zitat von Assarbad:

Zitat von Bernhard Geyer:

Der fehlende 64-Bit Compiler verursacht aber auch schon Supportaufwand da für einen Oracle-Zugriff jeder Admin erstmal den 64 NET-Client auf Win64-Systemen installiert und es damit erstmal nicht geht.

Ließe sich das nicht mit Marshaling über ein COM-Objekt beheben, wenn's denn notwendig ist?

IIIIIH COM. Für Oracle ist das glücklicherweise kein Problem wenn man weis was eigentlich abläuft. Schnell mal den 32-Bit Instant-Client per X-Copy "installiert", Umgebungsvariable darauf umgebogen (oder batch-datei erstellt weche die Umgebungsvariable nur für den eigenen Prozess ändert) und gut ist. Hätte Oracle sich für den 64-Bit eine anderen Namen für die Umgebungsvariable ausgesucht könnten 32/64-Bit problemlos ohne Tricks parallel installiert sein.