BCB6 und dann?
-
DocShoe schrieb:
Würde nix mehr von Borland/Codegear benutzen. Die meisten 3rd Party libraries gibt´s nun mal für das MS Visual Studio, daher wäre MS Visual Studio meine Wahl. Wenn du allerdings nur privat Kleinigkeiten programmieren und dich auch nicht in eine neue Entwicklungsumgebung einarbeiten möchstest guck dir den Codegear 2007 an.
Gruß,
DocDas ist absoluter Quatsch. Für den privaten Hobbyprogrammierer tut es MS VS. Für den Rest, der etwas professioneller und damit eine sehr aufgeräumte und ausgereifte Umgebung bevorzugt, ist der BCB 2007 erste Wahl.
Das ist allerdings so wie der Flamewar Linux VS Windows.MS VS ist absolut nicht mit dem Entwicklungsstand des aktuellen BCB zu vergleichen.
-
Was für 3rd-PartyLibs meinst du denn damit?
Ich habe das VS auch mal getestet fand es aber nicht sonderlich gut. Es fühlt sich für mich in der Bedienung irgendwie langsam an. Manche Optionen sind besser versteckt als beim BCB (z.Bsp. Libs hinzufügen, PCH). Ich bin aber eben auch den BCB gewohnt, für Neueinsteiger mag das anders aussehen.
Was gut funktioniert ist die Qt-Einbindung. Aber nur deswegen habe ich mich dann doch nicht entschliessen können zu wechseln. Für Qt nehme ich zur Zeit noch CodeBlocks obwohl der Debugger einen manchmal in den Wahnsinn treiben will.
-
Was bei VS 2008 und C++/CLI unter DotNet auch nicht vergessen werden darf ist dass diese Sprache zunehmend den Raum Interoperabilität mit "alten" Programmteilen ausfüllen wird bzw. der weitere Ausbau darauf konzentriert wird. Wer effizient mit Werkzeugen wie Datenbankdesigner, LINQ, Support von MS Office, Sharepoint usw. arbeiten will, muss zusätzlich noch ein Wechsel der Sprache zu C# erwägen.
-
phleg schrieb:
MS VS ist absolut nicht mit dem Entwicklungsstand des aktuellen BCB zu vergleichen.
Das ist so uneingeschränkt richtig... aber lassen wir das
Gruß,
Doc
-
Ja ich weiss worum es geht... BCB ist so die RAD Schiene.
Aber es gibt bestimmte Eigenschaften dieser Produkte, die doch gleich sind.
Und über die wurde hier nur gesprochen ... oder nicht ?
-
Braunstein (off) schrieb:
Was für 3rd-PartyLibs meinst du denn damit?
Ich habe das VS auch mal getestet fand es aber nicht sonderlich gut. Es fühlt sich für mich in der Bedienung irgendwie langsam an. Manche Optionen sind besser versteckt als beim BCB (z.Bsp. Libs hinzufügen, PCH). Ich bin aber eben auch den BCB gewohnt, für Neueinsteiger mag das anders aussehen.
Was gut funktioniert ist die Qt-Einbindung. Aber nur deswegen habe ich mich dann doch nicht entschliessen können zu wechseln. Für Qt nehme ich zur Zeit noch CodeBlocks obwohl der Debugger einen manchmal in den Wahnsinn treiben will.Ich habe keine bestimmten Bibliotheken angesprochen, sondern nur die Tatsache, dass die meisten Bibliotheken für das Visual Studio zur Verfügung stehen. Für quelloffene Bibliotheken wird oft eine VS Projektdatei mitgeliefert, um die Bibliothek zu erstellen. Wenn sie nicht quelloffen sind gelingt die Konvertierung mit implib auch nur selten (bei mir bisher garnicht, habe allerdings nur 2 Versuche gemacht... mit welchen Bibliotheken weiss ich allerdings nicht mehr genau). Guckt euch einfach mal die Beispiele auf www.codeproject.com an und zählt mal, wieviele Beiträge es für BCB und wieviele es für MSVC gibt.
Ausserdem wird der BCB Compiler auch nicht von allen Bibliotheken unterstützt, sogar boost unterstützt den BCB Compiler wegen mangelnder Kompatibilität zum Standard nicht mehr offiziell.
Auch die Tatsache, dass Borland die Compilersparte zuerst ausgegliedert und dann verkauft hat sollte jemandem, der langfristige Projekte pflegt, beunruhigen. Hier die entsprechende Meldung auf heise online.
Auch das Veröffentlichen von 3 grossen Updates innerhalb des ersten Jahres nach der Veröffentlichung von Codegear 2007 trägt nicht zu meinem Vertrauen in diese Suite bei, ebensowenig wie das Mitliefern einer 5 Jahre alten STL Implementation von Dinkumware (wobei Dinkumware zu den Rolls Royce/Ferraris der STL Implementationen gehört).
Was mich am BCB auch noch gewaltig stört sind so Funktionen wie FileDelete, die nichts anderes machen als die Win32 Funktion DeleteFile aufzurufen. Für einen ganzen Haufen Win32 Funktionen gibt es eine VCL Wrapper Funktion, die weniger flexibel ist als die ursprüngliche Win32 Funktion (zugegebenermassen dafür auch mit weniger Parametern auskommt). Gut, man muss diese VCL Funktionen nicht benutzen und kann sofort die Win32 Funktion nehmen, aber wofür sind sie dann da?!Gruß,
Doc
-
Für Borland gibt es dafür entsprechend viele Komponenten als Alternative so dass man eigentlich immer etwas findet. Vieles davon ist zwar in Delphi geschrieben funktioniert aber auch.
Wenn externe Bibliotheken in Standard-C++ geschrieben sind bekommt man sie im allgemeinen auch zum Laufen. bei Codeproject sind sie halt etwas auf MS-Compiler fixiert, weswegen das für mich kein Maßstab ist. Da kann man z.Bsp. bei
http://www.torry.net/index.htm
http://www.componentsource.com/features/codegear/index-de.html
etc. nachschauen.Das CodeGear jetzt verkauft wurde sehe ich eher als Plus. Die Kommentare dazu in den entsprechenden Newsgroups sind auch recht positv. Bei Borland hatte man die IDE/Compilersparte eh nur noch als Klotz am Bein gesehen. Das kann eigentlich nur besser werden. Die Roadmaps für die weiteren Entwicklungen sehen vielversprechend aus.
Was die gewrappten WinAPI-Funktionen in der VCL betrifft. Das kommt eigentlich alles von der Delphi-Schiene, da man dort nicht so ohne weiteres WinAPI-Funktionen aufrufen kann. Desweiteren sollen diese Funktionen das Handling der WinAPI für Einsteiger erleichtern. Da ist die höhere Funktionalität dort ja eher hinderlich.
Und wie du schon sagst, kann man ja, wenn man will, die WinAPI-Funktionen auch noch direkt benutzen.
Ich nutze die meisten dieser Funktionen aber auch kaum. Beim Filehandling nehme ich z. Bsp. meist boost::filesystem. Wenn man ein wenig sucht findet man immer das passende.
-
Interessante Links, werde die mir mal in Ruhe angucken, vielleicht ist ja was für mich Brauchbares dabei.
Gruß,
Doc
-
DocShoe schrieb:
Guckt euch einfach mal die Beispiele auf www.codeproject.com an und zählt mal, wieviele Beiträge es für BCB und wieviele es für MSVC gibt.
Die Seite ist ja bekanntermaßen VS-lastig; es gibt auch Delphi/C++Builder-lastige Alternativen (siehe Braunsteins Post). Das ändert nichts daran, daß viele CodeProject-Beispiele auch mit dem C++Builder benutzbar sind.
DocShoe schrieb:
Ausserdem wird der BCB Compiler auch nicht von allen Bibliotheken unterstützt, sogar boost unterstützt den BCB Compiler wegen mangelnder Kompatibilität zum Standard nicht mehr offiziell.
Das ist richtig, aber wie in der Roadmap nachzulesen ist, ist die Unterstützung von Boost für CodeGear von großer Relevanz.
DocShoe schrieb:
Auch die Tatsache, dass Borland die Compilersparte zuerst ausgegliedert und dann verkauft hat sollte jemandem, der langfristige Projekte pflegt, beunruhigen. Hier die entsprechende Meldung auf heise online.
Dazu möchte ich dich auf diesen Artikel verweisen.
DocShoe schrieb:
Was mich am BCB auch noch gewaltig stört sind so Funktionen wie FileDelete, die nichts anderes machen als die Win32 Funktion DeleteFile aufzurufen. Für einen ganzen Haufen Win32 Funktionen gibt es eine VCL Wrapper Funktion, die weniger flexibel ist als die ursprüngliche Win32 Funktion (zugegebenermassen dafür auch mit weniger Parametern auskommt). Gut, man muss diese VCL Funktionen nicht benutzen und kann sofort die Win32 Funktion nehmen, aber wofür sind sie dann da?!
Wie Braunstein anmerkte, handelt es sich hierbei um Funktionen aus der Delphi-RTL, die Delphi seinerseits von Turbo Pascal geerbt haben könnte. Turbo Pascal konnte nämlich anfangs noch nicht auf das Windows-API zurückgreifen
Wieso stört dich die bloße Existenz von Funktionen, die der Linker bei Nichtgebrauch ohnehin wegoptimiert?
Braunstein schrieb:
Was die gewrappten WinAPI-Funktionen in der VCL betrifft. Das kommt eigentlich alles von der Delphi-Schiene, da man dort nicht so ohne weiteres WinAPI-Funktionen aufrufen kann.
?
Das Aufrufen von WinAPI-Funktionen ist in Delphi genauso leicht möglich wie in C++.
-
audacia|off schrieb:
Das Aufrufen von WinAPI-Funktionen ist in Delphi genauso leicht möglich wie in C++.
Da habe ich wohl falsch nachgedacht.
Es ja wohl logisch, dass das gehen muss, sonst würde es die Funktionen ja nicht geben.
Es ist halt schon ziemlich lange her, dass ich was mit Pascal gemacht habe. Damals habe ich mich auch nie mit WinAPI beschäftigt.