borland c++builder 5.0, 18 jahre alt
-
Habe ich vom Flohmarkt erworben. Eine CD, 5 Eur.
Die Oberfläche erinnert an visual BASIC, das C++ steckt unter der Haube. Vom ersten Eindruck sehr ansprechend.Frage1: kann man damit auch Programme für DOS und Win16 und Win32-Textmodus erstellen?
FRage2: hat cpp builder heute noch irgendeine Relevanz?Danke im Voraus ...
-
Hi,
ich arbeite teilweise selber mit dem BCB 6, also eine Version später. Man kann damit Win32 und DOS-Programme erstellen. 16 Bit weiß ich nicht, habe ich nie versucht.
Relevanz: Wenn man eine recht durchdachte IDE nutzen möchte, jedoch kein .NET, ist der BCB in meinen Augen genau das Richtige. Meine Programme, die ich damit erstelle, funktionieren bestens auch unter Windows Server 2016 oder Windows 10, sowie aber auch unter Windows 2000 oder gar NT 4.0.
Die meisten Windows-Programme bauen heutzutage allerdings auf .NET auf, also z. B. mit Microsoft Visual Studio geschrieben. Dafür sind sie weniger kompatibel für ältere Windows-Systeme.
Also die Relevanz ergibt sich durch das Einsatzgebiet. Breitgefächerte Windows-Plattformen oder selbst WINE unter Linux können die mit dem BCB kompilierten Programme gut interpretieren. Deshalb nutze ich den BCB 6 nach wie vor.
Viele Grüße und viel Spaß damit
Nico
-
-
Ja, kann er. Das kannste auch selbst einfach ausprobieren, guck dir doch einfach die verschiedenen Projekttypen an. Ansonsten hier der Wikipedia Artikel
-
Was heisst Relevanz? Ich denke, der Marktanteil für C++ Entwicklung ist ziemlich klein, bei Delphi sieht´s anders aus. Ich würde heute auch niemandem empfehlen, mit dem RAD Studio C++ zu entwickeln:
- die Vollversion gibt es als Trial-Version, die nur 30 Tage kostenlos benutzt werden kann, danach wird sie unbenutzbar.
- die Free-Version ist stark eingeschränkt (zB. kein Debugger, das allein ist ein KO-Kriterium)
- teures Lizenzmodell und restriktive Updates. Für Privatkunden und/oder Hobbyprogrammierer einfach zu teuer (Vollversion ca. €3100, jährliche Subscription ca. €680). Zweimal jährlich erscheint ein Release, das Bugfixes enthält. Ohne Subscription bekommt man keine Updates mehr, selbst wenn der Compiler groben Bockmist baut (der Codegenerator hatte in 10.1 und 10.2 noch grobe Schnitzer)
- Versionssprünge führen zu Inkompatibilitäten mit 3rd Party Libraries. Jedes Release bekommt eine neue Versionsnummer und oft ändert sich iwas am Delphi Binärformat. Die mitgelieferten Bibliotheken sind alle in Delphi geschrieben und die Brücke von Delphi nach C++ bringt einige Einschränkungen mit sich. Patches, die Bugs beheben und die Major-Versionsnummer nicht verändern sind mir seit 2007 nicht mehr untergekommen. Das führt dazu, dass bereits gekaufte 3rd Party Libraries nicht mit der neuen Version funktionieren und für die 3rd Party entweder ebenfalls eine Subscription benötigt wird oder neu gekauft werden muss.
Mein Fazit:
Finger weg vom RAD Studio!
Das Microsoft Visual Studio Express ist für Privatanwender kostenlos und darf eingeschränkt kommerziell benutzt werden. Wenn man frisch anfängt zu programmieren und keine Altlasten pflegen muss ist das mMn das Tool der Wahl.
-
-
DocShoe schrieb:
Das Microsoft Visual Studio Express ist für Privatanwender kostenlos und darf eingeschränkt kommerziell benutzt werden.
So eingeschränkt finde ich es für kommerzielle Nutzung nicht. Wenn sich die Lizenz nicht geändert hätte würde es sogar noch für unsere Firma ausreichen, da wir weder 250+ PCs noch 1 Million USD Jahresumsatz haben (und das wird auf absehbare Zeit auch so bleiben).
-
Ich sag ja nur, dass es eine Einschränkung gibt. Inwiefern die jetzt für den geplanten Einsatz wichtig ist muss halt jeder selbst entscheiden.
-
DocShoe schrieb:
-
Ja, kann er. Das kannste auch selbst einfach ausprobieren, guck dir doch einfach die verschiedenen Projekttypen an. Ansonsten hier der Wikipedia Artikel
-
Was heisst Relevanz? Ich denke, der Marktanteil für C++ Entwicklung ist ziemlich klein, bei Delphi sieht´s anders aus. Ich würde heute auch niemandem empfehlen, mit dem RAD Studio C++ zu entwickeln:
- die Vollversion gibt es als Trial-Version, die nur 30 Tage kostenlos benutzt werden kann, danach wird sie unbenutzbar.
- die Free-Version ist stark eingeschränkt (zB. kein Debugger, das allein ist ein KO-Kriterium)
- teures Lizenzmodell und restriktive Updates. Für Privatkunden und/oder Hobbyprogrammierer einfach zu teuer (Vollversion ca. €3100, jährliche Subscription ca. €680). Zweimal jährlich erscheint ein Release, das Bugfixes enthält. Ohne Subscription bekommt man keine Updates mehr, selbst wenn der Compiler groben Bockmist baut (der Codegenerator hatte in 10.1 und 10.2 noch grobe Schnitzer)
- Versionssprünge führen zu Inkompatibilitäten mit 3rd Party Libraries. Jedes Release bekommt eine neue Versionsnummer und oft ändert sich iwas am Delphi Binärformat. Die mitgelieferten Bibliotheken sind alle in Delphi geschrieben und die Brücke von Delphi nach C++ bringt einige Einschränkungen mit sich. Patches, die Bugs beheben und die Major-Versionsnummer nicht verändern sind mir seit 2007 nicht mehr untergekommen. Das führt dazu, dass bereits gekaufte 3rd Party Libraries nicht mit der neuen Version funktionieren und für die 3rd Party entweder ebenfalls eine Subscription benötigt wird oder neu gekauft werden muss.
Mein Fazit:
Finger weg vom RAD Studio!
Das Microsoft Visual Studio Express ist für Privatanwender kostenlos und darf eingeschränkt kommerziell benutzt werden. Wenn man frisch anfängt zu programmieren und keine Altlasten pflegen muss ist das mMn das Tool der Wahl.Danke für die Info.
Ich habe wohl die kommerzielle, teure Vollversion.
Auf der CD steht "Borland C++ Builder Enterprise Suite". Ein Datenbanksystem (Interbase) und eine Versionskontrolle (TeamSource) sind auch dabei.
Debugger ist dabei und bei der Installation musste ich auch einen Lizenzschlüssel eingeben. Seltsam dass die CD so billig war, wenn das Produkt mal hunderte von Euros gekostet hat.Die IDE (RAD studio?) finde ich super.
Was ich noch nicht gefunden habe: wie man WinAPI direkt aufrufen kann.
Auch kein WinAPI-Helpfile.
Und diese bekannte Custom-Control-Library (mit dem grünen Häkchen am Button), die bei Delphi und Turbo-C++ dabei ist, scheint auch nicht da zu sein.Auf .NET kann ich verzichten. Ist eh nur ein Java-Plagiat
-
-
Die WinAPI-Funktionen sind mit inbegriffen. ShellExecuteEx usw. kann man nativ aufrufen.
-
- Versionskontrollsysteme gibt´s inzwischen wie Sand am Meer. Team Source Control scheint inzwischen ausgestorben zu sein, wenn du ein VCS einsetzen möchtest dann nimm was Modernes (zB. git, Mercurial oder Bazaar).
- die WinAPI Hilfe kann man als MSDN Helpfile direkt von Microsoft herunterladen. Such mal nach MSDN Library.
Dass die CD so billig war ist nicht wirklich erstaunlich. Immerhin ist das Produkt 18 Jahre alt. Ich würde meine Hand nicht für die Standardkonformität des Compilers in´s Feuer legen. 1998 wurde die für C++ essenzielle STL standardisiert, und ich glaube nicht, dass BCB 5 die 100%ig umsetzt. Allein das ist schon ein Grund dafür, lieber doch eine moderne Suite zu benutzen.
-
RetroGuy schrieb:
Ich habe wohl die kommerzielle, teure Vollversion... Seltsam dass die CD so billig war, wenn das Produkt mal hunderte von Euros gekostet hat.
Du meinst du hast die damals, vor 18 Jahren, teure Vollversion gekauft. Teuer und Teuer sind 2 Paar Schuhe und gerade in der IT können schon wenige Jahre einen großen Unterschied machen. Auch sind seit damals sehr viele Firmen von der Software abgesprungen, das merkt man schon am rapiden Sterben der Komponentenhersteller, ebenso an den Kommentaren der noch existierenden (wie Devexpress: Bei einem Wunsch haben die fast wortwörtlich geschrieben das dieser mit Sicherheit nicht mehr umgesetzt wird, da es einerseits ein nicht geringen Umbau erfordern würde, anderseits die Lizenzeinnahmen für die Delphi-Komponenten für solche Änderungen zu gering [im Vergleich zu den .Net Komponenten] sind).
Selbst für 5€ hätte ich diese CD wohl nicht mehr gekauft (oder nur "just for fun"). Zudem rate ich von Interbase und TeamSource zu heutigen Zeiten ab. Debugger wiederum ist nichts was man bei einer Entwicklungsumgebung extra erwähnen muss, und gerade der könnte dir auf aktuellen Windowsversionen einige Probleme bereiten.
RetroGuy schrieb:
Die IDE (RAD studio?) finde ich super.
Ich war selbst (bis eben zu der BCB 5.0-Zeit) ein Fan von dem BCB, inzwischen weiß ich warum ich den C++ Builder (selbst mit einer aktuellen Version, wie ich diesen noch beruflich nutzen muss) ablehne. Und keiner in unseren Team (selbst unser Chef, der lange den C++ Builder in Schutz genommen hat) will ihn noch nutzen - wir sind aber dazu derzeit noch gezwungen. Altcode lässt sich nicht einfach umstellen, gerade nicht wenn alle Entwicklerkapazitäten noch fleißig an der Umsetzung von Kundenwünschen gebunden sind. Aber wenn du davon so begeistert bist: wir suchen demnächst einen weiteren Entwickler, der a) meine Arbeit nach und nach übernimmt* und b) uns entlastet.
* Ich bin "nur" noch bis Anfang 2021 "sicher" hier (darüber hinaus gebe ich keine Zusage), wobei wir ohnehin mehr Entwickler brauchen. Mein Kollege hat selbst gesagt das er mich NICHT ersetzen kann.
RetroGuy schrieb:
Und diese bekannte Custom-Control-Library (mit dem grünen Häkchen am Button), die bei Delphi und Turbo-C++ dabei ist, scheint auch nicht da zu sein.
Du kannst Glück haben: einige Altbibliotheken, die schon seit Ano Dazumal nicht mehr gewartet werden laufen noch auf dem BCB 5, nicht aber mehr auf aktuellen Plattformen (aktuelle Komponenten wirst du aber nicht mehr unter den BCB5 zum laufen bekommen).
RetroGuy schrieb:
Auf .NET kann ich verzichten. Ist eh nur ein Java-Plagiat
Wer keine Ahnung hat und meint mit einem BCB5 glücklich zu werden...
Es wurde ursprünglich mal mit dieser Intension gestartet, doch .NET und Java sind trotz Ähnlichkeiten durchaus sehr unterschiedlich (und das nicht erst seit kurzem).
-
DocShoe schrieb:
Ich würde meine Hand nicht für die Standardkonformität des Compilers in´s Feuer legen. 1998 wurde die für C++ essenzielle STL standardisiert, und ich glaube nicht, dass BCB 5 die 100%ig umsetzt.
Das tun nicht einmal die aktuellen C++ Builder, wenn man, wie wir, noch auf den "classic"-Compiler festgelegt ist. Eine Portierung habe ich einmal versucht, aber selbst die erste compilierbare Version (noch nicht lauffähig) hat alleine die Compilezeiten weit mehr als verdreifacht (glaube der letzte Stand war 3 Minuten gegenüber mehr als 15 [und da habe ich den Compiler abgeschossen und das Projekt vorläufig beerdigt]).
-
Ja, das war bei uns ähnlich und hat für eine mittelschwere Krise gesorgt
Ich habe ein Projekt, das mit dem clang out of the box knapp 4 Stunden zum Übersetzen braucht. Andererseits ist der klassische Compiler dabei immer wieder mit Internal Compiler Error ausgestiegen, da hatten wir die Wahl zwischen Pest und Cholera. Die Lösung hat dann TwineCompile auf einem 8+8 Core PC gebracht, damit bin ich jetzt bei ca. 30 Minuten Übersetzungszeit für das komplette Projekt. Der klassische Compiler hat dafür 45 Minuten gebraucht.
-
DocShoe schrieb:
Ja, das war bei uns ähnlich und hat für eine mittelschwere Krise gesorgt
Ich habe ein Projekt, das mit dem clang out of the box knapp 4 Stunden zum Übersetzen braucht. Andererseits ist der klassische Compiler dabei immer wieder mit Internal Compiler Error ausgestiegen, da hatten wir die Wahl zwischen Pest und Cholera. Die Lösung hat dann TwineCompile auf einem 8+8 Core PC gebracht, damit bin ich jetzt bei ca. 30 Minuten Übersetzungszeit für das komplette Projekt. Der klassische Compiler hat dafür 45 Minuten gebraucht.Wir arbeiten auch mit dem TwineCompile, auf einen ähnlichen PC (Dual Xeon E5-2665; 8+8 Kerne [32 Threads], demnächst wohl Dual-Xeon mit jeweils 10+ Kernen). Der Versuch ist eine Weile her, damals war der Classic Compiler mit TC dennoch weit schneller fertig (nur der Linker braucht ewig im Vergleich). Aktuell sind wir bei etwa 5 min compilierung, und brauchen gefühlt fast genauso lange fürs linken.
-
asc schrieb:
Ich war selbst (bis eben zu der BCB 5.0-Zeit) ein Fan von dem BCB, inzwischen weiß ich warum ich den C++ Builder (selbst mit einer aktuellen Version, wie ich diesen noch beruflich nutzen muss) ablehne. Und keiner in unseren Team (selbst unser Chef, der lange den C++ Builder in Schutz genommen hat) will ihn noch nutzen - wir sind aber dazu derzeit noch gezwungen. Altcode lässt sich nicht einfach umstellen, gerade nicht wenn alle Entwicklerkapazitäten noch fleißig an der Umsetzung von Kundenwünschen gebunden sind. Aber wenn du davon so begeistert bist: wir suchen demnächst einen weiteren Entwickler, der a) meine Arbeit nach und nach übernimmt* und b) uns entlastet.
Ich bin nur Hobby-Programmierer. Ich sehe Programmieren eher als künstlerische Tätigkeit an. Wenn ich programmieren müsste um Geld zu verdienen, fände ich das schrecklich.
Mir ist klar, dass der alte BCB kein aktuelles C++ und STL kann. Aber das ist mir nicht so wichtig. Wenn ich das will, nehme ich irgendwas GCC-basiertes.
Den BCB nehme ich, um auf die Schnelle kleinere Windows-Tools zusammenzuklicken. Ich habe viel selbst geschriebene Programme für den Textmodus, die werde ich mit dem BCB erstmal auf Klicki-Bunti aufpeppen.
asc schrieb:
Wer keine Ahnung hat und meint mit einem BCB5 glücklich zu werden...
Es wurde ursprünglich mal mit dieser Intension gestartet, doch .NET und Java sind trotz Ähnlichkeiten durchaus sehr unterschiedlich (und das nicht erst seit kurzem).Ich bin da sehr eigen. Ich mag Programme, die nur aus einer EXE bestehen und die man von überall starten kann, ohne irgendwas installieren zu müssen. Sowas furchtbar Träges wie NET und Java, mit virtuellen Maschinen und riesigen Librarys, beleidigt mein ästhetisches Empfinden und meinen Hang zum Minimalismus.
Du siehst, als Berufsprogrammierer bin schon deshalb denkbar ungeeignet. :p
-
DocShoe schrieb:
Ja, das war bei uns ähnlich und hat für eine mittelschwere Krise gesorgt
Ich habe ein Projekt, das mit dem clang out of the box knapp 4 Stunden zum Übersetzen braucht.Was ist denn das für ein riesiges Programm? Lässt sich das nicht modularisieren, so dass man nicht immer alles neu bauen muss?
-
Ja natürlich ist das modularisiert
Aber vor einem Release macht man schon mal ein Build-All.Und da kommen wir zu den Macken des Builders: Er erkennt nicht immer, welche Subprojekte up-to-date sind, daher muss man schon mal wieder ein Build All machen.
-
Schau dir mal CMake an. Das ist ein Build-System für große Projekte. Ich persönlich habe es noch nicht benutzt, aber dem Hörensagen nach soll es ganz gut sein. https://cmake.org/
-
RetroGuy schrieb:
Ich bin da sehr eigen. Ich mag Programme, die nur aus einer EXE bestehen und die man von überall starten kann, ohne irgendwas installieren zu müssen. Sowas furchtbar Träges wie NET und Java, mit virtuellen Maschinen und riesigen Librarys, beleidigt mein ästhetisches Empfinden und meinen Hang zum Minimalismus.
Zunächst zur "nur eine exe"-Mentalität:
Diese Mentalität ist ein Grund für viele Probleme die wir hier haben. Zumal wir dies inzwischen ohnehin aufgeben mussten, das statische linken aller nötigen Komponenten macht der Linker nicht mehr mit.Wäre das Projekt rechtzeitig in Bibliotheken aufgeteilt wurden, wäre vermutlich sowohl die Schichtentrennung als auch die Compilezeiten für einzelne Bereiche besser (man ändert meist nur an wenigen, begrenzten Stellen; Wenn die Compilezeit reicht um sich gemütlich einen Kaffee zu kochen, lenkt dies bloss ab).
Doch nachträglich das Projekt zu modularisieren, ist vielleicht zuviel aufwand, wenn man weiß, das man eh die Plattform wechseln muss. Den vorhandenen Code können wir ohnehin zumeist nicht verwenden, auch wenn mein Chef dies nicht einsehen will (trotz anderer Meinung der Entwickler). Ganz zu schweigen das einige grundlegende Basiskonzepte auf dem Prüfstand für eine Neuumsetzung ständen, dies also auch von logischen Aspekten nur eingeschränkt klappen könnte.
Zur Trägheit:
Ich habe inzwischen viele .Net- und zumindest einige Java-Programme erlebt. Dabei habe ich eins festgestellt: Bei größeren Geschäftsanwendungen macht es, bei guter Programmierung, kaum einen nennenswerten Unterschied ob man nativ oder mit Java oder .Net entwickelt. Anders mag es bei Anwendungen die sehr Rechen- oder Grafikintensiv sind aussehen. Aber eine "typische" Businessanwendung kann man auch in Java oder .Net so schreiben, das sie nicht träge erscheint.Zu VM:
Die Konzepte haben sich selbst bei Java inzwischen geändert. Auch Java arbeitet im Grundsatz inzwischen mit einem JIT (JIT: Just in Time Compiler, es wird bei der ersten verwendung compiliert, anschließend das nativ compilierte verwendet; was .Net wohl seit Anfang macht).Rein von der Theorie her, kann ein JIT sogar schnelleren Code produzieren als ein nativer Compiler - da er den Code auf die konkrete Plattform kompilieren kann (bei einem nativen Compiler macht man das nur im seltenen Fall, normalerweise soll ein Programm ja ab einer bestimmten Rechnergeneration laufen). Das ist einer der Gründe (von mehreren) warum die "Trägheit" vor allem beim ersten Aufruf einer Programmfunktion merkbar ist. In der Praxis ist ein JIT aber nur dann auch im Endeffekt schneller, wenn die Compilezeit des JIT, zusammen mit der Anzahl der Aufrufe, durch den optimierteren Code tatsächlich eine Beschleunigung erzielt.
Native Compilierbarkeit:
Man kann übrigens schon seit vielen Jahren auch Java und .Net-Anwendungen nativ compilieren. Das hat aber gewisse Einschränkungen und sollte immer abgewägt werden. Es wird bei .Net Core gefühlt auch häufiger genutzt als noch bei klassischen .Net, auf gewissen Zielplattformen (z.B. über Xamarin auf iOS und Android) ist es schon Standard, da diese nur nativen Code erlauben oder es sich als praktikabler erwiesen hat.
-
asc schrieb:
Zunächst zur "nur eine exe"-Mentalität:
Diese Mentalität ist ein Grund für viele Probleme die wir hier haben. Zumal wir dies inzwischen ohnehin aufgeben mussten, das statische linken aller nötigen Komponenten macht der Linker nicht mehr mit.Wäre das Projekt rechtzeitig in Bibliotheken aufgeteilt wurden, wäre vermutlich sowohl die Schichtentrennung als auch die Compilezeiten für einzelne Bereiche besser (man ändert meist nur an wenigen, begrenzten Stellen; Wenn die Compilezeit reicht um sich gemütlich einen Kaffee zu kochen, lenkt dies bloss ab).
Doch nachträglich das Projekt zu modularisieren, ist vielleicht zuviel aufwand, wenn man weiß, das man eh die Plattform wechseln muss. Den vorhandenen Code können wir ohnehin zumeist nicht verwenden, auch wenn mein Chef dies nicht einsehen will (trotz anderer Meinung der Entwickler). Ganz zu schweigen das einige grundlegende Basiskonzepte auf dem Prüfstand für eine Neuumsetzung ständen, dies also auch von logischen Aspekten nur eingeschränkt klappen könnte.
Ich hab´ da grade ein Deja Vue
-
DocShoe schrieb:
Ich hab´ da grade ein Deja Vue
Prima, jemanden mit Vorerfahrung könnten wir brauchen *duckundweg*... ;p
-
Was zahlt ihr denn?
-
Hi,
Borlands C++-Compiler waren mal sehr gut, als sie noch Turbo C++ hießen.
Damals waren sie absolut Spitze und auch noch sehr gut bezahlbar.
Ich kann mich noch an die anderen Compiler erinnern, wie die gerödelt haben, und ehe bei denen der Präprozessor durch war war Turbo-C++ bereits fertig.Dazwischen hab ich dann einiges mit Delphi 1 und Delphi 3 gemacht, und als dann der C++Builder 1 raus kam war ich richtig happy. Nur die Begeisterung hielt nicht allzu lange. Die 1er Version war noch recht eingeschränkt, aber vermutlich damals ein Schritt in die richtige Richtung. Dann kam aber C++Builder 4 und der hat mich eigentlich davon weggebracht. Völlig unnachvollziehbare Komplettabstürze bei zum Teil an sich fehlerfreiem Code (lief in späteren Versionen)...
Die VCL war an sich eine feine Sache, aber sie war eben in Delphi (Pascal).
Irgendwie gibts da gewisse Klemmstellen zwischen den beiden Sprachen. Bestimmte Sachen, wie Mengen als Parameter an eine Funktion übergeben was in Delphi durch einfaches in ecklige Klammern setzen geht erfordern da umständliche Konstrukte.
Zwischen Delphi und C++ gibt es unterschiedliche Programmierparadigmen, unterschiedliche Aufrufkonventionen... Irgendwie ist das ein bisschen so, als ob man mit überkreuzten Händen Auto fährt.Das ganze Programm ist auch von der Sache her immer noch kein normales C++-Programm, sondern ein Pascal-Programm bei dem aber die eigentliche Arbeit von C++-Quelltexten realisiert wird.
Wer damit leben kann, der wird damit sicher recht gut klar kommen. Aber ich sehe es als etwas ne Querele an, dass der C++-Builder keine eigene von Grund auf C++-Basis hat.
Ein großes Plus ist eindeutig die reich bestückte Komponentenpalette, und vor allem, dass man die so elegant und einfach problemlos durch eigene oder abgeleitete Komponenten erweitern kann. Wobei, komplett eigene sind da nicht ganz empfehlenswert, man sollte sie immer wenigstens von TOBject oder TComponent ableiten, damit sie natlos in die Komponentenpalette und die Abarbeitung der VCL integriert werden können.
Wenn man eigene Komponenten erstellen will, tut man auf jeden Fall gut daran, dieses in Delphi zu tun. Da ist das ganze wie aus einem Guß und man kann sie auch genau so gut unter C++ verwenden.
Klar kann man eigene Komponenten auch mit C++ erstellen, aber das ist ein bisschen, als ob man einen Automotor aus Teilen eines Benziners und Teilen eines Diesels zusammenbaut. Irgendwo knarzt es.Was auch ein großer Vorteil gegenüber z.B. Java ist, ist dass alles was mit der VCL zusammenhängt nicht mit Quelltext gemacht werden muss, sondern sich in einer von Delphi bzw. dem C++-Builder selbst erzeugten dfm-Datei befindet. Man klickt sich die einzelnen Teile zusammen, parametrisiert sie in den Eigenschaftseditoren und braucht dann nur noch für die eigentliche Arbeit Quelltext. Das vereinfacht vieles etwas.
Wo es in C++Builder problematisch werden könnte ist die Verwendung von Design Patterns. Das zu verwendende Pattern ist im Prinzip die VCL.
Man hat zum einen die ganze Oberfläche, die ein VCL-Gebäude ist, und zum anderen die Datenbankschnittstelle, die auch Teil der VCL ist. Die beiden sind sich eigentlich schon von vornherein einig, wie sie miteinander reden wollen und mögen da keinen der ihnen dazwischen Quatscht. Auf der einen Seite gibts die diversen DataSets, die praktisch den Zugriff auf die Daten repräsentieren und auf der anderen Seite die datensensitiven VCL-Objekte (Gitter, Eingabefelder...) und dazwischen gibts als Mittler die DataSources. Man kann es in verschiedenen Quelltextdateien unterbringen, oder bei kleineren auch in einer gemeinsamen, aber diese Grundstruktur wird immer bleiben.Irgendwo klemmt es daran, dass Borland (und Nachfolger - aktuell wohl IDERA) nicht so viel Ressourcen haben um beide Strecken völlig parallel zu entwickeln. Und sie haben sich auch zum Teil verzettelt. Da war zwischendurch Power-Basic, Turbo-Assembler, J-Builder, Java-Builder... und noch diverse Hunde aus verschiedenen Körben dabei.
Wenn einem das Konzept der VCL gefällt (und es hat auf jeden Fall auch ne Menge für sich), dann ist es das beste, wenn man sich von C++ trennt und mit Delphi arbeitet. Dann ist alles aus einem Guss und alles passt perfekt zusammen. Manches ist nicht ganz so elegant wie mit C++, anderes einfacher. Und Delphi hält wesentlich weniger Fallstricke bereit als C++. Wärend man bei C++ noch an der Konzeption arbeitet, ist man bei Delpnhi schon beim Problauf. Vor allem sind auch die Compilierzeiten um Welten geringer, vergleichbar mit den alten Turbo-Sprachen.
Lediglich bei sehr großen Projekten ist Delphi nicht erste Wahl, weil einfach die Abstraktionsmöglichkeiten bei C++ größer und leistungsfähiger sind.Was man bei den ganzen Borland-Nachfolgern auf jeden Fall positiv heruasheben muss ist die sehr bereitwillige Hilfe durch Matthias Eissing, den man bei Problemen jeder Art direkt kontaktieren kann und wo man sehr kompetente hilfe bekommt.
Gruß Mümmel
