Migration von C++Builder 5 nach C++Builder 2010, Tipps?
-
Hallo,
ich habe wahrscheinlich die Migration von ca. 20 Projekten (klein und groß) von C++Builder 5 nach 2010 vor mir. Da dazwischen gut 10 Jahre liegen, gehe ich davon aus, dass dies nicht ohne Probleme funktioniert.
Gibt es generelle Tipps für dieses Vorhaben, z.B.
- Nicht die vorhandenen Projekte konvertieren, sondern neue Projekte anlegen und die alten Dateien hinzufügen
- Bestimmte Komponenten funktionieren nicht mehr/funktionieren anders
...
Danke und viele Grüße
Thomas
-
Hallo,
ich habe erst ein Projekt umgezogen. Und da mir BCB 2010 keine wesentlichen Vorteile bietet, habe ich es auch bisher nicht für alle anderen Projekte durchgezogen.
Grundsätzlich kannst Du mit BCB 2010 auch die alten Projekte öffnen. Sie werden dann automatisch konvertiert. Du brauchst also keine neuen Projekte erzeugen und nur die Quellen importieren.
Die meiste Arbeit die ich hatte, war daß viele Properties statt AnsiStrings nun UnicodeStrings sind. Und UnicodeStrings kennen die Funktion c_str nicht. Da ich allerdings davon regen Gebrauch mache, war mir der Aufwand zu groß.
Ansonsten war es relativ problemlos. Allerdings war das Projekt, das ich testhalber umzog keines, das die BDE benutzt. Ich weiß daher nicht, wie gut das funktionieren wird. Die BDE wird aber immer noch mitgeliefert. Lass aber die Installation der BDE aus, wenn Du schon eine hast. Bei mir hat danach die BDE nicht mehr funktioniert und ich mußte die Registryeinträge der BDE wieder manuel herstellen. Borland hat ja schon seit Ewigkeiten die weiterentwicklung der BDE eingestellt und die von BCB 5 ist immer noch aktuell.
Laut Hersteller planen die nächstes Jahr eine Version, die auch Mac und Linux Exes erzeugen können soll. Darauf warte ich, dann werde ich umziehen.
mfg Martin
-
Ich würde erstmal die Projekte ansehen und nach Fremdkomponenten ausschau halten um dann zu überprüfen ob diese für BCB 2010 verfügbar sind bzw falls nicht vorhanden durch andere ersetzbar sind.
-
mgaeckler schrieb:
Die meiste Arbeit die ich hatte, war daß viele Properties statt AnsiStrings nun UnicodeStrings sind. Und UnicodeStrings kennen die Funktion c_str nicht. Da ich allerdings davon regen Gebrauch mache, war mir der Aufwand zu groß.
UnicodeString kennt kein c_str weil es ein WideString ist und somit w_str zu verwenden ist,
außerdem ist es besser String als Datentyp zu verwenden den dann kann man über die Projekt-Optionen einstellen ob der String ein AnsiString(char) oder ein UnicodeString(wchar_t) ist bzw existiert dann auch c_str.
-
mgaeckler schrieb:
Laut Hersteller planen die nächstes Jahr eine Version, die auch Mac und Linux Exes erzeugen können soll. Darauf warte ich, dann werde ich umziehen.
Der Crosscompiler für Windows/Mac soll schon dieses Jahr kommen mit einer preview Version für Linux (nächstes Jahr 64bit),
ich hoffe nur das es Überhaupt möglich ist bestehende Projekte zu portieren und nicht wieder so ein CLX Version kommt.
-
Hallo,
schon mal danke für die Hinweise
Die von uns verwendeten Komponenten gibt es in aktueller Version (TMS Grids, ODAC).
Ist bei 2010 die TChart-Komponente noch dabei?
Und was wurde aus den Indy-Komponenten? Meine letzte Info ist, dass diese die buggy-Netmaster-Komponenten ablösen sollten. Aber das ist auch schon Jahre her.
-
ThomasBl schrieb:
Ist bei 2010 die TChart-Komponente noch dabei?
Und was wurde aus den Indy-Komponenten? Meine letzte Info ist, dass diese die buggy-Netmaster-Komponenten ablösen sollten. Aber das ist auch schon Jahre her.TChart ist dabei und die Indy Komponenten werden mit installiert bzw. ersetzten seit BCB 7 die Netmaster Komponeten.
-
VergissEs schrieb:
UnicodeString kennt kein c_str weil es ein WideString ist und somit w_str zu verwenden ist
Doch, es gibt UnicodeString::c_str(). Aber es gibt, genau wie ::w_str(), wchar_t* anstelle von char* zurück.
VergissEs schrieb:
außerdem ist es besser String als Datentyp zu verwenden den dann kann man über die Projekt-Optionen einstellen ob der String ein AnsiString(char) oder ein UnicodeString(wchar_t) ist
Die Projektoption hat nichts damit zu tun. In C++Builder 2009 aufwärts gilt immer String == UnicodeString. Die Projektoption entscheidet, ob die WinAPI-Funktionsnamen standardmäßig auf die ANSI- oder die Wide-Varianten gemappt werden. Wenn dein Code immer "AnsiString" anstelle von "String" verwendet, mag es sinnvoll sein, die Option auf "char" zu stellen, ansonsten ist aber "wchar_t" die bevorzugte Wahl.
VergissEs schrieb:
bzw existiert dann auch c_str.
Gibt bei dir UnicodeString:c_str() einen char* zurück? Dann hast du C++Builder 2009 ohne Updates; das wurde im ersten Update "behoben". Es wurde leider erst etwas zu spät bemerkt, daß es aus verschiedenen Gründen eine ziemlich schlechte Idee ist, einen UnicodeString mit einer c_str()-Funktion zu haben, die char* statt wchar_t* zurückgibt.
-
audacia schrieb:
VergissEs schrieb:
UnicodeString kennt kein c_str weil es ein WideString ist und somit w_str zu verwenden ist
Doch, es gibt UnicodeString::c_str(). Aber es gibt, genau wie ::w_str(), wchar_t* anstelle von char* zurück.
Mein Autohändler sagt mir auch, klar kannst du Benzin in das Diesel-Auto tanken klappt halt nicht, und nur weil es die Funktion "c_str()" gibt kommt eben kein c_str() raus sonder ein w_str().
-
VergissEs schrieb:
Mein Autohändler sagt mir auch, klar kannst du Benzin in das Diesel-Auto tanken klappt halt nicht, und nur weil es die Funktion "c_str()" gibt kommt eben kein c_str() raus sonder ein w_str().
Du willst vermutlich sagen, daß du UnicodeString::w_str() bevorzugst, weil es deutlicher sagt, was passiert?
