Delphi 2011 heißt jetzt Delphi XE

[Hansa]

Zitat von mkinzler:

Das hat auch einen guten Grund. Hätte nur noch zu mehr Problemen geführt und Unicode wäre zur 2. BDE geworden.

Wieso mehr Probleme ? Zu mehr Arbeit hätte es wohl geführt, das stimmt wohl. Wo kommt da jetzt eigentlich die BDE ins Spiel ? Abwärtskompatibel bleiben bis zum geht nicht mehr und dann plötzlich alles über Bord werfen und Compilerschalter einsparen oder wie ? Ich reklamiere mal etwas "Made in Germany" auch für mich selber. Soll heissen : alles muss auch funktionieren, sofern elementares geändert wird. Genau dafür sind Compilerschalter da. Habe hier selber etliche. Wäre ehrlich gesagt auch froh, ich bräuchte sie nicht. Geht aber nicht, also bleiben sie. Gabs nicht mal zu 16/32 Bit Zeiten ein $IDEF LONGINT oder so ?? Integer als 2 Bit oder 4 ? 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.

[mkinzler]

Die Abwärtskompatibilität hast du bei Verwendung von AnsiString. Und der Vergleich mit der BDE beziehst sich auf die Tatsache, dass sie immmer noch verwendet wird und viele sich von der Abkündigung und dem Rat diese nicht mehr zu verwenden sich nicht von ihr abbringen lassen.
Gebe es einen Schalter, der regelt auf welchen Stringtyp string gemappt wird, würde dieser einmal gesetzt werden und die Umstellung auf Unicode würde Ausbleiben.

[ralfschwalbe]

Jetzt muss ich auch mal was dazusagen.

Ein Compilerschalter hätte auch Vorteile gehabt, aber ich will hier nicht die (zu Hauf schon geführte) Diskussion neu entfachen. Ich persönlich habe das Problem, dass wir Datenbankzugriffe mit einem Puffer fester Länge realisieren (PervasiveSQL mit Zugriffsmethode Btrieve). Daran wird sich auch in der nächsten Zeit nichts ändern. 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;

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.

Ist ein Scheißjob! Wir brauchen noch nichtmal Unicode! Ein Schalter wäre mir da schon lieber gewesen.

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.

[mkinzler]

Dann würden alle nur diesen Schaltersetzten, als dafür zu sorgen, dass ihr Code an Unicode angepasst wird. Und wie schon geschrieben gibt es unter x64 nur noch Unicode, deshalb ist es wichtig seine Programme anzupassen.

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

[ralfschwalbe]

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

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

[himitsu]

Zitat von ralfschwalbe:

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 von mkinzler:

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 von himitsu:

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

[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 if irgendwas=true ein weitaus größerer Aufreger, als textsatz:string; oder auch ein 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