Delphi 2011 heißt jetzt Delphi XE

[mkinzler]

Zitat:

Die Firebird Unterstützung war ja auch bei Delphi 2010 so angepriesen worden und dann nicht in der Professional Version enthalten.

Doch, aber wie alle dbExpress-Treiber bei der Pro sehr beschränkt nutzbar

[Chemiker]

Hallo mkinzler,

ja OK. Ich hatte mir so was wie die Interbase – Komponenten für Firebird und Interbase vorgestellt. Bei gekauften Komponenten wie z.B. FIBPlus geht das doch auch.

Bis bald Chemiker

[mkinzler]

Man hat aber immer von dbExpress geredet. Zur Not geht es ja auch mit IBX.

[Hansa]

Zitat:

Zitat von HeikoAdams (Beitrag 1041193)

Mein Favorit wäre das berühmte Gorbi-Zitat "Den letzten beißen die Hunde" :lol:

Äh, schön dass dieses Zitat bekannt ist. :P Aber nix Gorbatschow. Der hat gesagt (DDR-Honecker war damit gemeint) : "Wer zu spät kommt, den bestraft das Leben". Vom Sinn her dürfte das allerdings wohl gemeint sein. :mrgreen:

OT : Wieso ist der Thread hier überhaupt noch auf ? 20 Seiten ? :shock: Von der DP Tradition her gesehen, müsste der schon längst eskaliert und geschlossen sein. Also so richtig eskaliert, komplett mit allem was dazugehört. :mrgreen:

[himitsu]

@OT-Hansa: Weil sich hier mal alle (fast) einig sind?

[Hansa]

Glaube eher, das liegt an den Schulferien. Nächste Woche gehts wohl richtig zur Sache. Beleidigte User weg usw. :mrgreen:

[xZise]

Zitat:

Zitat von mkinzler (Beitrag 1041331)

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.

[PhilmacFLy]

Ja wenns um unsere (DP) existenz grundlage geht da werden auf einmal ganz freundlich und gehen hand in hand :D

[Bernhard Geyer]

Zitat:

Zitat von xZise (Beitrag 1041357)

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:

Zitat von xZise (Beitrag 1041357)

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.

[himitsu]

Zitat:

Zitat von xZise (Beitrag 1041357)

Es gab keine Enumeratoren in Delphi 7?

Kommt drauf an, was du meinst.

Delphi-Quellcode:

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.

[Stevie]

Zitat:

Zitat von xZise (Beitrag 1041357)

PS: Operatoren gibt es inzwischen auch für Klassen.

Nö, die Trottel haben den Fehler in der Auflistung der neuen Features seit Delphi7 nur noch nicht gefixt.
Da steht:

Zitat:

Delphi allows certain functions, or operators, to be overloaded within record declarations

aber darunter steht eine Klassen Deklaration... und das geht nicht.

Anstatt ihrer Sch**** SVN Integration, UML Designern (vor allen sie zeigen nur Reverse Engeneering, oder? Wen interessiert das? Das und viel mehr konnte Modelmaker schon vor Jahren) und sonstigem Fluff sollten sie mal die QC abarbeiten und derbe Fehler in der RTL/VCL fixen und die Generics endlich komplett benutzbar machen. Ich stoß dauernd an Stellen wo ich mir nur denke, toll in C# würd das gehen... Beispiel?
Hab versucht, den CommonServiceLocator auf Delphi zu portieren:

Delphi-Quellcode:

type
  IServiceLocator = interface
    function GetInstance<TService>(): TService;
  end;

Möööp! Interfaces unterstützen keine parametrisierten Methoden... :wall:

[xZise]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1041376)

Zitat:

Zitat von xZise (Beitrag 1041357)

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 :oops: dachte Reflection wäre Refactoring :D

MfG
Fabian

[himitsu]

Das kann auch nicht/nie mit Objekten (Klassen) funktionieren, höchstens bei Interfaces wären es noch möglich.

Delphi-Quellcode:

var A, B, C: TObject;

A := B + C;

Denn wer soll jetzt dafür sorgen, daß eine Klasse in A auch ordnungsgemäß freigegeben wird, wenn da nun eine neue Klaee als Rechenergebnis reinwöllte?
Speicherlecks ohne Ende.
A einfach freizugeben geht auch nicht, da Delphi ja nich wissen kann, ob dieses Objekt noch wo anders in Verwendung ist.

[Stevie]

Zitat:

Zitat von himitsu (Beitrag 1041405)

Das kann auch nicht/nie mit Objekten (Klassen) funktionieren, höchstens bei Interfaces wären es noch möglich.

Delphi-Quellcode:

var A, B, C: TObject;

A := B + C;

Denn wer soll jetzt dafür sorgen, daß eine Klasse in A auch ordnungsgemäß freigegeben wird, wenn da nun eine neue Klaee als Rechenergebnis reinwöllte?
Speicherlecks ohne Ende.
A einfach freizugeben geht auch nicht, da Delphi ja nich wissen kann, ob dieses Objekt noch wo anders in Verwendung ist.

Imo kein großes Problem, ist auch nich viel anders als die Kombination von Copy constructor und Assign/AssignTo

[himitsu]

Nein, da Delphi keine automatische Referenzzählung bei den Objekten besitzt.

Delphi-Quellcode:

C := TZahl.Create(789);
D := C;

A := TZahl.Create(123);
B := TZahl.Create(456);
C := A + B;  // function TZahl.Add(x, y: TZahl);
             // begin  Result := TZahl.Create(x.num + y.num);  end;
WriteLn(C.num);

Wenn man jetzt einfach so die alte Zahl in C freigeben würde, dann wäre der Objektzeiger in D nun fehlerhaft, da man ihm das Objekt unterm Arsch geklaut hat.
Macht man mit dem alten Objekt in C nichts und dieses Objekt wäre sonst nirgendwo referenziert, dann entstünde ein Speicherleck.


Mit Interfaces ist es also möglich, da man dort weiß wieviele Referenzen es auf die enthaltenen Objekte/Interfaces gibt und kann es somit freigeben.
Bei Records ist garnichts nötig, da dort die Speicherbereiche direkt vorliegen (quasi ein RefCount von 1).
Darum hab ich bei meinen MatheLibs auch in dem Record ein Interface gekapselt, da ich so die Vorteile eines Interfaces (Referenzzählung), mit den Operatoren der Records kombinieren konnte.

[Stevie]

Dir ist schon klar, dass das nicht das Problem von operatoren auf Klassen ist sondern das des Programmierers, der hier lustig Objekte gegenseitig zuweist? Wenn per Definition ein Operator ein neues Objekt erzeugt ist allen klar, dass sie bei einer Zuweisung von a := b + c vorher a sichern oder freigeben müssten, wenn da was drin steht. Was hat das bitte mit Operatoren zu tun, das wäre bei jeder normalen Methode die ein Objekt zurück gibt genauso.

[himitsu]

Weil Delphi/Emba bei einem Versuch die Operatoren, Aufgrund der Natur der Objekte, bei den Objeten zu implementieren, nur scheitern kann, da man hier eben nichts "sicher" abfragen kann.
(ungültige Objektzeiger und unbekannte Mehrfachreferenzen)

Was denkst du denn, warum es nicht für Objekte implementiert wurden ist, sondern eben nur für Records?
(die Interfaces hatten die wohl einfach nur vergessen)

[mkinzler]

Dieses Problem dürften andere Sprache, welche mit Referenzen haben dann auch haben. das Problem besteht ja auch, wei schon gwschrieben auch so.

Delphi-Quellcode:

var
    a,b,c: TObject;
begin
    ...
    a := b;

Auch hier existiert das ursprüngliche Objekt, welches a referenziert weiter.

Oder

Delphi-Quellcode:

var
   a: TOject;
begin
   ...
   a := Tobject.Create;
   ...
   a := Tobject.Create;

...

[Stevie]

Zitat:

Zitat von himitsu (Beitrag 1041416)

Was denkst du denn, warum es nicht für Objekte implementiert wurden ist, sondern eben nur für Records?

Weil sie dort genauso wie bei vielen anderen Sachen nicht zu Ende gedacht haben? :stupid:
Nee, ernsthaft, wahrscheinlich würde es theoretisch gehen, nur würds wohl mehr Verwirrung stiften und Fehler hervorrufen es nützen würde.
überschreibt mal fix den Zuweisungsoperator für einige Klassen, muhaha :twisted:

P.S.: Da fällt mir gerade ein... würden die operator Überladungen dann vererbt? Japp, das könnt wohl richtig derb nach hinten losgehen, wenn man da was falsch macht :D

[HeikoAdams]

Klingt so, als ob es wirklich das schlauste wäre, den Compiler von Delphi durch den FPC zu ersetzen

[Win32.API]

Bloß keinen anderer Compiler verwenden, der nicht 100% mit den Sprachfeatures von D2010 kompatibel ist. Die Umstellung von Ansi auf Unicode, OHNE dabei abwärts kompatible zu bleiben ({$DEFINE UNICODE}), hat mir gereicht. :pale:

[mleyen]

Das war ja schon oft ein Wunschtraum. Delphi IDE + FPC-Compiler + Support und kommerzielle weiterentwicklung.
Jedoch würde sich da wahrscheinlich sowohl Embarcadero als auch die FPC-Entwickler querstellen.
Ich kann mir kaum vorstellen, dass dann noch so viele umsonst am Compiler für Emba weiterentwickeln werden.

Ich bin auch Hansa´s Meinung und man sollte mit neuen Features vorsichtig sein.
Denn nicht alle brauch(t)en unbedingt Unicode, 64bit, Multiplatform, etc.
Für viele Firmen war/ist die Umstellung auf neuere Versionen einfach ein Aufwand (den Code zu portieren) für etwas was sie nicht unbedingt benötigen.

[Bernhard Geyer]

Zitat:

Zitat von himitsu (Beitrag 1041381)

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.

[Bernhard Geyer]

Zitat:

Zitat von mleyen (Beitrag 1041433)

Ich bin auch Hansa´s Meinung und man sollte mit neuen Features vorsichtig sein.

Stimmt. Full Ack.

Zitat:

Zitat von mleyen (Beitrag 1041433)

Denn nicht alle brauch(t)en unbedingt Unicode, 64bit, Multiplatform, etc.
Für viele Firmen war/ist die Umstellung auf neuere Versionen einfach ein Aufwand (den Code zu portieren) für etwas was sie nicht unbedingt benötigen.

Wenn man sowas nicht braucht, wieso sollte man dann auf neue Version umstellen? Bisher haben wir (Trotz Notwendigkeit von Unicode/Theming/Vista/Win7-Support) noch gut mit D6 leben können. Eine Umstellung haben wir uns bisher gespart (beim letzten mal haben wir aufgrund von Release-Termin eine Umstellung noch verschoben). D2007 ist die erste Version seit D7 die wieder für uns brauchbar war/ist. D2009/2010 würde erst kommen wenn auch die (schon offiziell abgekündigter Win98-Support) nicht mehr nötig ist.

[mleyen]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1041437)

Wenn man sowas nicht braucht, wieso sollte man dann auf neue Version umstellen?

Einerseits wegen einiger neuen Features und andererseits damit der Umstellungsaufwand später nicht noch immensere Dimensionen animmt. (Wer weiß schon wie 64 bit etc. eingebaut wird?)
Ob noch mehr Faktoren eine Rolle spielten weiß ich nicht.

[cookie22]

Zitat:

Zitat von mleyen (Beitrag 1041433)

Ich bin auch Hansa´s Meinung und man sollte mit neuen Features vorsichtig sein.
Denn nicht alle brauch(t)en unbedingt Unicode, 64bit, Multiplatform, etc.
Für viele Firmen war/ist die Umstellung auf neuere Versionen einfach ein Aufwand (den Code zu portieren) für etwas was sie nicht unbedingt benötigen.

nicht alle. heisst nicht, dass es nicht ne ganze menge leute gibt, die es brauchen. gerade unicode ist wichtig, wer ohne unicode support neue projekte startet ist selbst schuld.

der delphi compiler ist jahre hinter fpc hinterher. wenn die nicht schnell was machen ist der vorsprung nie wieder einzuholen.

Zitat:

D2009/2010 würde erst kommen wenn auch die (schon offiziell abgekündigter Win98-Support) nicht mehr nötig ist.

habt ihr echt noch kunden, die noch win98 verwenden?

[HeikoAdams]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1041437)

Wenn man sowas nicht braucht, wieso sollte man dann auf neue Version umstellen?

Vielleicht, weil man einige Features benötigt, andere aber nicht. Frei nach dem Motto: Generics ja, Unicode nein.

Zitat:

Zitat von cookie22 (Beitrag 1041442)

der delphi compiler ist jahre hinter fpc hinterher. wenn die nicht schnell was machen ist der vorsprung nie wieder einzuholen.

Das kommt davon, wenn man sich zu lange auf einem vermeintlichen Vorsprung ausruht: irgendwann zieht die Konkurrenz an einem vorbei! Borland hat seinerzeit ja sehr eindrucksvoll vorgemacht, wie man den Vorsprung von Delphi verspielt.

[Bernhard Geyer]

Zitat:

Zitat von mleyen (Beitrag 1041441)

Einerseits wegen einiger neuen Features und andererseits damit der Umstellungsaufwand später nicht noch immensere Dimensionen animmt.

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.

[HeikoAdams]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1041444)

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. Bei einem ehemaligen Arbeitgeber von mir war es Standard, die Software nach jedem Update der Entwicklungsumgebung komplett zu testen, damit wir keine unbrauchbaren Versionen an Kunden ausliefern. Das fänden die sicher nicht so witzig, wenn ihre Software nach einem Update nicht mehr ordentlich funktioniert ;)

[Bernhard Geyer]

Zitat:

Zitat von HeikoAdams (Beitrag 1041445)

Zitat:

Zitat von Bernhard Geyer (Beitrag 1041444)

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:

Zitat von Bernhard Geyer (Beitrag 1041435)

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

[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 :wall:
(ü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:

Zitat von himitsu (Beitrag 1041463)

@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 :wall:

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:

Zitat von himitsu (Beitrag 1041463)

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

Zitat von mleyen (Beitrag 1041468)

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 :angel: :lol:

[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. 8-) :P

[Bernhard Geyer]

Zitat:

Zitat von Stevie (Beitrag 1041492)

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. 8-) :P

Es werden halt immer die Features eingebaut die man selbst nicht braucht 8-)