Delphi 2011 heißt jetzt Delphi XE

[xZise]

Zitat von mkinzler:

Zitat:

Außerdem was ist großes neues nach Delphi 7 in die Sprache integriert worden?

.Klassenmethoden
-Klassenoperataoren ( für Records)
-Enumaeratoren
-Generics
-Unicode
-Sealed Class
-Class Helper
-Reflection
...

Es gab keine Enumeratoren in Delphi 7? Da wäre ich mir nicht sicher. Und okay Generics gab es tatsächlich nicht. Reflection ist doch eine Funktion der IDE, Class Helper und Sealed Class habe ich nicht genutzt. Und Unicode: Wäre schade drum, aber FPC hat kein Unicode?

Naja gut es gibt wohl doch Sachen neu seit Delphi 7, aber ich weiß leider nicht ob der FPC nicht vielleicht das schon implementiert hat, aber anderes noch nicht.

Aber es ist nun mal so, dass der FPC wohl wesentlich schneller sich entwickelt als Delphi.

MfG
Fabian

PS: Operatoren gibt es inzwischen auch für Klassen.
PPS: Himitsu hat im ersten Link den Unterschied aufgezeigt. Der zweite Link liegt außen vor, da es mir wie gesagt nicht um die IDE geht, sondern um die Sprachtechniken.

[Bernhard Geyer]

Zitat von xZise:

Reflection ist doch eine Funktion der IDE,

Nee. Reflection ist die aufgebohrte RTTI damit man halbwegs das machen kann was per Reflection in .NET/Java auch möglich ist.

Zitat von xZise:

Und Unicode: Wäre schade drum, aber FPC hat kein Unicode?

AFAIK wird das dort auf Basis von UTF8 gemacht. Handelt man sich aber andere Problem ein als wenn man es wie "üblich" auf UTF16-Basis wie Java/.NET/Windows macht.

[mkinzler]

FPC kennt auch Gnerics, aber lehnt sich hier eher an der Implementierung unter C++ an, währrend Delphi eher nach Java/C# schielt.

[xZise]

Zitat von Bernhard Geyer:

Zitat von xZise:

Reflection ist doch eine Funktion der IDE,

Nee. Reflection ist die aufgebohrte RTTI damit man halbwegs das machen kann was per Reflection in .NET/Java auch möglich ist.[…]

Ach mist dachte Reflection wäre Refactoring

MfG
Fabian

[himitsu]

Zitat von xZise:

Es gab keine Enumeratoren in Delphi 7?

Kommt drauf an, was du meinst.

type myEnum = (a, b, c); gab's schon, aber die Enumerator-Klassen, welche z.B. für das For-In genutzt werden, wurden zusammen mit dem For-In eingeführt.

Zitat:

AFAIK wird das dort auf Basis von UTF8 gemacht. Handelt man sich aber andere Problem ein als wenn man es wie "üblich" auf UTF16-Basis wie Java/.NET/Windows macht.

Liegt das nicht daran, daß FPC, bzw. viele APIs der VCL und Co. noch "Ansi" waren, aber Lazarus nun Unicode unterstützen wollte?
UTF-8 kann man ja quasi auf Ansi mappen.

[Bernhard Geyer]

Zitat von himitsu:

Zitat:

AFAIK wird das dort auf Basis von UTF8 gemacht. Handelt man sich aber andere Problem ein als wenn man es wie "üblich" auf UTF16-Basis wie Java/.NET/Windows macht.

Liegt das nicht daran, daß FPC, bzw. viele APIs der VCL und Co. noch "Ansi" waren, aber Lazarus nun Unicode unterstützen wollte?
UTF-8 kann man ja quasi auf Ansi mappen.

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. Bei dem Widestring-Ansatz verliert man "nur" die Fremdsprachentext wenn automatisch nach Ansi gewandelt wird bzw. man bekommt eine Warnmeldung über evtl. Datenverlust. Bei Aufruf einen AnsiString-Funktion mit einem UTF8-String welcher in einer AnsiString-Variable steckt bekommt man AFAIK gar keine Meldung - es funktioniert u.U. halt nicht.

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