Integer und Cardinal bei 32 Bit eingefroren? NativeInt?

[alzaimar]

Und wer castet, ist selbst Schuld. Typecasting bedeutet immer eine implizite Kenntnis über den Compiler.
Plattformübergreifend und allgemeingültig zu programmieren bedeutet, diese manchmal Klimmzüge entweder zu vermeiden, oder wenigstens wohldefiniert auszulagern.

Wer das nicht gemacht hat, ist der Depp. Nicht der, der mit dem Standard mitgeht. Anstatt auf die Windowsprogrammierer zu schimpfen, die vor 15+x Jahren nicht in weiser Voraussicht daran gedacht haben, das jemals jemand mehr als 2Gig benötigt (die Spezis unter uns hätten natürlich dran gedacht, klar!), sollte man sich lieber selbstkritisch fragen, ob man nicht auch andere Codestellen datentypenunabhängig nachprogrammieren sollte.

Gerade die Pointerarithmetik ist doch ein Grund gewesen, die Programmiersprachen zu modernisieren. Man soll gefälligst -wo's geht- die Finger davon lassen. Und wenn ich eine Routine nochmals optimieren will bzw. muss, dann markiere ich sie entsprechend und nehme mir diesen Frickelcode zur Not vor.

Wer natürlich Pointer und PChar-Klimmzüge als wertvolle Beiträge zu stabilem und portablem Code ansieht... Tja, der hat eben Pech gehabt und muss Nachsitzen. :mrgreen:

im Ernst Jungs. :mrgreen: Sind wir nicht alle selbst Schuld an diesem Dilemma?

[himitsu]

Vorallem seit Delphi 2009 sollte es doch wohl klar sein, daß man bei seinen Definition aufpassen sollte.

Eigentlich hatte ich immer da wo möglich die "freien" Typen, wie Integer, Cardinal, String und PChar verwendet, wo sich alles automatisch an die CPU und den Compiler anpassen sollte.

Und da wo ich "feste" Typen benötige oder wo es nötig ist, da hab ich eben LongInt, LongWord, AnsiString, PAnsiChar und Co. verwendet.

Immerhinn sollte es doch so "laut bekannter Definition" der Typen ja auch zukunftssicher sein und gerade beim Integer würden so nun Bemühungen der letzen Jahre potentiel vernichtet, obwohl ich doch eigentlich zukunftsicherer sein wollte. :wall:

Mal ganz im Ernst: Mir doch egal was andere sagen, aber mir wäre es lieber und es währe auch gerechter, wenn die bestraft werden, welche nie hören wollten.
Also diejenigen welche Integer verwendet haben, obwohl sie zwingend Int32/LongInt benötigt hätten.


Nehmen wir mal mein himXML. Dieses läuft ohne große Änderungen unter D2006 bis D2010 und dabei werden nur Dinge Versionsabhängig abgestellt/zugeschaltet, welche in den Versionen nicht exisiteren oder anders laufen. Selbst in D7 läuft der Code weitesgehend.
Und theoretisch hätte der Code nichtmal bei der Umstellung auf 64 Bit Probleme gemacht, wenn der Integer/Cardinal mitwachsen würde. Nichtmal UCS4 wäre ein Problem geworden, wenn es dann irgendwann mal kommt.

[implementation]

Bin ganz alzaimar's Meinung. Nicht umsonst heißen solche Zeigeroperationen "unsicherer Code" und werden in Java und C# nur durch spezielle Compiler-/Precompiler-Optionen ermöglicht.

Zitat:

Zitat von Panthrax

Aber wie machen es denn C, Java und C#, wenn es darum geht aus einem Quelltext eine 32- und eine 64-Bit-Anwendung zu erstellen?

Java und C# erlauben solchen "unsicheren Code" standardmäßig gar nicht erst, siehe oben.
Und in C hat man sich da einfach schon dran gewöhnt.

Mich wundert vor allem, dass euch das ganze erst jetzt auffällt. Das war doch schon ziemlich lange absehbar - etwa seit es die ersten 64bit-C/C++/Java/C#/VB-Compiler gab. Schaut ihr denn nie über den Delphi-Tellerrand? Im FPC-x64 ist das auch längst so (wie lange gibt's den jetzt schon?).

[himitsu]

Zitat:

Zitat von implementation

Bin ganz alzaimar's Meinung. Nicht umsonst heißen solche Zeigeroperationen "unsicherer Code" und werden in Java und C# nur durch spezielle Compiler-/Precompiler-Optionen ermöglicht.

Das liegt aber auch an diesem komischen Speichermanager, welcher selber den Speicher verwalten will, anstatt es dem Programmier zu überlassen ... wenn ich nun einen Pointer auf etwas zeigen lasse und der Speichermanager davon nichts weiß, dann gibt er den Speicher frei und mein Pointer wäre "sinnlos", bzw. "unsicher".

Wer seinen Speicher ordentlich verwaltet, der baucht keinen kranken Garbage-Collector.
Ich will selbstbestimmen, was mein Programm macht und soein "Ding"ist nur was für Faule.


Der Rand meiner Schüssel ist zu hoch, drum seh ich sowas nicht.
- mit C hab ich nicht viel am Hut
- und Lazarus mag mich nicht, also beschäftige ich mich damit nicht weiter

[Namenloser]

Warum macht CodeGear/Embarcadero nicht einfach einen neuen Compilerschalter? Genau so hätte man es auch bei der Umstellung auf Unicode machen können und könnte dann sogar den gleichen Source Code für Ansi und Unicode kompilieren.

Wenn man sich mal C-Header ansieht findet man sowas zuhauf:

Delphi-Quellcode:

{$IFDEF WIN64}
type
  Integer = Int64;
{$ELSE}
type 
  Integer = Int32;
{$ENDIF}
{$IFDEF UNICODE}
type
  Char = WideChar;
{$ELSE}
type 
  Char = AnsiChar;
{$ENDIF}

Warum macht man es nicht auch unter Delphi so?

[mkinzler]

Beu der Unicode Einführung hat man bewusst darauf verzichtet, da der Umstieg sonst nie funktioniert hätte. Nur so konnte man 3rd-Party Hersteller (Jomponenten, Erweiterungen usw.) dazu zwingen und hat damit in Kauf genommen, dass manche die Entwicklung eingestellt haben.

[SirThornberry]

Weil das eben nicht geht. Viele Api-Funktionen wurden mit "Integer" übersetzt. Und nur weil man plötzlich einen anderen Compiler verwendet heißt es nicht das automatisch alle Api-Funktionen die vorher einen 32bit-Integer erwartet haben jetzt einen 64bit-Integer erwarten.

[himitsu]

Zitat:

Zitat von SirThornberry

Weil das eben nicht geht. Viele Api-Funktionen wurden mit "Integer" übersetzt. Und nur weil man plötzlich einen anderen Compiler verwendet heißt es nicht das automatisch alle Api-Funktionen die vorher einen 32bit-Integer erwartet haben jetzt einen 64bit-Integer erwarten.

Ja und, dann wird das einfach in den entdprechenden Headern der APIs mit angepaßt.
Wenn dort in Delphi ein LongInt statt einem Integer steht, dann paßt alles wieder. :roll:

[Medium]

Zitat:

Zitat von himitsu

dann gibt er den Speicher frei und mein Pointer wäre "sinnlos", bzw. "unsicher".

Nein, es heisst unsicher, weil man als Programmierer damit sehr leicht Dinge tun kann, die man so garnicht wollte. Mit dem GC hat das rein überhaupt nichts zu tun. Zudem gibt es in C# die Möglichkeit einen unsafe{..} Block zu deklarieren, in dem u.a. auch der Typ "IntPtr" verwendet werden kann, sowie Zeigerarithmetik wie von C gewohnt. Nachdem man unsafe Code in den Compileroptionen dann noch eingeschaltet hat, kann man fröhlich drauf los pointern - und man ist sich dann sicher, dass es nach quasi 2-maliger Bestätigung auch WIRKLICH so gewollt ist. Allerdings ist das als zeimlich üblber Stil anzusehen, ausser es geht um die Anbindung älterer APIs (wofür diese Option insbesondere geschaffen wurde).

Zitat:

Wer seinen Speicher ordentlich verwaltet, der baucht keinen kranken Garbage-Collector.
Ich will selbstbestimmen, was mein Programm macht und soein "Ding"ist nur was für Faule.

Dann verwende bitte auch keine case-Konstrukte, und diverse Schleifen. Sowas macht man doch bitte sehr schön von Hand mittels Labels und bedingter Sprünge!

Zitat:

Der Rand meiner Schüssel ist zu hoch, drum seh ich sowas nicht.

So viel ist hier denke ich mehr als klar geworden :(

[Namenloser]

Was wird jetzt eigentlich aus der Technik z.B. Objektreferenzen in der Tag-Eigenschaft von visuellen Komponenten zu speichern? :gruebel: