Delphi 2011 heißt jetzt Delphi XE

[Bernhard Geyer]

Zitat von HeikoAdams:

Zitat von Bernhard Geyer:

Die Compilierbarkeit bis D2007 habe ich schon geprüft. Jedoch eine vollständigen Test auf allen OS-Versionen und evtl. "versteckte" Probleme haben wir keine Umstellung gemacht.

Das ist riskant. Nur weil sich ein Projekt ohne Fehler compilieren lässt, heißt das nicht, das nicht z.B. irgendwelche Komponenten von Drittherstellern zur Laufzeit Fehler verursachen. ...

Deshalb haben wir ja auch keinen IDE-Wechsel durchgeführt.

[himitsu]

Zitat von Bernhard Geyer:

Dumm nur wenn viele diese Aufgerufenen Funktionen gar nix davon wussten das 1 Zeichen != 1 Character/1Byte ist und dann munter fehlhaft Funktionierten sobald Sonderzeichen im String vorhanden sind.

Wenn vorher alles korrekt implementiert wurden wäre, dann hätte eine Umstellung keinerlei Probleme bereitet.
Und es ist kein Delphiproblem, denn auch in anderen Programmiersprachen wäre es so gekommen, wenn man da sowas umgestellen würde.

Wenn man dynamische Typen (Integer, Char, String) als statisch nutzt, dann soll man sich nicht beschweren, wenn sie sich mal ändern und der Code dann nicht mehr ordentlich läuft.

[mleyen]

Hast du eine offizielle Quelle, die besagt das Integer dynamisch bleibt?

[mkinzler]

Code, der keine undokumentierten Details verwendet und nicht von nichtzugesicherten Dingen ausgeht, funktioniert eigentlich. Nur tricky Code stolperte natürlich über die Änderung der Länge eines Zeichens

[himitsu]

@mleyen: eigentlich sollte ja Integer in einem 64-bittigem Delphi auch 64 Bit sein, aber bei diesem Sonnderfall wird gemunkelt daß Delphi es C nachmachen will und Integer 32 Bit bleibt, was ich für vollkommenen Quasch halte
(über Cardinal hab ich noch nichts gehört, aber ich hoffe das bleibt so oder so kompatibel zum Integer)

Aber Integer war als dynamischer Typ ausgelegt und demnach hätte man diesen auch als dynamischen Typen (kompilierrt für Win 1.x = 16 Bit / Win 9x/NT32 = 32 Bit / Win64 = 64 Bit) benutzen müssen.
Aber beim Char/String/PChar trifft es ja zu ... da war vorher schon klar (bevor man überhaupt an ein Unicode-Delphi dachte), daß sich dieses irgendwann mal ändern könnte ... hätte man also ordentlich programmiert, gäb's keine Probleme.

[Bernhard Geyer]

Zitat von himitsu:

@mleyen: eigentlich sollte ja Integer in einem 64-bittigem Delphi auch 64 Bit sein, aber bei diesem Sonnderfall wird gemunkelt daß Delphi es C nachmachen will und Integer 32 Bit bleibt, was ich für vollkommenen Quasch halte

Dieser "Quatsch" ist auch unter .NET/Java so. Du handelst dir nur dann Probleme mit SizeOf(Int) != Sizeof(Pointer) ein wenn du Integer für die Speicherung von Pointer mißbrauchst.

[mleyen]

Zitat von himitsu:

... da war vorher schon klar (bevor man überhaupt an ein Unicode-Delphi dachte), daß sich dieses irgendwann mal ändern könnte ... hätte man also ordentlich programmiert, gäb's keine Probleme.

So klar, dass solche Dokumente überflüssig sind. Programmierer sind auch nur Menschen und können nicht jede Eventualität berücksichtigen. Wie man sieht hat man jetzt Probleme ala das man nicht weiß welche Server Daten als String auswerten und welche den Speicher direkt nutzen.
Du hast in XP-Zeiten auch immer nach %APPDATA% geschrieben, nicht?
Der Aufwand existiert[Punkt]

[HeikoAdams]

Zitat von mleyen:

Du hast in XP-Zeiten auch immer nach %APPDATA% geschrieben, nicht?

natürlich haben wir zu XP-Zeiten die Daten nach %APPDATA% und nicht ins Anwendungsverzeichnis geschrieben

[Stevie]

Wenn plötzlich alle nicht mehr migrieren wegen neuer Features, die evtl Probleme mit der Abwärtskompatibilität machen, frag ich mich, warum alle so rumheulen, wenn Emba dann keine neuen Features einbaut.

[Bernhard Geyer]

Zitat von Stevie:

Wenn plötzlich alle nicht mehr migrieren wegen neuer Features, die evtl Probleme mit der Abwärtskompatibilität machen, frag ich mich, warum alle so rumheulen, wenn Emba dann keine neuen Features einbaut.

Es werden halt immer die Features eingebaut die man selbst nicht braucht