Warum Borland?
-
Ich hab da mal ne Frage (wirklich)
Warum benutzt ihr Borland und nicht den MS-Compiler?MFG: m aus b
-
Weil die VCL einfach schöner als die MFC ist.
-
MFC ist ein mismatch aus C und C++. Keine gerade Linie erkennbar. Deshalb, und weil ich Winzigweich nicht mag, habe ich die VCL und den BCB gewählt.
-
Na ja,
weil dir VCL schöner ist, ist glaube ich ein Argument mit dem man schlecht was anfangen kann. Die VCL ist ja immerhin eine Pascal Bibliothhek und somit auch nicht direkt vergleichbar mit der MFC. Ganz anders sehe das aus, wenn man die OWL mit der MFC vergleicht, dann könnte man schon einige Argumente für die OWL finden, die die WINDOWS API besser kapselt als die MFC. Dafür hat sie andere Nachteile die meiner Meinung nach in erster Linie daran liegen, dass M$ in ihren Compiler bzw. Klassenbibliothek natürlich immer zuerst die neuesten Microsoft-Technologien (Bsp. COM+) implementiert und die anderen sozusagen hinter rennen.
Nun aber zrück zu Deiner Frage. Hier meine Argumente (dazu muss ich sagen, dass ich mehrere Jahre mit der MFC gearbeitet habe):
1.)
Der CBUILDER ist ein echtes RAD-Tool, vergleichbar mit BASIC aber eben mit C++ und all den dazu vorhandenen mächtigen Möglichkeiten.
2.)
Neben der sehr guten Unterstützung der MS-Technologien (meiner Meinung nach aber erst so richtig gut seit BCB6) werden andere Technologien wie CORBA hervorragend unterstützt.
3.)
Die Unterstützung bzw. Anbindungen verschiedener Datenbanken und nicht nur des SQL-Server ist hervorragend.
4.) Es gibt eine enorm große Anzahl von Komponenten auf dem Markt, die entweder kostenfrei sind oder in der Regel das Budget einer Firma garantiert nicht sprengen. Das hierbei der Sorcecode meistens zum Lieferumfang datzugehört ist ein weiterer Pluspunkt.
5.)Es lassen sich sehr kompakte Programme erstellen, die keinerlei Registrierungen in der Registry benötigen. Im Gegensatz,wenn man wie bei VC auf den Einsatz von COM-Objecten z.T. angewiesen ist.
6.)Borland versucht den Compiler weitesgehend nach dem ANSI/ISO Standard auszurichten. Immer gelingt dass auch nicht, aber wie es in der Werbung heißt:"immer öfter".
Dazu muss ich allerdings sagen, dass dieses Argument (ja,ja nun erschlagt mich wieder) für die meisten Entwickler bzw. erstellten Programme kein wirklich schlagendes ist. Denn auch Borland hat, gezwungenermaßen Erweiterungen vornemhem müssen, die in keinem Standard definiert sind.So, was gefällt mir nicht:
1.)
Die IDE vom Visualstudio ist meiner Meinung nach ungeschlagen
2.)
Der Support von Borland ist, sorry wenn ich das sage, beschi...
Es gibt beim C++ Compiler der Version 6 wesentliche Verbesserungen was die Unterstützung von Templates angeht. Warum konnte man den zahlreichen BCB5 Anwendern diese nicht auch zugute kommen lassen. In dem man ein entsprechendes Update nur des Compilers zur Verfügung stellt. Jeder der den BCB5 benutzt, weiß wann es das letzte Update gab.
3.)
Ein Ugrade von einer Version auf die andere ist eine Qual. Ich habe das seit BCB3 mitgemacht.O.K. Es lassen sich sicherlich noch viele Argumente dagegen und dafür finden und meistens artet das auch in einen Glaubenskrieg aus. Aber ich hoffe, Dir zumindest ein paar stichhaltige Gründe genannt zu haben, warum ich mit dem CBUILDER arbeite.
Gruß
Gerhard
-
Gerhard schrieb:
Der Support von Borland ist, sorry wenn ich das sage, beschi...
ähm, welcher Support
Gerhard schrieb:
Aber ich hoffe, Dir zumindest ein paar stichhaltige Gründe genannt zu haben, warum ich mit dem CBUILDER arbeite.
gut gebrüllt Löwe. ICh schiebs mal nach Rund um die Programmierung, damit sich die MCF- Fraktion an der Diskussion beteiligen kann. Ist sonst so einseitig.
Davon mal abgesehen gibt es dort, in Rund um.., mindestens 100 solcher Beiträge zum Thema B vs. M
Deshalb verschoben nach Rund um ...
-
Ich denke, dass der C++Builder sicherlich die bessere Wahl für GUIs und Datenbanken ist. Sollte man aber lediglich Bibliotheken und Anwendungen ohne Benutzeroberfläche schreiben, fällt dieser Vorteil des BCB weg, dafür stechen dann die Qualitäten des Visual C++ umso deutlicher hervor: hohe Standardkonformität (VC++ 7.1: http://boost.sourceforge.net/regression-logs/), benutzerfreundliche IDE, ein sehr guter Debugger und ein schneller Compiler.
-
\aleph_0 schrieb:
hohe Standardkonformität (VC++ 7.1: http://boost.sourceforge.net/regression-logs/),
Kannst du mir bitte mal erklären was hier genau gemessen wird? Irgendwie hab ich keine brauchbare Beschreibung zu den Logs gefunden. Und das Messen einer "Qualität" anhand von Warnungen scheint mir äusserst Zweifelhaft....
-junix
-
junix schrieb:
Kannst du mir bitte mal erklären was hier genau gemessen wird? Irgendwie hab ich keine brauchbare Beschreibung zu den Logs gefunden.
Es werden verschiedene standardkonforme C++-"Programme" mit verschiedenen C++-Compilern kompiliert und die erzeugten Fehler und Warnungen aufsummiert. Die Tests sind natürlich sehr künstlich/akademisch, aber geben zumindest einen Anhaltspunkt.
junix schrieb:
Und das Messen einer "Qualität" anhand von Warnungen scheint mir äusserst Zweifelhaft....
Entscheidend sind wahrscheinlich eher die Fehler.
-
Es werden verschiedene standardkonforme C++-"Programme" mit verschiedenen C++-Compilern kompiliert und die erzeugten Fehler und Warnungen aufsummiert. Die Tests sind natürlich sehr künstlich/akademisch, aber geben zumindest einen Anhaltspunkt.
Wie kommst du auf Künstlich/Akademisch? Wenn ich mich nicht täusche, sind das die Regression-Tests der Boost-Libs. Und die sind weder künstlich noch akademisch. Sondern schlicht und einfach nötig (damit natürlich und praktisch).
Sie sind aber auf jeden Fall sehr template-lastig, da boost bekanntlich eine Sammlung von hochwertigen Bibliotheken ist, und viele davon relativ gewifte Template-Techniken einsetzen.
-
HumeSikkins schrieb:
Wie kommst du auf Künstlich/Akademisch? Wenn ich mich nicht täusche, sind das die Regression-Tests der Boost-Libs. Und die sind weder künstlich noch akademisch. Sondern schlicht und einfach nötig (damit natürlich und praktisch).
Stimmt, ich wollte einfach nur ausdrücken, dass die Tests eben keine wirklichen Programme darstellen, sondern immer nur einzelne Bereiche isoliert testen.
-
Wesentliche Erkenntnis aus den Konformitätstests ist, daß der VC7.1 in Zukunft ein gutes Tool für den Einsatz von modernen patternbasierten Bibliotheken unter C++ sein wird. Also sich seine Position noch stärker in das sogenannte Backend schieben wird, wo man die Architektur des Gesamtsystems abbildet.
Der Builder häuft dagegen mehr und mehr Fähigkeiten an, die in das Frontend und GUI-nahe fallen.
Sieht für mich danach aus, daß Builder <=> COM <=> VC eine gute Kombination wären, und erfüllt auch gewisse Anforderungen an die Trennung von Visualisierung und Design.