Lohnt es sich noch in den Builder tiefer einzuarbeiten?
-
Ich habe den Eindruck den setzt kaum jemand ein, wenn man sich die Stellenanzeigen anschaut, wenn überhaupt was von Borland im Einsatz ist, dann Delphi.
Wenn es sich um Windowsprogrammierung und C++ handelt dann fordern die ganzen Stellenanzeigen MFC und Visualstudiokenntnisse obwohl man damit mehr oder weniger (meisten sehr viel mehr
umständlich zum Ziel kommt.Wo setzt ihr den Builder ein? Privat, beruflich (Selbstständig oder Angestellt) würde mich mal interessieren.
-
Und was ist mit dem Developer Studio für c++?
http://www.borland.de/estudiocpp/
-
Builder ist offensichtlich leichter zu handhaben als MSVC++, was die Bunti-Klicki-Schiene angeht. Wie sehen das die Profis?
-
Ich arbeite jetzt in der Firma ca. 3 Jahre damit, nachdem ich mich vorher privat nur mit MSVC++ beschäftigt habe. Das Konzept der GUI-Erstellung ist schon sehr gelungen so wie die VCL überhaupt. Es könnte ein großartiges Produkt sein.
Leider gibt's auch tonnenweise Probleme damit. Die IDE ist sehr instabil. Man muss das Ding also am Tag sicher 20-30 mal killen und neu starten. Nicht tragisch, weil eh automatisch gespeichert wird, aber lästig. Die IDE bietet bei weitem nicht so viel wie MSVC. "Goto definition" von MSVC vermisse ich schmerzlich - es gibt zwar so was ähnliches, aber das versucht nur zu "erraten", wo das nun ist und nimmt die Info nicht vom Compiler. Autocomplete ist wesentlich schlechter und außerdem sooo langsam, dass man es sofort ausschaltet. Auf aktuellen Rechnern dauert's nicht selten 10 sek, bis das Fenster aufgeht. Überhaupt ist die ganze IDE ziemlich träge, wenn das Projekt mal etwas größer ist.
Weitere Lästigkeiten sind, dass der Kommandozeilencompiler und der in die IDE integrierte sich geringfügig anders verhalten. Unser aktuelles Projekt kann ich z.B. nur mehr auf der Kommandozeile compilieren, weil sich die IDE über eine nicht definierte Klasse beschwert. Das empfiehlt sich aber soundso, weil's auf der Kommandozeile ca. 5x so schnell ist. Die Kommandozeile schreibt aber in die Debug-Info relative Pfade, die IDE absolute. Wenn man's dann im Debugger öffnet, macht der deswegen jedes File doppelt auf. Lästig, denn wenn man dann das eine editiert und speichert, fragt er ständig, ob das andere nachgeladen werden soll...
Bugs hat der Compiler natürlich auch schöne (das ist der einzige Compiler, bei dem ich jemals tatsächlich über Compilerbugs gestolpert bin). Wenn man RAII extensiv verwendet, hat er irgendwann keine Lust mehr, die Destruktoren aufzurufen. Ja, das ist besonders lustig... Wenn man in einem switch-Statement an verschiedenen Stellen strings initialisiert, werden am Ende die Destructoren von allen strings aufgerufen, auch von den nicht initialisierten. Der ist nicht schlimm, weil er leicht umgangen werden kann. Irgendwas hatten wir noch, hab ich aber vergessen. Aber selbst wenn der Compiler mal richtigen Code erzeugt, muss man damit leben, dass der so langsam ist, dass ihn selbst der ungeübteste Anfänger von Hand in asm schneller schreiben könnte. Profiler gibt's dafür überhaupt keinen...
Es könnte ein nettes Produkt sein, hat aber so viele Kinderkrankheiten, dass wir auch versuchen, irgendwann davon wegzukommen - leider haben wir halt sehr viel existierenden Code, der in Form von VCL-Komponenten vorhanden ist. Und Borland würde das Ding ja am liebsten begraben und vergessen.
-
Ich kann hier Ringding zu 100% zustimmen, wobei wir sowohl BC5 als auch VC6 einsetzen. Für kleinere lokale Projekte, die in kurzer Zeit erstellt werden müssen, ziehe ich, trotz aller Macken, den Builder vor.
Ist die VCL mal nicht ausreichend, kann man unter dem Builder auch durchaus noch auf die MFC zugreifen. Wenn es jedoch um professionelles Arbeiten geht, ist VC6 aus meiner Sicht ganz klar im Vorteil.
-
Manfred Schmidtke schrieb:
Für kleinere lokale Projekte, die in kurzer Zeit erstellt werden müssen, ziehe ich, trotz aller Macken, den Builder vor.
also ich finde für mini-sachen und zum testen von c-codes den nicht mehr ganz zeitgemässen vs6 unschlagbar.
topic: so schlecht habe den bcb nicht in erinnerung, ausser dass die toolbar manchmal komisch aussah und nicht auf den bildschirm passte
-
Ich setze den C++Builder schon seid Jahren beruflich ein (ab v.1.0).
Bis auf kleine ,aber zu behebende Fehler, bin ich sehr zufrieden damit.
Das einzige was mich besonders stört das die Halcon nicht richtig funktioniert.Ansonsten habe ich schon recht große Projekte damit entwickelt welche in meiner Firma ganze Messsystem in Produktionsanlagen steuern.
Gruß Rainer
PS. Die Halcon ist ein Vision-System.
-
Nach eigenen Angaben wird Borland den Borland Builder in der nächsten Delphi Version unterbringen, wo jetzt schon der C#-Builder drinnensteckt. Die Sache insgesamt gesehen wird wohl so aus sehen, daß mit .NET und Longhorn dann alle Compiler nur noch in .Net Scriptsprache und nicht mehr in Binärcode wandeln. In wie weit man dann noch hardwarenah programmieren kann ist dann die Frage, weil wir dann den Zustand wie beim heutigen Java haben (virtuelle Maschine). Bei mir auf Arbeit benutzen wir heute noch einige Dos-Rechner mit Turbo C++ um die Daten aus A/D-Karten zeitgerecht auslesen können.
-
Nachtrag:
Heute laufen die .Net-Programme im Emulationsmode. Mit Longhorn werden die heutigen "Binärprogramme" im Emulationsmodus laufen, so wie heute die DOS-Programme in Windows. Das Gute ist man muss nicht mehr den aktuellsten Compiler haben, weil dann das Betriebssystem (Longhorn) dafür sorgt, das die Hardware optimal ausgelastet wird.