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?