4. VCL und dynamic_cast

VCL und dynamic_cast

  • A

    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é

    0
  • B

    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.

    0

  • 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. 👎

    0
  • B

    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.

    0

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

    0
  • ?

    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.

    0
  • A

    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);
    0
  • ?

    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 ? 😕 🙂

    0
  • A

    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.

    0
  • ?

    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.

    0
  • A

    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.

    0
  • ?

    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.

    0
  • A

    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.

    0
Anmelden zum Antworten