Diskussion: Der BCB / BuilderX und die Zukunft von Borland (war:Builder 7 kommt raus)

[epidemic]

Hallo Zusammen,

ich persönlich freue mich auf die künftige Entwicklung mit dem
CBuilderX.
Darauf habe ich ehrlich gesagt schon seit Jahren gewartet!

Endlich wird alles(wenn es wirklich so stimmt was man so liest)
konsistent in einer Sprache gehalten.
Es hat mich eigentlich schon immer am CBuilder gestört, daß hier nicht alles
in einer Sprache gehalten wird und die VCL in Pascal geschrieben sind.

Weiß einer von Euch wie das mit der Unterstützung von STL aussieht?

epidemic

[VolkerH]

Hallo,
der C++BuilderX unterstützt die STL, da es der bisherige bcc32- Compiler ist, auch zwei Varianten. Der Trend geht aber eindeutig zu STLPort.

WxWindows nutzt die STL noch nicht (genauso wie RTTI noch nicht genutzt wird). Die Ursache liegt darin, dass die Konzeption von wxWindows vor der Standardisierung der STL liegt. Aber es gibt eine Liste der nächsten Schritte in der Implementierung, da steht die STL- Unterstützung ganz oben, und die wxWindows- Foundation erhofft sich hier Unterstützung von Borland.

Schöne Grüsse

Volker

[epidemic]

Das Sind ja tolle Neuigkeiten.

Prima, herzlichen Dank für die Infos!

epidemic

[C++Gast]

Hallo Zusammen,

ich habe mit erschrecken die bisherigen Beschreibungen und Kommentare zum C++Builder X gelesen. Wenn es tatsächlich so ist, dass der BuilderX die bisher mit dem C++ Builder geschriebenen Applikationen nicht mehr unterstützt, dann muss man annehmen, dass Borland von allen guten Geistern verlassen wurde.

Es kann doch nicht angehen, dass man mehrere Mann-Jahre in die Entwicklung einer Software steckt und dann auf ein Mal heisst es, wenn du auf die neue Entwicklungsplattform updaten willst, dann muss die Applikation neu geschrieben werden. Dies ist ein Schlag ins Gesicht aller professionellen Softwareentwickler, die auf den C++Builder gesetzt haben.

Die Aussage von Andreas W., dass Borland mit dem BuilderX sehr viele Kunden neu gewinnt mag vielleicht stimmen, allerdings wird Borland einen grossen Teil seiner bestehenden Kunden verlieren.
Denn mit Verlaub, keine VCL-spezifischen Klassen in den Applikationen zu verwenden klingt zwar toll, geht aber an der Realität vorbei. Denn jedes Form, jedes StringGrid usw. ist eine VCL-Klasse und diese zu ersetzen ist bei einem kommerziellen Produkt nicht eben trivial. Es mag vielleicht sein, dass ein "normaler" Dialog recht schnell zusammengebaut ist, aber viele Softwareprodukte bieten dem Anwender besondere Bedienungsfeatures, die einen grossen Programmieraufwand bedeuten. Ganz zu schweigen von dem über die Jahre gesammelten Erfahrungen mit einer Klassenbibliothek, die man nun über Bord werfen soll.

Ein Wechsel auf den BuilderX bedeutet somit für die professionellen Borland-Anwender einen riesigen finanziellen Aufwand, da das Personal neu geschult, Erfahrungen neu gewonnen und nicht zuletzt die Software portiert werden muss. Diese Kosten können meist nicht erwirtschaftet werden, da eine solche Umstellung keinen Mehrwert für den Kunden bringen und dieser zurecht nicht bereit ist für ein solches Update auch noch Geld zu bezahlen.

Mich würde interessieren wie Ihr darüber denkt. Werdet Ihr, sofern Ihr ein kommerzielles Produkt mit dem C++Builder entwickelt habt, auf einen Builder X ohne VCL-Unterstützung updaten?

[KlausB]

Hallo

wenn Borland ein Programm mitliefert, das die Umstellung macht -> Ja
ansonstern macht es keinen Sinn

dann lieber was anderes (Delphi) oder gleich der Umstieg zu MS

[epidemic]

@C++ Gast:

wo liegt das Problem ?
Benutze doch für Deine bestehenden Progs den alten CBilder.

Wenn dann irgendwann mal ein vernünftiges Framework für den CBuilder X
steht, dann kann man sich Gedanken machen.
Sieh doch auch mal positive Aspekte.
Endlich wird alles konsistent in einer Sprache gehalten!

epidemic

[AndreasW]

schwierig wenn man über Komponentenentwicklung sich ein eigenes Framework drauf gesetzt hat. Da ist eine Portierung seitens Borland wohl kaum möglich.

C++Gast hat ansich recht. Man wird zur Zeit richtig verarscht. Aber nciht nur von Borland. Auch MS mischt ja kräftig auf. Das Borland der große Buh-Mann ist wage ich zu bezweifeln. Mit dem Scheiss ist MS angefangen und Borland war dadurch gezwungen etwas ähnliches wie das VisualStudio.NET auf dem Markt zu Schmeissen, damit man sie nicht aus dem Markt gedrängt werden. Das hat dan Borland mit dem BuilderX auch gemacht.

Prizipiell muss man aber in der IT stets mit Änderungen rechen. Ist ja wie jeder weiss ein sowieso so kurzlebig. Allerdings sind mir dieses Geschichten auch ein wendig zu deftig. Zumindst hätte man den BuilderX ankündigen können.

Ich würde vorhandene Anwendungen nicht updaten. Erst wenn Änderungen oder Erweiterungen anstehen würde ich später mal drüber nachdenken. Der BCB ist ja immer noch auf dem Rechner. Eine Umstellung ist deshalb vorerst nicht notwendig. Wer weiss was uns der Markt so noch in den nächsten Monaten vor die Füsse wirft.

Ich werde vorerst auf andere Umgebungen umsteigen da der BuilderX alles andere als Marktreif ist. Schliesslich will ich für Borland nicht den Alpha oder Beta-Tester spielen und eh kein Support erhalten.

[epidemic]

AndreasW schrieb:

Ich werde vorerst auf andere Umgebungen umsteigen da der BuilderX alles andere als Marktreif ist. Schliesslich will ich für Borland nicht den Alpha oder Beta-Tester spielen und eh kein Support erhalten.

Und welche Umgebung käme da in Frage?
Würde mich interessieren.

Ich benutze ab und an auch MVC++ 6.
Hier ist aber seehr viel Handarbeit angesagt!

Und im Bereich Datenbankprogrammierung ein schlechter Scherz im Vergleich zu den VCL Klassen/Kompos.

[dschensky]

C++Gast schrieb:

Werdet Ihr, sofern Ihr ein kommerzielles Produkt mit dem C++Builder entwickelt habt, auf einen Builder X ohne VCL-Unterstützung updaten?

Ohne VCL bedeutet auch ohne die teuer zugekauften bzw. selbst erstellten Komponenten programmieren zu müssen. Wenn ich alle diese Komponenten und den VCL-Code aus meiner aktuellen Anwendung herausnehme, kann ich auch gleich von vorn anfangen. Und da der Kreis meiner End-User momentan sowieso nur Windows verwendet, bleibt praktisch kein Grund zum Updaten.
Abgesehen davon erwartet der CBuilderX Hardware-Voraussetzungen, die über kurz oder lang die Anschaffung neuer Hardware erfordert. Das ist für eine kleine Software-Firma keine Selbstverständlichkeit.

AndreasW schrieb:

Der BCB ist ja immer noch auf dem Rechner. Eine Umstellung ist deshalb vorerst nicht notwendig. Wer weiss was uns der Markt so noch in den nächsten Monaten vor die Füsse wirft.

Wir hatten geplant, die Neu-Entwicklung einer weiteren Anwendung mit dem CBuilder vorzunehmen. Das haben wir komplett gestoppt und sind jetzt zu 99,9% auf .Net und Visual Studio(C#) umgeschwenkt. Das Problem ist, daß wir die Entscheidung jetzt treffen müssen und der ganze Hickhack von Borland ein zu großes Risiko darstellt. Das mißlungene Kylix-Projekt ist in diesem Zusammenhang auch kein besonders gutes Aushängeschild.
Der CBuilder ist eine hervorragende IDE - da sind wir uns wohl alle einig. Aber er wird nicht mehr weiter entwickelt und ich denke, daß die Lebensdauer von GUI-Anwendungen heute viel enger an die IDE gebunden ist. Nur wenn die Weiterentwicklung der IDE die Weiterentwicklung des Betriebssystems reflektiert, kann in meinen Augen auch die Anwendung selbst modern bleiben. Ohne diese stetige Modernisierung läßt sich die Anwendung nicht verkaufen (darum geht es letztlich) und stirbt schneller aus, als es ökonomisch vertretbar ist.

[AndreasW]

naja, siehe auch :

MFC->tot

da wären aln Umgebungen folgende zu nennen:

von Borland:

C#- Builder
JBuilder

von MS:

VisualStudio.net

Sun (and other java-IDEs):

Sun-Studio
NetBeans
Eclipse

ich hab alle getestet und muss sagen, dass alle, ausnahmslos alle, Java- IDEs voll mit Bugs sind, ständig abschwirren, extrem langsam (Eclipse geht noch), schlecht handhabbar sind. Der JBuilder ist vielleicht nicht ganz so übel, hebt sich aber nicht wirklich von der Masse ab. Der C#Builder von Borland ist vergleichbar (IDE nicht Sprache) mit dem JBuilder. Auch kein Knaller, bei dem man sagen könnt:"joh, dooss isses!"

Auch wenn man das aus meinen Mund wohl nicht erwartet hätte, zur Zeit sehe ich nur das VisualStudio.net als ausgereifte IDE. Das Framework ist recht gut und Webentwicklung wird sehr vereinfacht, da C# zum Beipiel dieses ASP.NET integriert. Das Studio vom Microsaft als einzige Alternative,welche bei mir überhaupt ein "Aaahh"- Effekt erzeugen konnte.

Vielleicht bin ich auch zu anspruchsvoll...

Und zum Thema Datenbanken: Da war/ist der BCB ja unschlagbar.
mom, muss eben den Rechner neu starten

[AndreasW]

so, I'm back.

Im VisualStudion mit c# zum Beispiel werden Datenanbindungen gerne mit ADO.NET gemacht. Soweit ich das verstanden habe, arbeitet ADO.NET mit XML-Daten.
Das halte ich persöhnlich für ganz übel.

Beispiel: Ein einfacher Datensatz aus eine Anwendertabelle:

Id	Nachname	Vorname	Straße	Hausnummer	PLZ	Ort	
1	Wigmann	Norbert	Musterstraße	12	40211	Duesseldorf

So, der eine Datensatz umfasst, wenn man ihn in einem Datenstrom in Form einer Klasse oder Struktur versendet genau 44 Byte.

In XML sicht das so aus:

<personen>
   <person>
       	<Id>1</Id>
       	<Nachname>Wigmann</Nachname>
<Vorname>Norbert</Vorname>
	<Straße>Musterstraße</Straße>
	<Hausnummer>12</Hausnummer>
	<PLZ>40211</PLZ>
	<Ort>Duesseldorf</Ort>	
   </person>
</personen>

Nun braucht der selbe Datensatz (ohne die personen-tags) auf einmal 218 Byte.
Das ist knapp das 5fache, was ich für sehr bedenklich halte. Sicherlich kann man so was machen, wenn es vorrangig darum geht, eine Webseite anzuzeigen oder um ein WebService möglichst allgemein zu halten. Aber zu mehr taugt das nicht.

Wenn man einigermaßen Veranwortungsbewust ist, nutzt man sowas nicht.

[dschensky]

AndreasW schrieb:

Soweit ich das verstanden habe, arbeitet ADO.NET mit XML-Daten.

Die Verwendung von XML als "Datenbank" wird unterstützt, ist aber nur eine Möglichkeit. ADO.NET ist (wie etwa die BDE) eine generisches Datenbank-Zugriffs-Modell. Du kannst genauso auf jede andere Datenbank zugreifen, falls der Hersteller die entsprechenden Treiber zur verfügung stellt (OLEDB, ODBC).
Die "große Neuerung" in ADO.NET ist die Verbindungslosigkeit (keine Cursor auf Server-Seite). Das macht das Programmieren schwerer, verbessert aber die Skalierbarkeit.

[VolkerH]

Hallo,
ich denke, in allen Aussagen hier steckt Wahrheit. Die Informationspolitik von Borland ist zur Zeit unter aller Kanone, und wie so oft macht man sich um Delphi und Java mehr Gedanken, als um C++. Wenn man da nicht verunsichert wäre, hätte man als kommerzieller Entwickler einen falschen Beruf gewählt.

Aber Programmieren ist Veränderung und ständige Anpassung. C++ ist eine Sprache, die durch ein Gremium vieler Firmen nach vorne entwickelt wird, dadurch ist es relativ stabil. Deshalb ist C++ die Nummer 1 der Programmiersprachen und wird es auch in den nächsten 5 Jahren bleiben. Nur die VCL und .net werden von einzelnen Entscheidungen beeinflußt. Und wenn .net strategisch auch gut ist, so ist der Weg, den Microsoft dahin wählt, nicht unbedingt richtig.

Der C++ BuilderX ist strategisch ein starkes Produkt. Borland wurde durch die allgemeinen Marktsituationen dazu gezwungen, den Microsoft führt einen riesigen Werberummel um .net, und viele sind wie Lemminge, und laufen diesem Werberummel nach (ich bin ansonsten eher ein Microsoft Fan, und glaube, viele gute Dinge kommen von dort) und mit Delphi hatte man die Chance, den Zuschlag für die .net Lizenz zu bekommen. Und Delphi zielt, wenn es einige auch nicht wahrhaben wollen, immer noch auf das Marktsegment Visual Basic, also mußte man einfach diese Entscheidung treffen. Deshalb wurde die VCL zu einer Ergänzung des .net- Framework (und wie für Borland typisch, zu einer sehr guten). Auf der anderen Seite wird der Linux und Palm(+Handy-) Markt immer größer. Also hätte die weitere VCL- Ausrichtung eine klare Fixierung auf .net nach sich gezogen, was bestimmt keinen Sinn für C++ gegeben hätte.

Wenn ich den letzten offenen Brief im Oktober richtig gelesen habe, wird es auch einen neuen Compiler für die VCL.net - Komponenenten von Borland geben, allerdings dann für das durch Microsoft kreierte "managed" C++, sonst wäre ja nichts mit .net. Vielleicht wird dieser sogar in den BuilderX eingebettet, vielleicht ist es ein Builder7 oder 8, das kann bei der Informationspolitik keiner sagen. Aber auch hier ist Borland eher selber ein Opfer. Wenn Ihr also zukünftig von Einzelentscheidungen befreit sein wollt, dann kann der BuilderX mit wxWindows eine gute Alternative werden.

Auch wir haben viele Mann- Jahre in die Entwicklung professioneller Software mit dem C++ Builder gesteckt. Wenn wir auch immer vorsichtig waren, was die Abhängigkeit zur VCL betraf, es ist eine Illusion, bestehende Projekte zu drehen. Und unter Zeitdruck hat man oft das Unbehagen zurückgedrängt, und die VCL- Klassen dorch direkt benutzt. Und da es für die Kunden erstmal keinen Mehrwert gibt, ist es jetzt auch schwierig, die Umstellung zu finanzieren. Aber man kann jetzt beginnen, einen schleichenden Übergang zu vollziehen, und C++ hat die Sprachmittel, das Framework entsprechend zu kapseln. Und damit kann man mit dem C++Builder 5 oder 6 beginnen, dafür braucht man nicht den neuen BuilderX. Und dann kann man in einigen Monaten in Ruhe und richtig informiert entscheiden. Und wenn es dann schließlich gelingt, den Schritt zum C++BuilderX zu machen, gewinnt man mit den Applikationen sofort neue Kunden im Linux (Unix) und Mac- Bereich, und dann hat man den gewünschten Mehrwert (und wir werden schon häufiger nach Linux und Mac- Fähigkeit gefragt), nicht für den Kunden, aber für die eigene Firma. Und darum geht es doch in der kommerziellen Entwicklung.

Meine Empfehlung ist daher immer noch die gleiche, wie vor einigen Monaten, langsame Migration, Aufbau einer Architektur, um die Oberfläche abzukoppeln und schrittweise (immer wenn Puffer sind oder man sowieso daran arbeitet) alle AnsiString's und VCL- Container durch die C++ Klassen (STL) ersetzen. Auch die Datenbankzugriffe über eine abstrakte Schnittstelle von dem Anwendungskern trennen, damit der wichtige Kern der Anwendung schrittweise nur noch aus C++ besteht, ohne VCL, MFC, wxWindows, .net und welches Framework in der Zukunft noch kommen wird. Und noch etwas, der Test in der C't hat doch gezeigt, wie schlecht diese VCL- Klassen im Zusammenspiel mit C++ sind, wollt Ihr Euch darauf ausruhen? Nachdem ich die STL (die ja zu C++ gehört, es also schon verwunderlich ist, wenn der Autor sie damals als "eine andere Klassenbibliothek" abtat) in das Besipiel eingebaut habe, und die Strings via Referenz übergeben habe (fair muss man ja bleiben) war die Anwendung mit dem C++BuilderX und wxWindows geschrieben, wieder sehr viel schneller als die Referenzergebnisse aus der C't für Java, Delphi und C#. Die Kostruktionszeit war kaum noch meßbar. Es wäre also falsch, gerade in dieser Zeit, einen Wechsel von C++ und auch von Borland in eine andere Richtung, sei es nun JAVA oder C# zu machen. Denn dann ist man eventuell vor zukünftigen Machtentscheidungen zwischen SUN und Microsoft nicht mehr geschützt. Der Weg mit dem C++ Builder X ist also richtig, man muss sich nur richtig darauf vorbereiten und erkennen, dass es ein Weg ist, und noch nicht das Ziel.

Euch allen einen guten Rutsch und ein erfolgreiches Jahr 2004

Schöne Grüße aus Berlin

Volker

[AndreasW]

VolkerH schrieb:

Euch allen einen guten Rutsch und ein erfolgreiches Jahr 2004

jo, von mir auch

[C++Gast]

Hallo Zusammen,

wie ich aus den Äusserungen von einigen schliesse, gibt es doch sehr viele die über die Vorgehensweise von Borland nicht ganz glücklch sind. Ich habe immer noch die Hoffnung, dass Borland dies auch noch bemerkt und vielleicht die Vorgehensweise überdenkt. Ich könnte mir vorstellen, dass man die VCL (auch innerhalb von C++) weiter pflegt und diese als Untermenge zukünftiger Klassenbibliotheken erhält.

Im Übrigen bin ich mir bewusst, dass in der IT-Technik nichts von langem Bestand ist. Allerdings haben wir schon die Schritte von der OWL 1 zur OWL 2 und anschliessend zur VCL vollzogen. Und mir will nicht in den Sinn warum die Bibliotheken von Borland einen kürzeren Lebenszyklus haben, als die mit ihnen erstellten Applikationen. Des Weiteren zeugt es nicht gerade von souveränem Verhalten, wenn Produkte auf z.B. Betriebssysteme ausgerichtet werden, die nur ca. 5% des Softwaremartks ausmachen. Denn dabei werden die restlichen 95% oftmals vor den Kopf gestossen.
Borland sollte endlich mal aufhören zu versuchen jede Nische im Markt besetzen zu wollen. Wenn ein Borland-Guru mal wieder eine neue, revolutionäre Programmiertechnik ersonnen hat, so ist doch die Euphorie bei den Alt-Kunden schnell verflogen, wenn dabei alle Brücken zu bestehenden Projekten abgebaut werden.
Wir könnten es uns nicht erlauben, unseren Kunden ein neues Softwareprodukt zu verkaufen, welches die Projekte der Vorgängerversion nicht mehr bearbeiten kann.

In diesem Sinne, ich wünsche Euch allen ein gesundes und erfolgreiches Jahr 2004.

Gruß Torsten

[VolkerH]

Hallo Torsten,
ich kann Deinen Frust ein ganzes Stück weit verstehen. Aber man muss auch fair sein, denn auch mit dem C++ Builder konnte man die OWL- Programme eine ganze Zeit lang weiterentwickeln und betreuen. Ich denke jeder von uns hat diese Wechsel mitgemacht, es ist wirklich zum k.... Aber trotzdem haben wir gewechselt, weil wir das mehr an Möglichkeiten nutzen wollten. Und die Einfachheit der VCL- Umgebung hat schon etwas fazinierendes gehabt. Und ich gebe Dir auch darin recht, Borland versucht manchmal wirklich auf so vielen Hochzeiten zu tanzen (wie hat Borland selber mal geschrieben, den "Schweizer Weg" zu gehen), aber es ist im Moment wirklich schwer, verherzusagen welche Entwicklung die IT durch die nächsten 5 Jahre nehmen wird. Wie entwickelt sich Linux weiter? Setzt sich .net oder J2EE durch? Das sind doch nur einige der Fragen, auf die, wenn man sich die Vorhersagen der IDC ansieht, auch die Analysten keine Antwort kennen. Wer hätte vor 22 Jahren gedacht, dass Microsoft sich gegen IBM's propitäre Systeme durchsetzt? Erinnern wir uns doch mal an die einst so dominierende Firma "Lotus" mit Notes und 123 Marktführer, auf OS2 gesetzt und verzockt, oder an Novell, absoluter Marktführer im Netzwerkbereich, wieviel Prozent neuer Netzinstallationen werden wohl noch mit Novell ausgeliefert? Es kann also sehr gefährlich sein, wenn man sich zu sehr festlegt und bindet.

Und setzt Borland schon mal Prioritäten, dann nicht unbedingt für C++. Als Kylix damals kam, warteten wir auf den BCB5, der BCB6 kam auch später und nach Delphi 7 kam die .net- Entwicklung für Oktane, Klasse. Da können wir doch eigentlich froh sein, daß die Wege Delphi und C++ sich im CBX trennen, oder?

Und auch das Borland mit dem C++ Builder einen katastrophalen Fehler gemacht hat stimmt. Nr nicht jetzt mit dem CBX, bereits vor einigen Jahren, als sie ein sehr gutes C++ Entwicklungssystem geopfert haben, und den Builder mit der VCL einführten, anstatt konsequent an der C++ Umgebung weiterzuarbeiten. Der C++ Builder ist doch nichts anderes mehr, als ein anderes Frontend für Delphi, wenn die VCL einbezogen ist, funktioniert die RTTI und Mehrfachvererbung nicht. Der Code ist für C++ relativ langsam und der alte Grundsatz Funktionalität / Geschwindigkeit / Oberfläche, der beim Programmeieren galt, ist in vielen Fällen einer oberflächenlastigen Quick and Dirty- Methode gewichen (bitte, keiner soll sich angesprochen fühlen). Wer kennt noch die ClassLib mit der Datumsklasse? Was ist heute TDateTime, doch eher ein Witz. Wenn man Implementierungen mit TList austauscht gegen die STL, werden die Programme plötzlich schneller, weil da echter C++ Code erzeugt wird. Auf der RoadShow habe ich gefragt, wer partielle (virtuelle) Mehrfachvererbung, RTTI mit dynamic_cast oder Templates nutzt, von den insgesamt ca. 80 Teilnehmern nicht einmal 10!!! Wenn man Fremdbibliotheken benutzen möchte, paßt oft das Objektformat nicht, da Borland das von Delphi verwendet (damit die VCL paßt), und es gibt viel mehr C++ Bibliotheken auf dem Markt, als VCL- Gegenstücke, nur haben wir es als BCB- Programmierer nicht mehr gesehen. Jetzt scheint (genaues kann man bei der Informationspolitik von Borland leider nicht sagen) Borland die Entwicklung von der Isolation zurück in die größte Programmiergemeinde zu lenken, und dieser Schritt ist richtig, wenn er uns auch allen viel abverlangen wird. Aber jedem, der keine Templates, keine Typumwandlungen über RTTI und Mehrfachvererbung verwendet, Euch bleibt doch der Weg zu Delphi frei, und Delphi entspricht heute doch eher C++ als Pascal.

Außerdem noch mal, im offenen Brief vom 29.Oktober schreibt doch LeBlanc

Windows C++ Applications. If you are committed to building and deploying C++ applications for the Microsoft Windows platform only, Borland will recommend and encourage developers to build for the .NET framework using Managed C++. Borland is committed to supporting this path by providing a C++ compiler with Managed Extensions and integrating support for VCL for the .NET framework, which should provide an straightforward route for current C++Builder 6 developers using VCL to migrate their applications to the .NET platform with less effort.

Da die BCB- Route in diese isolierte Ecke geführt hat, und Microsoft jetzt die Richtung festegelegt hat (.net + C# oder managed C++) ist das die konsequente Fortsetzung, und damit lässt Borland auch keinen VCL / C++ Entwickler im Stich. Ich persönlich rechne schon im 1. Quartal mit neuen C++ Tools. Und ich denke, der Weg zum CBX, wenn man ihn richtig angeht, ist der zukunftsicherere Weg, und ich denke auch, daß Borland diesen unterstützen wird, zu mindest hat LeBlanc dieses versprochen.

We recognize the importance of your investment in VCL technologies and will provide further details on native VCL support in and migration to C++BuilderX in a follow-up Open Letter within these next few weeks

DbExpress ist ja bereits migriert, ich denke, dass in den nächsten Schritten noch einige VCL - Komponenten migriert werden. Aber man kann nicht von Borland erwarten, die Design- Fehler aller Entwickler zu beachten. Ich denke, da müssen wir selber ran. Und die Antwort ist eigentlich einfach, das Framework vom Anwendungskern trennen, durch Kapselung und abstrakte Schnittstellen, sich mit modernen C++ Eigenschaften (templates, RTTI, partielle Mehrfachvererbung, ...) auseinandersetzen, und die Anwendungen in eine moderne Architektur bringen. Ich denke, genau das erwarten auch unsere Kunden von uns. Und dann ist man von Entscheidungen einzelner, sei es Borland, SUN oder Microsoft, frei.

Ich wünsche Euch allen ein schönes, erfolgreiches, neues Jahr 2004

Volker

[murphy]

hallo,

@volkerh: toll, wie sauoft werden diese c++-features schon wirklich benötigt wenn jeder mal ehrlich ist??? und wegen diesen sachen dieser rückschritt? also ich weiss nicht...

mfg
murphy

[VolkerH]

hallo murphy,
also, Du hast recht, man benötigt diese Eigenschaften nicht unbedingt, sonst würde es ja keine anderen Sprachen, wie Delphi, Basic, JAVA, ... geben ;-). Aber dann kann man auch mit diesen Sprachen entwickeln.

Aber diese Eigenschaften machen eben gerade den Unterschied aus! Warum programmierst Du in C++, wenn Du die Eigenschaften nicht ausnutzen willst, warum nimmst Du die langen Compilier und Linkzeiten in Kauf? Wenn Du diese Eigenschaften konsequent einsetzt, dann wird Deine Anwendungsarchitektur stabiler, Du hast plötzlich extrem weniger Quellcode, die Wiederverwendbarkeit erreicht eine neue Dimension und das Fehlerpotential sinkt. Deine Anwendung wird toleranter gegenüber Veränderungen, und Du kannst größere Probleme lösen. Eben gerade das ist der Unterschied zwischen professioneller Anwendungsentwicklung und der Quick and Dirty- Methode, und gerade hier spielt C++ seine Leistung aus. Also ist es schon vernünftig dafür einen vermeintlichen Rückschritt zu machen. Der BCB war am Ende nicht mehr C++. Wenn es Borland jetzt, wie versprochen, gelingt, die guten Eigenschaften und Möglichkeiten der VCL in eine echte C++ - Entwicklungsumgebung zu migrieren, dann ist das Fortschritt, und wir werden alle davon profitieren.

Schöne Grüße aus Berlin

Volker

[murphy]

hallo,

hallo volkardh, also ich wollte dir ja nicht an den karren fahren, aber ich muss gestehen, ich arbeite eigentlich nur mit c++ weil es den c++builder gibt, in meiner ausbildung (da lerneten wir programmieren mit ms-visual c++ und der gaaaaaanz tollen mfc), war der erste einfühtungssatz unseres dozenten der seit 27 jahren mit dabei ist, das das seltenst sinnvoll eingesetzte feature der sprache c++ mehrfachvererbung ist, und wenn man solchen dinge doch einmal unbedingt benötigen sollte, so wäre es besser diese mit ´den moderneren konzepten der interfaces nachzubilden. naja, wie dem auch sei, ich arbeite seit ca. 5 jahren in der dos/windowsprogrammierung hauptsächlich windows, ich selber habe dieses feature noch nie gebraucht. klar, vielleicht bin ich dazu auch ein viel zu durchschnittlicher programmierer, aber für die dinge die du da angeführt hast, möchte ich auf keinen fall den komfort einer vcl vermissen! das ist es mir einfach nicht wert. für mich heisst der fall ganz klar und eindeutig: nix vcl-mässige klassenbibliothek = kein c++ und an borland: CBuilderX = ohne mich...

mfg
murphy

[VolkerH]

Hallo murphy,
auch ich wollte Dir nicht an den Karren fahren. Entschuldige bitte, wenn Du es so aufgefaßt hast. Ich habe von vielen Leuten zu oft gehört, dass man diese Eigenschaften nicht braucht, und meistens von Leuten, die nicht verstanden haben, worum es eigentlich bei Mehrfachvererbung, templates, RTTI, ... geht. Eigentlich schade, denn das führt dazu, dass viele sich nicht damit beschäftigen. Und ich schließe mich dabei nicht aus.

Meine ersten konstruktive Begegnung mit templates hatte ich in einem sehr datenintensiven Projekt, ein Zusatztool auf einer Finanzbuchhaltung. Eigentlich war der Termin nicht mehr zu halten, ich mußte in drei Tagen ca. 15.000 Quelltextzeilen schaffen, und dann auch noch alles sinnvoll einbinden. Dann habe ich aus der Not heraus, weil ich keinen Quelltext mehr sehen konnte, templates eingesetzt, aus den 15.000 Quelltextzeilen sind 2.500 geworden, und ich habe den Termin geschafft. Außerdem hatte ich in diesen Tagen sogar noch etwas gelernt. Vorher habe ich auch gesagt, templates, wozu?

Mit der virtuellen Vererbung das gleiche. Am 4. April 1999 habe ich in einem Workshop in einem größeren Programmierprojekt, in dem ich verantwortlich war, gesagt, dass partielle Mehrfachvererbng nett ist, aber man es nicht braucht (ich hatte es mir bis dato garnicht angesehen, da ich glaubte, man brauche es nicht). Es waren damals 7 Projektmitarbeiter, die mir dieses natürlich auch glaubten. Nur 4 Tage später kam es zu Problemen im Modell, das Konzept war gut, nur lies es sich nicht umsetzen. Einen ganzen Tagen berieten wir, ohne Erfolg. Nachts im Auto, auf dem Weg nach hause, hatte ich plötzlich die Idee, vielleicht könne es ja mit der partiellen Vererbung zu lösen sein? Ich nahm mir ein Buch und arbeitete die Nacht durch. Ich las, probierte Sachen aus und am nächsten Morgen trommelte ich das Team zusammen und stellte am Flipchart das neue / alte Modell vor. Es hatte funktioniert, es wurde im laufe der Wochen verfeinert, aber es blieb bis zum Schluß stabil. Wir hätten es ohne die partielle Vererbung nie geschafft, ein Lebenversicherungssystem mit 6 unerfahrenen und 2 erfahrenen Programmieren in 6 Monaten aus dem Boden zu stampfen, wenn wir uns dieser Mittel nicht bedient hätten.

Warum die Geschichten, passen sie überhaupt noch zum BuilderX? Ich denke ja, denn man muss sich ständig nach vorne bewegen und mit neuem beschäftigen, und wenn man in ein Sackgasse läuft auch den Mut haben, wieder zurück zu gehen. Und jedem, der C++ programmiert, kann ich nur raten, beschäftigt Euch mit diesen Spracheigenschaften, weil es sich wirklich lohnt. Und ich denke, aus meiner Erfahrung in Seminaren und RoadShows, die meisten C++ Entwickler haben noch eine Menge Freiraum, neue Dinge zu lernen.

Schöne Grüße aus Berlin

Volker