Hat C++ Builder auf dem Markt Zukunftsaussichten?
-
Hi,
was meint Ihr , Hat C++ Builder auf dem Markt Zukunftsaussichten im Vergleich
zu Konkurenzprodukten?Bei uns in der Firma nutzen wir den Builder und sind eigentlich im großen und ganzen zufrieden.
Aber, wenn man zum Bespiel zukunftsorientiert denkt, macht man sich schon mal Gedanken, wie viel Zeit noch dem C++Builder bleibt...
Danke schon mal im voraus für Eure anregungen!
epidemic
-
Verschoben nach "Rund um".
-
Er wird sicherlich niemals die Nummer 1 auf dem Markt werden.
Aber unter Windows hat Borland mit der Kombination Builder + Delphi (die darf man nicht so getrennt sehen) eine starke Stellung als die Nummer 2 hinter Microsoft.
Das ist die Basis.
Und Borland hat auch gezeigt, daß sie in der Lage sind auf neue Märkte zu reagieren - die Produktpalette unter Linux ist ja auch nicht zu verachten. Zur Zeit ist der Builder das einzige breitenwirksame Produkt, das die Entwicklung unter Windows und Linux koordiniert und vereinheitlicht.
Dadurch ist Borland in der Lage Marktverschiebungen von Windows nach Linux zu kompensieren, vorausgesetzt sie sind in der Lage für die Produkte unter Linux genauso viel Geld zu verlangen wie für die Produkte unter Windows. Das wird der Hauptknackpunkt sein.
Von der Technik her würde ich mir aber um Borland keine solchen Gedanken machen.
-
borland wird wahrscheinlich von microsoft geschluckt werden, daher denke ich, dass die zukunftsaussichten nicht gerade berrauschend sind.
-
Moment, redest Du von Borland oder vom Builder?
Wenn Borland von Microsoft geschluckt wird, werden sie viele Dinge vom Builder in eines der nächsten VS.Nets stecken und sich was einfallen lassen, wie man VCL-Projekte damit übersetzen kann. Damit ist der Bestand des Quellcodes vorerst gesichert - und darin ging es doch wohl in der Anfangsfrage.
Die Firma Borland mag dadurch untergehen, aber die waren seit den 80ern doch ohnehin schon dreimal Pleite, ist insofern nichts Neues für Borland-Kunden.
Weiterhin bezweifle ich, daß Microsoft Borland schluckt - wozu? Wer sich die WinForms-Bibliothek von .NET anschaut und auch den grafischen Editor dazu findet überall nur VCL, VCL, VCL. Die Klassen und Methoden heißen auch ähnlich. Der Umstieg von VCL auf .NET ist kleiner als von MFC auf .NET. Kein Wunder, die haben doch schon das Delphi-Entwicklungsteam vor 3 Jahren eingekauft.
Was bleibt noch an Defiziten? Die Standardkompatibilität vom VC++ - da würde man mit Borland nach Vorne springen. Aber auch dafür ist es zu spät, da die neue VC++ 2002 Beta schon draußen ist und nun auch mit komplizierten Template-Sachen besser klar kommt.
Weiteres Ziel wäre der Linux-Markt von Borland, um diesen a) einzustellen oder b) zu übernehmen. b) erscheint mir wenig sinnvoll, wenn Microsoft Linux-Produkte herstellen will, dann sind sie dazu selbst in der Lage. Schließlich schaffen sie das auch für den Mac, und der hat sogar einen anderen Prozessor. Und Borland töten, um einen Anbieter von Entwickler-Produkten für Linux aus dem Markt zu nehmen... wenig sinnvoll, da sich gerade auf dem Linuxsektor der Markt für kommerzielle Produkte immer noch entwickelt. Ist ja nicht so, daß man Linux damit einen Schlag verpassen würde.
-
Original erstellt von Marc++us:
Weiterhin bezweifle ich, daß Microsoft Borland schluckt - wozu?um eine art monopol auf die (c++ -) dev programme zu bekommen? da gibt es ja praktisch nur borland c++ builder und MS vc++. ich denke kaum, das der ottonormal-entwickler einen intel(?) compiler besitzt.
Original erstellt von Marc++us:
Aber auch dafür ist es zu spät, da die neue VC++ 2002 Beta schon draußen ist und nun auch mit komplizierten Template-Sachen besser klar kommt.echt? wo bekommt man den? oder bekommen das nur firmen etc?
-
Hoppla, 2003 natürlich und nicht 2002.
siehe hier:
MSDN Subscriber müsste man sein, visual studio 2003 beta
-
ich denke kaum, das der ottonormal-entwickler einen intel(?) compiler besitzt.
Ich hab mal gehört, dass es noch mehr Compiler gibt, als MSVC++ und den Intel Compiler und das diese sogar von ganz normalen Menschen benutzt werden auf ganz anderer Hardware zum Teil
-
Original erstellt von kingruedi:
Ich hab mal gehört, dass es noch mehr Compiler gibt, als MSVC++ und den Intel Compiler und das diese sogar von ganz normalen Menschen benutzt werden auf ganz anderer Hardware zum TeilEben! Und das sind gerade NICHT die Ottonormal-Entwickler. Diese benutzen nämlich BCB/Delphi oder VC++. Alles andere ist selten. Oder war das von dir nur ein Hinweis, dass die Nicht-Ottonormal-Entwickler auch andere Compiler benutzen als den von Intel?
-
Hi,
Danke für Eure Anregungen!!!!
Weiß zufällig einer von Euch, ob in dieser neuen,
tollen Version von MVC++ .Net2003 die MFC verbessert werden soll?Machen wir uns nichts vor,bis jetzt war MFC sehr schlecht konzeptioniert.
epidemic
-
btw .. Microsoft darf Borland nicht aufkaufen ... sonst hätten sies schon lang getan ..
... das die Borland Compiler jedoch nur nummer 2 hinter Microsoft sind möchte ich mal nicht behaupten .. Da die Borland Ide der M$ Ide einiges .. vorraus hat ... siehe Komponenten ..
IMHO seh ich das eh so ... MFC oder BCB ist genau wie die Frage was geiler ist ne Frau mit blonden oder eine mit braunen Haaren ... Es ist geschmacksache ..
-
Original erstellt von 1ntrud0r:
... das die Borland Compiler jedoch nur nummer 2 hinter Microsoft sind möchte ich mal nicht behauptenDas ist außer Frage! Borland ist nicht Nummer 1. Es geht hier um Marktanteile, nicht um IDEs.
-
@WebFritzi
was sind den für dich Otto-Normal-Entwickler? Ich kenn zum Beispiel welche, die arbeiten mit Cygwin und GCC. Digital Mars soll auch Kunden haben, hab ich mir sagen lassen.
-
Ihr lenkt langsam aber sicher vom Thema ab ...
-
ich denke nicht das der CBuilder eine schlechte zukunft hat. allerdings denke ich er wird sich weiter von windows entfernen und eher im linux bereich sich weiter entwickeln.
meiner meinung nach kann microsoft borland nich ohne weiteres übernehmen, das wird das kartellamt nicht zulassen.
-
Ich find die VCL gut designed. Wenn da nicht dieser hässliche Compiler bei wär. Musst ich mal loswerden
-
Was sagt Ihr in Eurer Firma zu den Compilier-Zeiten vom Builder? Bei uns hat er deswegen (und aufgrund einiger anderer wenig einsichtiger Macken) einen ziehmlich schlechten Ruf. Eigentlich wollen wir weg davon, aber wir ham halt so viele Projekte damit - und zu MS wolln wir auch net ...
-
würden die die VCL Compilerunabhängig machen und den Compiler durch den GCC ersetzen wette ich, dass es Marktanteile schaffen wird. Aber das werden sie sicher net tun
Wie sieht es eigentlich mit der Templateunterstützung des BCC aus?
-
also in unserer firma hat er einen recht guten ruf. gut eine kleine macken hat der schon aber das haben andere auch. was die compilier-zeiten angeht kann ich nur sagen man mus halt wissen wie man die compieler optionen richtig einstellt dann gehts auch schneller.
-
hm, darüber haben wir jetzt schon oft diskutiert. Immer wieder sagen einige, dass man das Teil schon dazu bekommt schnell zu kompilieren. Vielleicht sollten wir mal ein Tutorial machen!
Was stellst Du an den Compilereinstellungen ein, dass er schnell kompiliert?
Mit Präcompilierte Header - zumindest so wie wir das hier machen - isses uns immer noch zu langsam. Wir machens so:
wir haben einen Header precomp.h in dem sind grundsätzlich mal alle Header der Standard-Bibliothek, windows.h, und vcl.h drinnen. Diese precomp.h wird in jedem Modul eingebunden. Ganz am Anfang jeder cpp-Datei steht
#include "precomp.h"
#pragma hdrstopSo wie ich mir das vorstelle, müsste das jetzt doch so gehn:
Bei einem Rebuild werden beim ersten Modul all diese Header compiliert -> dauert recht lange, bei jedem weiteren Modul, werden sie nicht mehr compiliert -> weitere Module müssten ziehmlich schnell gehn.
Man kann dann, wenn man damit rumspielen will, für einzelne Projekte eine eigenen precomp.h machen, um nicht die ganze Standard-Bibliothek einbinden zu müssen.
Was wir nicht praktikabel auf die reihe bringen, ist eigene Header als Präkompilierte zu verwenden. Weil: Templates machen Probs, Funktionen mit Standard-Parametern erstrecht und inline geht auch nicht. Außerdem wäre der Pflegaufwand doch recht erheblich. Da unsere Projekte aber alle eigentlich nicht so groß sind, sollte das nicht so extrem ins Gewicht fallen.
Damit hab ich dann mal folgendes Ergebnis erzielt:
kleineres Projekt mit vielleicht 30 kleineren Klassen jeweils in einem eigenen Modul:
Ohne vorkompilierte Header 900 sec, mit 300 sec (ungefähr). Also mit war der Compiler 3 mal so schnell. Aufgrund der Größe des Projekts erscheinen mir 5 Minuten aber immer noch als extrem unangemessen. Außerdem, wenn das allermeiste was er kompiliert - und das ist die vcl.h, windows.h und die Header der Standard-Bibliothek wirklich nur einmal übersetzt wird, und das Compilieren eines kleinen Modulen vernachlässigbar kurz dauert, dann müsste der Compiler bei 30 Modulen auch ca. 30 mal so schnell sein. Ok, das ist ein theoretischer Wert, aber es sollte doch mehr als von 900 auf 300 sec dauern.
Was ist also der Trick, um den CBuilder zu einem schnelleren compilieren zu bringen? Wie machst Du/macht Ihr das?