Delphi 2011 heißt jetzt Delphi XE

[ralfschwalbe]

Da gebe ich Dir recht. Aber als mündiger Delphientwickler wünscht man sich doch, selbst zu entscheiden was man braucht.:wink:

Für mich bedeutet es einfach nur viel, viel (für unser Projekt) sinnlose Arbeit!

[Bernhard Geyer]

Zitat:

Zitat von Hansa (Beitrag 1045115)

Abwärtskompatibel bleiben bis zum geht nicht mehr und dann plötzlich alles über Bord werfen und Compilerschalter einsparen oder wie ?

Und dann alles für beide Compilerschalter testen? Alle Packages für beide Schalter verfügbar halten? Dafür sorgen das du mit UNICODE compilierte Packages nur in einer IDE laufen die auch mit UNICODE compiliert wurde, ....

Zitat:

Zitat von Hansa (Beitrag 1045115)

Heutzutage ist das dann wohl für UNICODE zuviel verlangt ? Siehe DEC : egal welche Delphi-Version ursprünglich dafür benutzt wurde : Compilerschalter $UNDEF UNICODE und fertig. Oder eben alles umschreiben.

Wirklich alles Umschreiben? Also wenn DEC auch intern für die Codierung auf String aufgesetzt hat, hat er einfach den falschen Datentypen verwendet. Und ein paar public Methoden umzuschreiben wäre wohl auch kein Problem.

Zitat:

Zitat von ralfschwalbe (Beitrag 1045123)

Ich persönlich habe das Problem, dass wir Datenbankzugriffe mit einem Puffer fester Länge realisieren (PervasiveSQL mit Zugriffsmethode Btrieve). ... Das bedeutet, ich habe tausende Deklarationen wie diese:

Delphi-Quellcode:

dataType = record
  Teil1 : array[1..20] of char;
  Teil2 : array[1..24] of char;
end;

Wenn Du tausender solcher Deklaration hast ist doch was an eurer DB-Schnittstelle falsch bzw umständlich realisiert.

Zitat:

Zitat von ralfschwalbe (Beitrag 1045123)

Und jetzt bitte nicht den Spruch bringen, bleib doch bei Delphi 2007. Ich möchte auch gern an den neuen Features teilhaben, auch wenn ich kein Unicode brauch.

Wenn du neue Features haben musst, dann mußt du halt mal nach über 10 Jahren in einen solchen saurern Apfel beißen. Spätestens mit 64-Bit wäre er gekommen.

[xZise]

Zitat:

Zitat von Hansa (Beitrag 1044983)

[...]Was, wenn der jetzt Lebensversicherung abschliessen will ? Dann wäre es wohl schon gut, die Original-Schrift benutzen zu können. Wie die eingetippt werden muss, das müsste man allerdings dann mal sehen. :lol: [...]

Moin Hansa, nichts gegen dich, aber dieses Argument ist sowas von Müll. Ich stelle mir ehrlich vor, wieso es eine lokalisierte Version von Windows gibt (z.B. Chinesisch oder Russisch), wenn die Anwender eh englisch müssen, weil sie nur die QWERTY Tastatur haben?! Also ich kenne das Layout von anderen Schriftsätzen nicht, aber nur, weil jemand nicht ein auf den lateinischen Buchstaben basierten Zeichensatz nutzt, wird er ausgegrenzt? Wäre ja noch schöner.

Ich finde die Umstellung auf Unicode gut. Zum einen musste das irgendwann wegen x64 passieren und zum anderen, wenn man das weiter verschleppt, ist damit niemanden geholfen.

Außerdem hätte man von Anfang an Ansi genutzt wo Ansi Pflicht ist und halt die generischen (heißt das so?) Typen (string/char) wenn es "egal" ist. Zum Beispiel bei einer MessageBox, wird dadurch relativ viel vereinfacht.

Und ein Compilerschalter ist da immer relativ kompliziert und für den Programmierer unübersichtlich. Z.B. bei DEC, wenn ich die nutze und die würde Unicode deaktivieren, wird sie dann nur für die Units deaktiviert (wenn ich zum Beispiel Unicode in der Anwendung brauche)? Dann rufe ich "foo(string):string" auf und weiß nicht, ob es Ansi oder Unicode ist?!

Die Herren sollen sich nicht so "anstellen" und den Code portieren.

Übrigens sowas ähnliches wird auch wahrscheinlich bei x64 passieren. Das kannst du ja verschleppen Hansa, aber dann in 5 Jahren, wenn du es mal brauchst, dann geht dein Code dafür nicht, weil du ja immer beim guten alten x86 geblieben bist? Also umso früher das verfügbar ist, umso besser! So kann der Code migriert, oder x64 ignoriert werden, aber der Entwickler hat die Wahl.

MfG
Fabian

[himitsu]

Zitat:

Zitat von ralfschwalbe (Beitrag 1045123)

Das bedeutet, ich habe tausende Deklarationen wie diese: ...
Ich muss jetzt ALLE(!!!) Typen in AnsiChar und alle PChar in PAnsiChar tauschen, und das ist nur der Anfang! Unsere Projektgruppe hat ca. 800.000 Zeilen Code.

Zitat:

Zitat von mkinzler (Beitrag 1045124)

es gibt ja verscheidene Tools zum Ersetzen von Zeichenketten (auch über Dateien hinweg) ' Char' -> ' AnsiChar'

Tut mir Leid, daß dieses schonwieder gesagt wird,
aber hätte man vorher schon überall AnsiChar/PAnsiChar/AnsiString gesetzt, wo es auch unbedingt ANSI sein muß, dann gäbe es jetzt keine Probleme.

Nur weil ihr "Mist" gebaut habt, müßt ihr da jetzt nicht die Schuld auf's Unicode/Emba schieben.

Das Char, PChar, String, Integer, Cardinal, Real keine generischen Typen sind, diese nicht immer 1, bzw. 4 Byte groß sind und sich somit irgendwann mal ändern könnten war vorher schon klar.
Wenn man diese nie beachtet hat, dann ist man nun selber dran Schuld, wenn es jetzt Probleme gibt.

Soein Unicode-Compilerschalter war also diesbezüglich niemals nötig.
Der Einzige Grund für soeinen Schalter wäre nur gegeben, um die API umschalten zu können und somit über den selben Quellcode jeweils eine Ansi- und eine Unicode-Version des selben Programms erzeugen zu können,
um somit z.B. eine Version zu erhalten welche auch noch problemlos mit Win9x lauffähig wäre.

Also Compiler-Schalter für mehrere Ausgaben und nicht um den Compiler an fehlerhaften Code anzupassen.

[HeikoAdams]

Zitat:

Zitat von himitsu (Beitrag 1045138)

Nur weil ihr "Mist" gebaut habt, müßt ihr da jetzt nicht die Schuld auf's Unicode schieben.

[OffTopic]Zu versuchen, die Schuld immer erst auf andere zu schieben, ist IMHO ein ganz normales Verhalten :wink:[/OffTopic]

[Tonic1024]

Es ist hier viel diskutiert worden und es sind viele Dinge angesprochen worden. Eines, auch wenn ich es manchmal aus Beiträgen herausschimmern bemerkt habe, wurde aber in aller Deutlichkeit hier noch nicht gesagt.

Ich verdiene mit dem RAD Studio mein Geld. Ich bin nicht selbstständig sondern die Lizenz wird mir von meinem Arbeitgeber zur Verfügung gestellt. WELCHE Lizenz (welcher Hersteller und welches Produkt) allerdings, wird vom backoffice vorgeschlagen. Macht ja IMO auch Sinn sowas nicht allein nem Vertriebler zu überlassen. Und bislang war das der Kurs jahrelang eindeutig.

Mir fehlt ein x64 Compiler im Moment nicht oder X-Plattform oder Facebook oder "Killerfeature 4711". Was mir wirklich fehlt ist ein gutes Gefühl für die Zukunft oder das Gefühl auf das richtige Pferd gesetzt zu haben. Was soll ich denn nun meinem Chef im Januar zur Jahreszielbesprechung vorschlagen? Kann ich die 2000 Euro pro Platz rechtfertigen und wenn ja womit? Sollten wir lieber langsam das sinkende Emba-Schiff verlassen oder auf den durchstartenden Emba-Zug aufspringen? DAS wäre mal ein Killerfeature, dass gerne auch ordentlich Geld in Embas Kassen spühlen darf.

just my 2 cent...

Toni

[mkinzler]

Zitat:

Zitat von himitsu (Beitrag 1044938)

Zitat:

Zitat von mkinzler (Beitrag 1044933)

Verschoben, nicht abgesetzt

seit vielen Jahren immer wieder verschoben = so gut wie abgesetzt

Auf der momantan stattfindenden Delphi Live Konferenz wurde ein Preview des Preview-Compilers gezeigt.

http://twitter.com/andreanolanusse

[himitsu]

Eine Vorschau auf die Vorschau? :lol:

Na OK, dann kann es sich ja nun nur noch um Jahre handeln. :thumb:
(falls man es nicht doch noch aufgibt)

[mkinzler]

Immerhin ist es dass 1. Mal, dass jemnad ausserhalb von EM in sieht. Bisher waren es ja nur Absichtserklärungen.

[divBy0]

Ist denn eigentlich bekannt wann es eine erste Testversion von XE geben wird?

[HeikoAdams]

[QUOTE=mkinzler;1045203]

Zitat:

Zitat von himitsu (Beitrag 1044938)

Auf der momantan stattfindenden Delphi Live Konferenz wurde ein Preview des Preview-Compilers gezeigt.

Fotos/Videos von der Preview wären interessant. Hat ja nicht jeder die nötige Zeit/das nötige Kleingeld, um die Delphi Live Konferenz zu besuchen

[himitsu]

Zitat:

Zitat von divBy0 (Beitrag 1045211)

Ist denn eigentlich bekannt wann es eine erste Testversion von XE geben wird?

Theoretisch könnte XE wohl die nächsten 1-3 Monate auf den Markt kommen
und dann kann man es sich auch als Trial runterladen.

PS: Das Zitat war nicht von mir :angle2:

[p80286]

[QUOTE=himitsu;1045138Tut mir Leid, daß dieses schonwieder gesagt wird,
aber hätte man vorher schon überall AnsiChar/PAnsiChar/AnsiString gesetzt, wo es auch unbedingt ANSI sein muß, dann gäbe es jetzt keine Probleme.
[/QUOTE]

Auch wenn ich Dir inhaltlich voll Recht geben muß, sowohl die OH als auch hier im Forum wurde die Auffassung vertreten String=AnsiString und gut is.
Jedenfalls ist

Delphi-Quellcode:

if irgendwas=true

ein weitaus größerer Aufreger, als

Delphi-Quellcode:

textsatz:string;

oder auch ein

Delphi-Quellcode:

packed record

.
Glücklicher Weise nutzt ja niemand mehr Records, sonst gibt es demnächst (irgendwann) noch mehr Probleme.

Gruß
K-H

[mkinzler]

Das string ein virtueller Typ ist war aber bekannt

[himitsu]

Das mit dem True wird auch oft genug gesagt und bezüglich des Packed prädige ich auch schon seit Jahren rum.

[OldGrumpy]

Das mit dem packed record ist mir so noch gar nicht aufgefallen, wo liegt denn da das Problem?

[mkinzler]

Da hat sich die Ausrichtung geändert.

[Phoenix]

XE soll bald (TM) veröffentlicht werden. Da das aber ein recht komplexer Prozess ist der offenbar ziemlich viele Unterschriften von ziemlich vielen Leuten benötigt kann das auch noch ein paar Tage gehen. Aber an sich isses fertig und eigentlich ready to ship.

[himitsu]

Jupp, darum auch für Records, welche "extern" gespeichert oder irgendwohin übertragen werden, nur generische Typen verwenden und alles schön "packen".

Spart A) eventuell ein paar Byte und gibt B) keine Probleme, wenn am anderen Ende die Typen und/oder die Ausrichtung anders sind.

[MEissing]

Zitat:

Zitat von Phoenix (Beitrag 1045280)

XE soll bald (TM) veröffentlicht werden. Da das aber ein recht komplexer Prozess ist [...] kann das auch noch ein paar Tage gehen. Aber an sich isses fertig und eigentlich ready to ship.

Aha!?!

[mkinzler]

Sebastian scheint mehr als du zu wissen :zwinker:

[xZise]

Zitat:

Zitat von p80286 (Beitrag 1045273)

Zitat:

Zitat von himitsu (Beitrag 1045138)

Tut mir Leid, daß dieses schonwieder gesagt wird,
aber hätte man vorher schon überall AnsiChar/PAnsiChar/AnsiString gesetzt, wo es auch unbedingt ANSI sein muß, dann gäbe es jetzt keine Probleme.

Auch wenn ich Dir inhaltlich voll Recht geben muß, sowohl die OH als auch hier im Forum wurde die Auffassung vertreten String=AnsiString und gut is.
Jedenfalls ist

Delphi-Quellcode:

if irgendwas=true

ein weitaus größerer Aufreger, als

Delphi-Quellcode:

textsatz:string;

oder auch ein

Delphi-Quellcode:

packed record

.[...]

Naja string an sich ist ja nicht böse, aber wenn man davon ausgeht, dass ein string immer ein AnsiString bleiben wird, dann ist es ein Problem. D.h. wenn man zum Beispiel die Länge im Speicher wissen will, dann ist es ja auch wichtig, wie das kodiert wird. Aber für andere Aufgaben hingegen ist das völlig egal.

MfG
Fabian

PS: Irgendwie ist das quote-Tag anfällig für Verhunzungen.

[himitsu]

Delphi-Quellcode:

var s: String;

LängeDerDaten = Length(S) * SizeOf(Char);
// oder
LängeDerDaten = Length(S) * SizeOf(S[1]);

[DeddyH]

Bei einem Leerstring könnte das 2. Beispiel aber in die Hose gehen.

[himitsu]

Nein, wird es nicht :angel: (obwohl ich das früher auch mal dachte)

Der Delphi-Compiler ist inteligent genug, um zu wissen, daß die Größe dieses Chars sich niemals ändert und setzt dann wärend der Kompilierung die Größe als direkte Zahl ein und greift nicht erst zur Laufzeit auf den Char zu.

Du kannst also auch

Delphi-Quellcode:

SizeOf(S[987654321])

nehmen.
Die Klammer+Zahl ist nur dafür da, um zu sagen, daß man die Größe des Zeichens und nicht des StringPointers wissen will.

[Mithrandir]

Zitat:

Zitat von MEissing (Beitrag 1045286)

Aha!?!

Ich denke nicht, dass der Kommentar vom Feuervogel so bierernst gemeint war. ;)

[DeddyH]

Zitat:

Zitat von himitsu (Beitrag 1045308)

Nein, wird es nicht :angel: (obwohl ich das früher auch mal dachte)

Der Delphi-Compiler ist inteligent genug, um zu wissen, daß die Größe dieses Chars sich niemals ändert und setzt dann wärend der Kompilierung die Größe als direkte Zahl ein und greift nicht erst zur Laufzeit auf den Char zu.

Du kannst also auch

Delphi-Quellcode:

SizeOf(S[987654321])

nehmen.
Die Klammer+Zahl ist nur dafür da, um zu sagen, daß man die Größe des Zeichens und nicht des StringPointers wissen will.

Tatsache. Trotzdem finde ich das ein wenig unsauber, zumindest aber schwer verständlich.

[xZise]

Zitat:

Zitat von himitsu (Beitrag 1045303)

Delphi-Quellcode:

var s: String;

LängeDerDaten = Length(S) * SizeOf(Char);
// oder
LängeDerDaten = Length(S) * SizeOf(S[1]);

Dann hätte man ja doch sauber programmiert -.-

Du beziehst dich doch gerade auf sowas:

Delphi-Quellcode:

LängeDerDaten = Length(S); // 1 Zeichen = 1 Byte

MfG
Fabian

[himitsu]

Ich verwende auch lieber

Delphi-Quellcode:

Length(S) * SizeOf(Char)

, aber hier muß man sicherstellen, daß Char und String "zusammenpassen".

Wärend bei

Delphi-Quellcode:

Length(S) * SizeOf(S[1])

die Zusammengehörigkeit sichergestellt ist.

Und was passiert, wenn man mal den Typen von S ändert?

Ist das Gleiche wie bei den Record-Pointern

Delphi-Quellcode:

ZeroMemory(P, SizeOf(TMyRec))

sieht schöner aus, als

Delphi-Quellcode:

FillMemory(P, SizeOf(P^), 0);

.

[Chemiker]

Hallo,

Zitat:

Zitat von himitsu

Tut mir Leid, daß dieses schonwieder gesagt wird,
aber hätte man vorher schon überall AnsiChar/PAnsiChar/AnsiString gesetzt, wo es auch unbedingt ANSI sein muß, dann gäbe es jetzt keine Probleme.

ich habe mal eine Frage, wie viel Fremdkomponenten setzt Du ein?

Bis bald Chemiker

[himitsu]

wohl Zuwenige

Aber dann ist wiederum nicht Delphi/Unicode,
sondern der jeweilige Komponentenentwickler dran Schuld. :angel2:

[MEissing]

Zitat:

Zitat von mkinzler (Beitrag 1045288)

Sebastian scheint mehr als du zu wissen :zwinker:

Ich wüsste nicht, dass wir über ein Verfügbarkeitsdatum/zeitraum schon öffentlich gesprochen haben.

[mkinzler]

Sebastian ist ja gerade als Referent in den Staaten (Delphi Live). Vielleicht wurde dort etwas gesagt. Obwohl seine Aussage, wohl auch etwas auf diesen Blogeintrag Bezug nimmt

[Phoenix]

Sowohl Michael Swindell und Michael Rozlog haven die Delphi Live mehrfach als Launch-Event bezeichnet und es hieß auch anderen Konferenz-Besuchern gegenüber beim Meet the Teams, dass es schon fast da sein müsste (it almost should be there).

Es kann sich also nur noch um Jahre handeln ;)

Edit Nachtrag: der Delphi Live Discount Code der hier auf die ganzen Flyer gedruckt ist gilt auch nur noch bis zum 15. September. Das Datum wurde auch von David I. auf der opening keynote genannt. Also wird man wohl spätestens bis zu diesem Datum zumindest mal vorbestellen können.

[himitsu]

http://blogs.embarcadero.com/chrispa...10/08/27/38971

Zitat:

1) Over 4200 fixes in RAD XE by the team compared to over 3000 in RAD 2010.

Ein Teil davon ist bestimmt sein vielen Jahren bekannt
und die bleiben dann wohl alle in 2010 und Co. ungefixt.

Zitat:

RAD Studio 2010:
OPT=-B : 2.75 seconds
OPT=-M : 2.54 seconds (1st time, delete *.dcu before compile)
OPT=-M : 2.15 seconds (2nd time, there is *.dcu compiled by previous run)

RAD Studio XE
OPT=-B : 1.37 seconds
OPT=-M : 1.36 seconds (1st time, delete *.dcu before compile)
OPT=-M : 1.40 seconds (2nd time, there is *.dcu compiled by previous run)

Der Durschnitt wievieler Messungen ist das denn?
Doch nicht etwas nur ein Durchgang und womöglich waren beim XE dann schon alle Dateien durch's 2010 im WindowsCache.

[Stevie]

Von den Zahlen her sieht das schonmal sehr gut aus. Noch mehr Bugs gefixt als in Delphi 2010, Dokumentation verbessert (ich hoffe sie setzen nicht mehr auf den Drecks Document Explorer). Ich bin gespannt, welche Generics Bugs behoben wurden, weil die mich wie schon erwähnt noch von vielem abgehalten haben.

[himitsu]

http://andy.jgknet.de/blog/?p=870

Schöne neue Features, welche alles nur verbessern
und die man so auch nicht schon durch externe Programme hatte :roll:

[jbg]

Zitat:

Zitat von himitsu (Beitrag 1046480)

http://andy.jgknet.de/blog/?p=870

Schöne neue Features, welche alles nur verbessern

Ich bin halt anspruchsvoll was die Startgeschwindigkeit der IDE betrifft. Und wenn ich sehe, dass BC hier alle Dateinamen des Source-Ordners einließt und dann auch noch die ineffektivste Methode der StringList einsetzt (TStrings.Values[]), dann ist bei mir halt Schluss mit lustig.

[mkinzler]

Das machen die doch nur, dass du was zu tun hast :stupid:

[Daniel]

:gruebel:
Merkwürdig, bei mir hat BC das genau einmal getan. Ich habe den Key eben entfernt und der Start ist genau so schnell wie vorher. Ich sehe die von Dir beschriebene Pause auch nicht. Der gesamte Startvorgang dauert ca. 5 Sekunden.