VCL und dynamic_cast

Noch einmal dazu:

DocShoe schrieb:

(das QC Snippet habe ich schon ausprobiert, scheint für das RAD Studio gemacht zu sein. static TObject::GetInterfaceEntry( ...,... ) gibts im BCB6 nicht, der akzeptiert nur die Methode mit einem _GUID Parameter. Nach der Korrektur ist dann der Linker mit einem unresolved external ausgestiegen)

In QC #40084 wird auf #40100 verwiesen, der dieses Problem und die Lösung beschreibt (ggf. die Kommentare lesen).
Nachdem ich den Workaround für #40100 angewendet hatte, akzeptiert auch C++Builder 6 meinen Code ohne weiteres.

Burkhi

DocShoe schrieb:

....
Das Ding taugt nix für professionellen Einsatz. ...

Auch da werde ich mal heftigst widersprechen.

Ich habe 2001 mit dem CB5 eine komplette Anlagensteuerung geschrieben für die Hinterachsenfertigung des Bentley, Phaeton und Passat B5, (komplett mit automatischer Auftragsvergabe, Darstellung von Tabellen auf mehreren Monitoren, Ausdruck auf mehreren Druckern z.T. mit Barcodes, Datenbank auf Oraclebasis) die Anlage läuft heute noch einwandfrei.
Im gleichen Jahr entstand eine Auftragsvergabesoftware (ebenfalls mit CB5) für die Federbein und Schwenklagermontage bei Audi in Ingostadt. Auch heute noch in Betrieb, teilweise werden bis zu 1000 stck/Tag gefertigt.
Im VW Werk laufen seit 2004 mehrere neue Erfassungspunkte 24 Stunden am Tag, 7 Tage die Woche, die SW dafür wurde auch mit dem CB5 geschrieben.

So und nu kommst du. was ist daran unprofessionell?

So, ich hab mir lange überlegt, ob und wie ich antworten soll.
Mag ja sein, dass es Leute gibt, die den BCB besser finden als die MS Produkte, aus welchen Gründen auch immer. Es gibt sicher Vor- und Nachteile beider Produkte, die jeweils für sich oder gegen das Konkurrenzprodukt sprechen. Woran ich meine Meinung festmache sind jedenfalls die Dinge, die ich im täglichen Umgang mit dem BCB6 erlebe. Der Umstieg auf CG2009 steht kurz bevor, aber im Moment müssen wir uns mit jeder Menge Legacy Code und 3rd Party Libraries beschäftigen, die für den CG2009 teilweise nicht mehr existieren bzw. unterstützt werden.
Ich komme nun mal vom MS Compiler und habe jahrelang mit dem VS 6.0 gearbeitet. Die damaligen Aufgabengebiete waren komplett andere als heute, sodass ich mit den Flaws des VS 6 nie in Berührung gekommen bin. Laut Aussagen von Leuten in anderen Foren sind VS 6 und VS 2003 wohl die schlechtesten Compiler Suites, die je entwickelt worden sind. Privat benutze ich das VS 2008 und bin äußerst zufrieden damit.
Meine Aussage über die Untauglichkeit des BCB6 zur professionellen Anwendungsentwicklung stütze ich auf folgende Punkte:
- fehlende IDE/Debugger Stabilität I:
Unser Team besteht aus 6 Entwicklern, bei denen der Builder während des Debuggens mit irgendwelchen seltsamen Fehlermeldungen stehenbleibt und nicht aus dem Debug Lauf zurückkommt. Einzige Lösung ist dann den BCB über den Task Manager zu beenden oder manchmal sogar den Rechner neu zu starten. Manchmal nimmt die IDE dann geöffnete Formulardateien mit und zerstört diese, sodass ein Backup eingespielt werden muss. Passiert selten, ist aber schon mehrmals vorgekommen.
- fehlende IDE/Debugger Stabilität II:
Bei Schleifendurchläufen mit vielen Iterationen verabschiedet sich der Variableninspektor und zeigt einfach nix mehr an. Nicht kritisch, aber äußerst ärgerlich.
- kritische Compiler Fehler bzw. nicht nachvollziehbares Verhalten:
Es gibt zumindest einen Compiler Bug, der micht knapp 2 Tage Arbeit gekostet hat (Codeguru forums. Ich kann mich dran erinnern, dass ich mehrere solcher Probleme hatte, konkret fiel mir allerdings nur dieser eine Fall ein.

- dieses eigenartige Delphi-VCL Framework, dass irgendwie in einen C++ Compiler integriert wird
Manche Dinge nerven einfach nur, weil man die Brücke zwischen Delphi/Pascal und C++ schlagen muss. Anders als bei MS hat man hier keine integrierten Alternativen (MFC/.NET) und muss die Klippen selbst umschiffen (wenn es möglich ist). 3rd party Lösungen wie wxWidgets oder QT mal aussen vor, da sie mit Borland nichts zu tun haben.

Die Aussagen anderer Leute sind für mich weniger konkret als die Probleme, die der BCB tagtäglich bei uns verursacht. In unserem Team haben ALLE diese Probleme, ich bin also kein Einzelfall. Mag ja sein, dass eure Projekte problemlos umsetzbar sind und eure Compiler stabiler laufen, aber aus meiner Sicht ist und bleibt der BCB einfach nur schlecht.

asc

DocShoe schrieb:

Mag ja sein, dass es Leute gibt, die den BCB besser finden als die MS Produkte, aus welchen Gründen auch immer.

Die meisten Probleme die du ansprichst gelten aber für beide Compiler aus ungefähr der gleichen Zeit (Also z.B. Vergleich VC6 zu BCB6). Das was die VCL dem BCB ist, ist die MFC des VC (und ich bin persönlich von beiden nicht sonderlich begeistert; Der VCL merkt man den Delphischwerpunkt an, der MFC das hohe Alter - Beides keine gute Basis).

Und zumindestens damals war der BCB imho trotz VCL näher am Standard als VS (inzwischen nicht mehr, wobei der 2009 wohl wieder eine massive Verbesserung darstellen soll).

Der VC ist imho tatsächlich stabiler, wenn gleich ich den BCB6 nicht kenne (Habe bislang mit 3/4/2007 und der 2009 Trial gearbeitet), soviel ich aber hier mitbekommen habe, war einer der Gründe von BCB6 auf BCB2007 zu wechseln in genau diesen Punkt begründet - kann sein das die 6er Version tatsächlich ein Fehlgriff dargestellt hat.

DocShoe schrieb:

Laut Aussagen von Leuten in anderen Foren sind VS 6 und VS 2003 wohl die schlechtesten Compiler Suites, die je entwickelt worden sind. Privat benutze ich das VS 2008 und bin äußerst zufrieden damit.

Zumindestens für VS6 kann ich das ganze unterschreiben, aber bereits der 2003er war besser. Die Versionen 2005/2008 sind sowohl stabil als auch sehr Standardkonform (unter Windows ist IMHO VS2008 die aktuelle Referenz unter den C++ Compilern). Was VS aber nicht ist: Eine RAD Umgebung. Hier hat MS erst seit den .Net Compiler, sowie VB eine vergleichbare Umsetzung wie der BCB.

cu André

Braunstein

Ich bin schon seit dem BCB1 dabei. Die Stabilität der einzelnen Varianten ist schon sehr unterschiedlich. BCB3 bis 5 waren eigentlich recht stabil (den 5er nutze ich immer noch manchmal) während der BCB6 und der BCB2006 deutlich unstabiler waren.
Erst der BCB2007 läuft wieder recht ordentlich. Er hat zwar auch manchmal Schwierigkeiten (hauptsächlich Suche und Debugger) die sind aber meiner Meinung nach nicht wirklich gravierend.

Burkhi

Ich muss _DocShoe_ im Bezug auf Stabilität recht geben: Aus meiner Erfahrungen (bin ebenfalls wie Braunstein seit CB 1 und Delphi 1 dabei) sind CB6 und BDS2006 sehr instabil und neigen wirklich gerne mal zum Absturz, z.b. ist es mir selten gelungen, das BDS sauber zu beenden, sehr oft gings nur noch über den Taskmanager.

CB2009 ist dagegen sehr stabil, damit hatte ich bisher keine Probleme.

Aber die Aussage, das mit dem CB keine professionelle SW erstellt werden kann, ist schlichtweg falsch.

Braunstein

Kannst du den BCB2007 mit dem 2009er stabilitätsmäßig vergleichen? Ich konnte mich bis jetzt noch nicht dazu durchringen den neuen zu erwerben.
Unicode spielt für mich keine Rolle und die neuen C++Features werde ich aus Kompatibilitätsgründen so schnell nicht einsetzen. Deswegen habe ich jetzt noch keinen Bedarf für ein Update gesehen.

Burkhi

Hi Braunstein,
die 2007er Version besitze ich nicht, deshalb kann ich dir leider keinen "Vergleich anbieten".

Aber die Aussage, das mit dem CB keine professionelle SW erstellt werden kann, ist schlichtweg falsch.

Das habe ich ja auch nie behauptet. Ich bin schon der Meinung, dass man mit dem BCB 6 professionelle Software erstellen kann (schliesslich tut unsere Firma genau das). Ich bin allerdings der Meinung, dass das Produkt BCB 6.0 kein professionelles Werkzeug ist, und zwar aus den Gründen, die ich früher schon angeführt habe.

audacia

Auch hier hat sich die Situation verändert, und zwar bereits in XE. Delphi-Klassen können nach wie vor Interfaces handhaben, allerdings nur solche, die auch von Delphi als Interfaces anerkannt werden - also solche, die von IUnknown / IInterface ableiten. Läßt man das außer acht, so bekommt man eine Warnung:

class IMyIntf
{
    virtual void foo (void) = 0;
};

    // Warnung W8130: Interface 'IMyIntf' ist nicht von IUnknown abgeleitet. (Interfaces müssen von IUnknown abgeleitet sein)
class TInterfacedSomething : public TObject, public IMyIntf
{
};

Außerdem gibt es seit C++Builder XE eine neue Klasse TCppInterfacedObject<> , die einem das erneute Implementieren von QueryInterface() , AddRef() und Release() erspart:

// die IID ist nach wie vor optional
class __declspec (uuid ("{3B6D49E8-712C-4442-9A02-1E37F107516F}")) IMyInterface : public IUnknown
{
public:
    void foo (void) = 0;
};
  // DelphiInterface<> ist ein Smart-Pointer für Delphi-/COM-Interfaces und dient dem Komfort.
  // Das Präfizieren des Typedefs mit "_di_" ist Konvention und wird auch vom .hpp-Generator des Delphi-Compilers so gemacht.
typedef DelphiInterface<IMyInterface> _di_IInterface;

class TMyObject : public TInterfacedObject, public IMyInterface
{
public:
    ULONG   __stdcall AddRef (void)
    { return TInterfacedObject::_AddRef (); }
    ULONG   __stdcall Release (void)
    { return TInterfacedObject::_Release (); }
    HRESULT __stdcall QueryInterface (REFIID iid, void** p)
    { return TInterfacedObject::QueryInterface (iid, p); } 

    void foo (void) { ... }
};

wird also zu

class TMyObject : public TCppInterfacedObject<IMyInterface>
{
public:
    void foo (void) { ... }
};

(Möglich wird das durch das Beheben des in QC #66382 beschriebenen Problems.)

Es ist weiterhin nicht möglich, dynamic_cast<>() mit Interfaces zu benutzen. Die technischen Gründe dafür stehen hier; seit XE gibt es aber als Ersatz dafür den interface_cast<>() , mit dem man nach Belieben zwischen Interfaces und Klassen hin- und hercasten kann:

TMyObject* obj = new TMyObject;

        // implicit upcast to guard interface
    _di_IMyInterface myInterface = obj;

        // explicit object->interface upcast
    _di_IInterface i2 = interface_cast<IInterface> (obj);

        // explicit interface->interface downcast
    _di_IMyInterface i3 = interface_cast<IMyInterface> (i2);

        // explicit interface->object downcast
    TMyObject* obj2 = interface_cast<TMyObject> (i3);

Daß man zu einem bestimmten Interface hin-casten kann, erfordert natürlich, daß diesem Interface mittels __declspec(uuid()) eine IID zugeordnet ist.

Wohlgemerkt ist interface_cast<>() keine Keyword-Erweiterung, sondern ein Funktionstemplate im System-Namespace. Allerdings verweist der Compiler auf interface_cast<> , wenn man versehentlich dynamic_cast<>() verwendet:

// Warnung W8131: Umwandlung des Interface 'IUnknown' in eine Klasse im Delphi-Stil. Verwenden Sie
        // stattdessen 'System::interface_cast<TBar>(intf)'
    TMyObject* obj3 = dynamic_cast<TMyObject*> (i3);

Danke für die nützlichen Infos.

Zu Zeiten der in diesem Thread erwähnten BCB5 und 6, gab es so nützliche Bücher wie den C++ Builder Developers Guide. Da konnte man sowas schön nachlesen.

Wir können dich vermutlich nicht überreden, einen Nachfolger zu verfassen ?

audacia

nn schrieb:

Zu Zeiten der in diesem Thread erwähnten BCB5 und 6, gab es so nützliche Bücher wie den C++ Builder Developers Guide. Da konnte man sowas schön nachlesen.

Ich weiß, daß bei Embarcadero wieder an einem "C++Builder Developers Guide" gearbeitet wird (wobei fraglich ist, ob es das nochmal in Druckform geben wird). Das Buch bestand ja im Wesentlichen aus den in schön lesbare Form gebrachten Inhalten der Online-Hilfe. Die aktuelle Online-Hilfe beinhaltet wieder die meiste Dokumentation, die zwischenzeitlich mal verlorengegangen ist, und auch neuere Themen werden oft gut behandelt. Aber bis es wieder den schlüssigen Zusammenhang des "Developers Guide" hat, muß noch einiges getan werden.

nn schrieb:

Wir können dich vermutlich nicht überreden, einen Nachfolger zu verfassen ?

Haha Nein; ich habe weder einen Job bei Embarcadero noch überflüssige Lebenszeit. Ich könnte aber solche Informationen on-demand (wenn es z.B. hier im Forum angefragt wird) auf meiner Webseite in einem Artikel zusammenzustellen.

audacia schrieb:

Sich darüber zu beschweren, daß ein mittlerweile gute acht Jahre altes Produkt nicht mehr zeitgemäß ist, halte ich, offen gesagt, für albern.

Ich schon. Denn die Features sind ja "drin", sollten also funktionieren. Das taten sie halt schon vor 8 Jahren nicht. Das sie es mittlerweile in späteren Versionen tun ist keine Entschuldigung für das ursprüngliche Produkt.

audacia

Morle schrieb:

Das sie es mittlerweile in späteren Versionen tun ist keine Entschuldigung für das ursprüngliche Produkt.

Stimmt.

Ich denke, ich muß die zitierte Aussage einschränken. Ich war mir nicht darüber im klaren, wie schwer es sein kann, ein Lock-in auf eine ältere Version zu überwinden.

Andererseits wirst du zustimmen, daß es albern wäre, sich über die von Windows 98 verursachten Alltagsbeschwerden zu beklagen, solange man genausogut auf ein modernes Windows migrieren könnte. Darauf wollte ich hinaus.

audacia schrieb:

Andererseits wirst du zustimmen, daß es albern wäre, sich über die von Windows 98 verursachten Alltagsbeschwerden zu beklagen, solange man genausogut auf ein modernes Windows migrieren könnte. Darauf wollte ich hinaus.

Nur das man eben nicht "einfach so" migieren kann. Wir entwickeln mittlerweile mit was anderem. Für unsere Abteilung z.B. wären das mal eben 20 Lizenzen für eine aktuelle Version vom Builder zusätzlich zu unserer eigentlichen IDE. Und das nur um alte Applikationen weiter zu pflegen und sich damit ggf. auch noch Probleme beim Update einzuhandeln? Welcher Chef lässt sich denn auf sowas ein?
Ich hatte mit Dir doch schonmal darüber geredet, glaube ich.

audacia

Morle schrieb:

Und das nur um alte Applikationen weiter zu pflegen und sich damit ggf. auch noch Probleme beim Update einzuhandeln? Welcher Chef lässt sich denn auf sowas ein?

Hängt natürlich stark von der Zukunftsplanung bezüglich dieser alten Anwendungen ab, nicht?

Morle schrieb:

Ich hatte mit Dir doch schonmal darüber geredet, glaube ich.

Ja, wir hatten die Diskussion schon.