3. virtual inheritance == binär kompatibel?

virtual inheritance == binär kompatibel?

  • C

    Moin 🙂
    Kann mir einer von euch C++ genies sagen ob irgendwo im standard festgelegt ist, was bei virtual inheritance passieren soll (konnte leider nichts finden)?
    Es geht mir hauptsächlich um die frage: wir jeder compiler den selben code erzeuge?
    Ich möchte virtual inheritance in nem interface verwenden und da muss es halt 100%ig sicher sein, dass der compiler der appliktion den selben code (vtables, subobjects ect.) wie der der comiler der dll erzeugt.

    0
  • J

    Da vtables afaik schon nicht standardisiert sind (es ist nichtmal vorgeschrieben, daß das überaupt mit vtables implementiert wird), wirste da keine Chancen haben.

    0
  • R

    glaub mal, da wirst schon an den symbolnamen scheitern 🙂 weil schon das nicht standardisiert ist ...

    Weiss nich wie es unter Unix/Linux ist ... (kann man da programme ueberhaupt teilweisse mit anderen kompilern bauen ? wenn das system auf gcc basiert, hab ich dann mit dem intel ueberhaupt noch die moeglichkeit, nen binary zu erstellen ? wie siehts da mit Shared objects aus ? )

    aber windows ist ne Faustregel, die sich schmerzhaft ins gehirn einbrennt:
    dlls, die von anderen kompilern genutzt werden sollen, duerfen keine Klassen exportieren ! nur plain C ist standardisiert !

    Ciao ...

    0
  • P

    Hi,

    @RHBaum .. exportiert man in diesem fall nich generell ne factory-function ?
    Oder geht das selbst dann nicht ?

    0
  • R

    Noe, "normal" nicht

    Gibt Faelle, wo man Proxy / Stubs generiert, und die per statischer lib dem eigentlichen programm zulinkt. Aber das geht glaub ich nur mit speziellen Erweiterungen zu irgendwelchen compilern ...

    Kenn mich mit den MFC Erweiterungs-Dlls nicht soo aus, die generieren ne lib zu, aber ich glaub die haendelt wirklich nur das LoadLibrary. Die Klassen werden , glaub ich, weiterhin direkt exportiert.
    Man muesste sich mal die symbole anschauen, die sowas generiert ....

    Schreibst dlls "per hand" und exportierst klassen, werden definitiv die klassen direkt exportiert ... also keine lib generiert, und die Member methoden haben komisch gemergelte Symbolnamen .... kannst nur noch in programmen mit binaerkompatiblen compiler verwenden.

    Ausserdem sollten richtig generische windows-dlls, auch von nicht c++ programmen genutzt werden koennen ... da fallen klassen eh raus ...

    Man kann das aber selber mit bisserl aufwand umgehen, in dem man selber mit handles statt klassen arbeitet (OOP programmierung mit C ) . Da kommen auch dann deine factories zum Einsatz, aber automatisch macht das zumindest kein nativer compiler ... kenn da zumindest nix ...

    Ciao ...

    0
  • P

    Hi,

    achso ich glaub ich hab dich ein bisschen falsch verstanden. Auf unix-systemen gibts gar keine möglichkeit direkt klassen zu exportieren. Ich dachte das wär bei win32 auch so. Da muss man immer ne c-function anbieten die dir die klasse baut und nen zeiger darauf zurück gibt. Und eine entsprechende funktion der du den zeiger wieder übergibst, die sich dann um das aufräumen kümmert.

    Dieser mechanismus sollte doch auch für win32-dlls funktionieren denk ich.

    0
  • C

    Es werden keine klassen exportiert, das sind alles pure virtual methoden.
    Der aufbau ist ne art COM-clone, also intefaces die von IUnknown ableiten und ich brauche jetzt irgend ne lösung um mehrfachverbung von IUnknown-abgeleitet klassen in den grif zu bekommen.
    Klar kann man jedes mal auf das sub-object caste (damit die IUnknown methoden eindeutig werden) aber das strsst auf die dauer 😉 Also wollte ich es mit virtuellen vererbung versuchen, da ich das aber noch nie einem COM interface gesehen habe frage ich mich grad obs da nicht irgend nen hacken gibt.

    0
  • J

    Wie wär's, wenn Du nur nen Proxy rausgibst und dort alle Methoden weiterleitest. Intern kannste ja dann tun und lassen was Du willst.

    0
  • C

    ich glaube ihr versteht mein problem nicth richtig 🤡

    class IDerived1 : public IUnknown
{
};

class IDerived2 : public IUnknown
{
};
class ITopLevel : public IDerived1, public IDerived2
{
};

// wird von dll exportiert:
void CreateTopLevel(ITopLevel **p);

void func()
{
  ITopLevel *p=NULL;
  CreateTopLevel(&p);
  p->AddRef() // <- geht nicht, da ambiguous access of 'AddRef' in 'ITopLevel'
}

    Lösung 1: ein down-cast auf ein IDerived interface -> umständlich
    Lösung 2: multiple inheritance vermeiden -> gute lösung
    Lösung 3: virtuel von IUnknown erben -> hmm.. geht das?
    Ich möchte eigenlich nur wissen ob ich Lösung 3 anwenden kann, oder irgend was dagegen spricht (wie gesagt, habe virtuelle vererbung noch in keinem anderen interface finden können, was mich stuzig macht).

    0
  • R

    Nein, kannst du nicht. Das wäre auch ziemlich sinnlos, weil IUnknown keine Datenmember hat.

    0
  • C

    😕 was hat das mit datenmenbern zu tun?

    Das ganze hat sich aber eh grad erledigt, da nicht mal vorgeschrieben ist was bei mehrfachverbung passieren soll (reihenfolge der subobjects, ect.) also bleibt nur mehr lösung 2 wenn das mit allen compilern laufen soll.

    0
  • R

    Ich habe so gedacht: Bei virtueller Vererbung wird nur eine Instanz der Basisklasse angelegt, wenn diese in der Hierarchie mehrmals vorkommt. Wenn die Instanzgröße aber gleich 0 ist (keine Datenmember), macht das keinen Unterschied.

    Allerdings habe ich vergessen, dass die Instanzgröße wegen der VMT nie gleich 0 ist.

    0
Anmelden zum Antworten