Delphi 2011 heißt jetzt Delphi XE

[xZise]

Zitat von HeikoAdams:

Ich sehe das auch ein wenig problematisch, wenn Emba den FPC nutzen würde:

• Delphi würde letztendlich dazu degradiert werden, "nur" eine Distribution des FPC zu sein
• Der FPC ist im Moment "erst" mit Delphi 7 kompatibel[...]

[...]

Um ehrlich zu sein, mag ich die IDE von Delphi 2009 so wie sie ist eigentlich. Ich hätte kein Problem, wenn die den FPC nutzen würde. Und ich meine so viel hat da Embarcardero nicht mehr zu verlieren.

Außerdem was ist großes neues nach Delphi 7 in die Sprache integriert worden? Hmmm die "erweiterte for schleife" (aka for-each / for-in Schleife) und ich glaube Methoden in Records. Und glaub ich auch Operator-Methoden. Aber ich glaube FPC entwickelt sich ja auch weiter, zumindest schneller als Delphi. Teilweise ist FPC auch schon besser als Delphi.

MfG
Fabian

PS: @HeikoAdams: Du bist nicht der erste. Damals war die Signatur auch noch nicht so qualitativ hochwertig wie jetzt. Und ich glaube da war noch irgendwo ein Thread.

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

[himitsu]

http://edn.embarcadero.com/article/34324
http://edn.embarcadero.com/article/34323

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