4. Zukunft des C++ Builders (Vista?)

Zukunft des C++ Builders (Vista?)

  • C

    Hallo,

    ich wollte einmal fragen wie Ihr die Zukunft des 'Codegear' C++ Builders sieht?
    Bleibt ihr ihm weiter treu oder überlegt ihr auch auf Visual Studio umzusteigen?

    Ich persönlich möchte den BCB nicht mehr missen. Mit Visual Studio komme ich einfach nicht so gut klar.

    Was meint ihr, wird er sich in Zukunft noch behaupten? Oder wird man wenn man nicht über Tellerrand schaut irgendwann auf einer veralteten nicht weiterentwickelten IDE sitzen?

    Habt ihr was gehört wie es weiter gehen soll in Punkto Unterstützung von Windows Vista (64Bit ?) und der neuen Möglichkeiten?
    In Delphi 2007 sollen wohl Ajax und die neue Funktionen von Aero integriert werden, aber ich habe nichts von 64Bit gelesen.

    Und wie wird es dann wohl generell aussehen in Zukunft. Kann man wohl per Option einstellen ob man ein 32 oder 64Bit Release macht? Man muss ja trotzdem auch Abwärtskompatibel für 2000/XP bleiben.

    Danke 🙂

    Christian

    0
  • A

    Hallo

    Ich bin bereits bei meinen neuen Projekten vom Builder weg. Mich stört weniger die IDE selber als die selbstgebackene nicht standardkonforme VCL. Wenn sich das Framework nicht in den nächsten Versionen nicht mehr zu Standard hin bewegt sehe ich in ihr auch keine Zukunft... aber vermutlich will Borland die Delphi-Ähnlichkeit nicht aufgeben.

    /Edit : Grammatik korrigiert.

    bis bald
    akari

    0
  • ?

    akari schrieb:

    Ich bin bereits bei meinen neuen Projekten vom Builder weg.

    Und zu was genau bist du gewechselt?

    0
  • C

    Hallo,

    das entmutigt mich schon mal.

    Das ganze Thema unbeunruhigt mich insofern, da ich mit dem Builder auch mein Geld verdiene (als Werksstudent).
    Mit dem BCB werde ich immer fitter... aber was bringt mir das, wenn der Marktführer MS den BCB komplett verdrängt.
    Meinst du es ist sinnvoller jetzt mit Vista auf Visual Studio parallel umzusteigen um den Anschluss nicht zu verlieren? Da habe ich nämlich Angst vor.

    Hat schon einer 64Bit Erfahrung?

    0
  • A

    Hallo

    Fragelein schrieb:

    akari schrieb:

    Ich bin bereits bei meinen neuen Projekten vom Builder weg.

    Und zu was genau bist du gewechselt?

    Momentan arbeite ich an einem größen Projekt mit dem Code::Blocks/MinGW, als Framework wxWidgets. So richtig zufrieden bin ich damit aber auch noch nicht.

    bis bald
    akari

    0
  • A

    chbr schrieb:

    ich wollte einmal fragen wie Ihr die Zukunft des 'Codegear' C++ Builders sieht?

    Ungewiß. Wenn CG den Compiler auf längere Sicht in bezug auf Standardkompatibilität und Codeeffizienz wieder konkurrenzfähiger macht, sehe ich Hoffnung. Und auch eine Linux-Version der VCL unter Mitarbeit der Community ist im Gespräch...

    chbr schrieb:

    Ich persönlich möchte den BCB nicht mehr missen. Mit Visual Studio komme ich einfach nicht so gut klar.

    Geht mir auch so. Zumal es sonst, von Delphi abgesehen, einfach kein gescheites RAD-Tool für Win32 gibt.

    chbr schrieb:

    Was meint ihr, wird er sich in Zukunft noch behaupten? Oder wird man wenn man nicht über Tellerrand schaut irgendwann auf einer veralteten nicht weiterentwickelten IDE sitzen?

    Seinen Bruchteil des Marktes wird er sicher noch eiige Zeit behaupten können. Und weiterentwickelt wird er auf jeden Fall - auch Delphi für .NET und C#Builder werden weiterentwickelt, und die werden deutlich weniger nachgefragt als der C++Builder. CodeGear will den Win32-Tools, also Delphi und C++Builder, auf den ausdrücklichen Wunsch der Community jedenfalls den Vorzug geben.

    chbr schrieb:

    Habt ihr was gehört wie es weiter gehen soll in Punkto Unterstützung von Windows Vista (64Bit ?) und der neuen Möglichkeiten?
    In Delphi 2007 sollen wohl Ajax und die neue Funktionen von Aero integriert werden, aber ich habe nichts von 64Bit gelesen.

    Soweit ich das mitbekommen habe, dürfte es entweder in absehbarer Zeit einen C++Builder 2007 als Pendant zu Delphi 2007 geben, der Vista-Kompatibilität, die überarbeitete IDE und Intraweb 9 (Ajax) enthält, oder das wird bis zum Highlander-Release (gegen Mitte 2007) verschoben. 64 Bit wird wohl noch nicht dabei sein (und wenn, dann wohl erst für Delphi), aber auch sonst dürften die Neuerungen interessant werden. Und auf der Roadmap steht 64-Bit-Unterstützung auf jeden Fall - wahrscheinlich kommt es 2008.

    chbr schrieb:

    Und wie wird es dann wohl generell aussehen in Zukunft. Kann man wohl per Option einstellen ob man ein 32 oder 64Bit Release macht?

    So wird es dann wohl sein.

    chbr schrieb:

    Meinst du es ist sinnvoller jetzt mit Vista auf Visual Studio parallel umzusteigen um den Anschluss nicht zu verlieren? Da habe ich nämlich Angst vor.

    Glaube ich nicht. Nur wenn du WPF aka Avalon benutzen willst, mußt du vermutlich auf eine .NET-fähige Sprache zurückgreifen - aber das dürfte in absehbarer Zeit noch keine allzu dringende Relevanz bekommen. Vielleicht gibt es bis dahin ja auch Managed C++ von CodeGear - auf der Roadmap stand es jedenfalls mal. Und wenn nicht, benutze einfach Delphi für .NET - wenn du die VCL kennst, dürftest du auch damit ziemlich problemlos klarkommen.

    akari schrieb:

    Mich stört weniger die IDE selber als die selbstgebackene nicht standardkonforme VCL. Wenn sich das Framework nicht in den nächsten Versionen nicht mehr zu Standard hin bewegt sehe ich in ihr auch keine Zukunft... aber vermutlich will Borland die Delphi-Ähnlichkeit nicht aufgeben.

    Würde mich in der Tat wundern. Die VCL hat sich schon in den Experimenten mit Kylix (CLX/Qt) und C++BuilderX (wxWidgets) als wesentlich attraktivere Lösung als diverse portable Libraries erwiesen, ich glaube nicht, daß CodeGear sich so etwas noch einmal leistet. Und für mich selbst ist die Kompatibilität zu Delphi ein wesentliches Argument für den C++Builder - man kann in einem Projekt sowohl von der Produktivität Delphis als auch den Möglichkeiten der Sprache C++ Gebrauch machen. .NET mit C# und C++/CLI ist eigentlich nichts anderes als das, nur eine Nummer größer.
    Aber daß sie deswegen keine Zukunft hat, glaube ich trotzdem nicht. Bei Microsoft ist es ja nicht anders (die MFC ist auch nicht standardkompatibel, und C++/CLI ist, auch wenn es natürlich einen anderen Umfang hat, in dieser Hinsicht durchaus mit den C++Builder-Spracherweiterungen vergleichbar.

    Wenn man Wert auf Standardkompatibilität legt, benutzt man die VCL eben nur für das GUI und trennt die eigentliche Funktionalität des Programmes strikt davon. Für größere Projekte ist Standardkompatibilität in diesem Umfang ohnehin nicht praktikabel, da muß man i.d.R. ohnehin zu einer ausgereiften herstellerspezifischen Lösung (MFC, VCL, .NET, Qt, ...) greifen, und dann spricht auch nichts mehr gegen die VCL - zumal da sie hinsichtlich des OOP-Designs im Vergleich mit MFC durchaus gut ist.

    0
  • A

    Hallo

    @ audacia : Das Problem ist einfach das die VCl einige Extravaganzen mitbringt, die stilitisch einfach schlecht sind. Dazu gehört die Ignorierung von namespaces bzw. das Voranstellen von T in den Klassen, der Anfang der Indizierung bei AnsiString mit 1, __closure, Ignorierung von Templates (halbherzige Ausnahmen wie DynamicArray bestätigen die Regel), Verleitung zu zu viel unnötigen dynamischen Speicherverwaltung...
    Dazu kommt noch die immer geringer werdende Unterstützung vom C++ Standard durch den Compiler selber... zum Beispiel läßt sich das boost-Package teilweise nicht mit dem Builder Compiler kompilieren (afaik). Da aber ein Teil davon schon im TR1 ist und im nächstem C++ Standard sein wird, muß Borland hier ordentlich nachbessern um nicht den Anschluß zu verlieren. Immerhin wollte Borland den Builder ja erst vor kurzem ganz einstellen... da kann ich mir nicht vorstellen das dort jetzt wieder mit ganzen notwendigen Eifer aufgeholt wird.

    bis bald
    akari

    0
  • A

    akari schrieb:

    Das Problem ist einfach das die VCl einige Extravaganzen mitbringt, die stilitisch einfach schlecht sind. Dazu gehört die Ignorierung von namespaces bzw. das Voranstellen von T in den Klassen, der Anfang der Indizierung bei AnsiString mit 1, __closure, Ignorierung von Templates (halbherzige Ausnahmen wie DynamicArray bestätigen die Regel), Verleitung zu zu viel unnötigen dynamischen Speicherverwaltung...

    In bezug auf den T-Präfix teile ich die Auffassung. Namespaces werden aber durchaus verwendet - auch wenn in jeder Headerdatei ein using namespace ~; steht 🙄
    Daß AnsiStrings ab 1 indiziert werden, dürfte seine Gründe im ShortString aus Delphi 1 haben, der IIRC im Index 0 seine Länge speicherte. Auch der Verzicht auf Templates ist darin begründet, daß es solche in Delphi nicht gibt - Templates sind aber keineswegs unabdingbar für gutes OOP-Design.
    Was du mit "unnötiger dynamischer Speicherverwaltung" meinst, ist mir nicht ganz klar - um Polymorphie nutzen zu können, braucht man eben Heap-Objekte und Zeiger.
    Und was du gegen __closure hast, kann ich beim besten Willen nicht verstehen - das fehlt mir in Standard-C++ dauernd. IMHO eines der Defizite dieser Sprache.

    Mit der Standardkonformität des Compilers hast du allerdings recht - da muß noch viel getan werden. So schlimm, wie VC6 war, ist es aber nicht 😉

    0
  • A

    Hallo

    Auch der Verzicht auf Templates ist darin begründet, daß es solche in Delphi nicht gibt - Templates sind aber keineswegs unabdingbar für gutes OOP-Design.

    Nein notwendig sind sie nicht... aber schau dir mal an was die STL alles aus Templates rausholt... auch nur durch einfache Funktionen. Als Beispiel verweise ich nur mal auf lexical_cast (kann man durch std::stringstream auch schnell selber schreiben). Im Builder gibts dafür Dutzende einzelne Funktionen.

    Was du mit "unnötiger dynamischer Speicherverwaltung" meinst, ist mir nicht ganz klar - um Polymorphie nutzen zu können, braucht man eben Heap-Objekte und Zeiger.

    Deshalb hab ich ja geschrieben : Verleitet. Die VCL selber benutzt nicht mehr dynamische Verwaltung als notwendig. Aber jedenfalls bei mir wars so das ich irgendwann zu viel dynamisch gemacht habe, ohne mir vorher zu überlegen ob es nicht doch durch einfache Stack-Instanzen mit sinnvollen Kopierkonstruktoren, Zuweisungop und selbstverwaltende Container erledigt werden kann.

    Und was du gegen __closure hast, kann ich beim besten Willen nicht verstehen - das fehlt mir in Standard-C++ dauernd. IMHO eines der Defizite dieser Sprache.

    Solange es für einfache Rein-Raus Aufrufe benutzt wird ist __closure wirklich praktisch. Allerdings bei komplexeren Eventhandling reicht es nicht mehr aus : Dann sollten gleich richtige Mechanismen wie das Observer-Pattern benutzt werden. Zum Beispiel wenn ein Event nicht nur an eine Komponente gehen soll, sondern an mehrere hintereinander, muß man mit __closure immer manuell nacharbeiten. Da sich __closure-Events nicht von selbst wieder "deregistrieren" wenn die Zielkomponente gelöscht wird können so ganz schnell ungültige Zugriffe das Programm raushauen. Hier bietet zum Beispiel wxWidgets ein wesentlich funktionsreicheres und cleveres Eventmanagment, das oben genannte Dinge besser löst.

    Die VCL ist wirklich praktisch und man kann schnell Standardsoftware schreiben. Allerdings darf man sich eben nicht nur darauf verlassen... ich seh an meiner Vergangenheit und manchen Usern hier im Forum, das die Bequemlichkeit und mangelnde C++ Umsetzung bzw. Delphi-Nähe doch verleitet schlechtes C++ zu schreiben. Seit ich jetzt einen Blick über den Tellerrand geworfen habe habe ich mich viel mehr mit alternativen Möglichkeiten beschäftigt, was nun auch wieder meinen Stil in meinen immer noch bestehenden Builder-Projekten verbessert.

    bis bald
    akari

    0
  • A

    akari schrieb:

    Allerdings bei komplexeren Eventhandling reicht es nicht mehr aus : Dann sollten gleich richtige Mechanismen wie das Observer-Pattern benutzt werden.

    Da hast du recht. Allerdings gibt es mit TActionList/TActionManager durchaus einen Ansatz in diese Richtung.

    Ansonsten mag es schon sein, daß der C++Builder ein wenig zum Delphi-Stil verleitet. Mir sind die Vorteile all der schönen Dinge in C++ wie z.B. Stackobjekte, Templates etc. allerdings viel zu hilfreich, um auf sie versehentlich zu verzichten 😉

    0
  • A

    Hallo

    Mir sind die Vorteile all der schönen Dinge in C++ wie z.B. Stackobjekte, Templates etc. allerdings viel zu hilfreich, um auf sie versehentlich zu verzichten

    Dann bist du auch erfahren genug um die unbestreitbaren Vorteile des Builders zu nutzen ohne dich von den Nachteilen aufhalten zu lassen 😉

    bis bald
    akari

    0
Anmelden zum Antworten