Ist es möglich, eine C-Struktur in C++ ableiten und Zeiger auf die Struktur in C-Code verwenden?

Question

Gibt es eine Nebenwirkung dies tun:

C-Code:

struct foo { 
     int k; 
}; 

int ret_foo(const struct foo* f){ 
    return f.k; 
} 

C++ Code:

class bar : public foo { 

    int my_bar() { 
     return ret_foo((foo)this); 
    } 

}; 

Es gibt eine extern "C" um den C++ Code und jeder Code ist innerhalb seiner eigenen Compilation Einheit.

Ist dies über Compiler übertragbar?

Answer 1

Dies ist völlig legal. In C++ sind Klassen und Strukturen identische Konzepte, mit der Ausnahme, dass alle Strukturelemente standardmäßig öffentlich sind. Das ist der einzige Unterschied. Die Frage, ob Sie eine Struktur erweitern können, unterscheidet sich nicht von der Frage, ob Sie eine Klasse erweitern können.

Hier gibt es einen Vorbehalt. Es gibt keine Garantie der Layoutkonsistenz von Compiler zu Compiler. Wenn Sie also Ihren C-Code mit einem anderen Compiler als Ihrem C++ - Code kompilieren, können Probleme mit dem Element-Layout (insbesondere dem Padding) auftreten. Dies kann sogar auftreten, wenn C- und C++ - Compiler vom selben Hersteller verwendet werden.

I haben hatte dies mit gcc und g ++ passieren. Ich arbeitete an einem Projekt, das mehrere große Strukturen verwendete. Leider packte g ++ die Strukturen wesentlich looser als gcc, was zu erheblichen Problemen bei der Freigabe von Objekten zwischen C- und C++ - Code führte. Wir mussten schließlich manuell packen und einfügen einfügen, damit der C- und C++ - Code die Strukturen gleich behandelt. Beachten Sie jedoch, dass dieses Problem unabhängig von Unterklassen auftreten kann. Tatsächlich haben wir die C-Struktur in diesem Fall nicht abgeleitet.

Answer 2

Wow, das ist böse.

Ist dies über Compiler übertragbar?

Auf jeden Fall nicht. Berücksichtigen Sie Folgendes:

foo* x = new bar(); 
delete x; 

Damit das funktioniert, muss der Destruktor von foo virtuell sein, was er eindeutig nicht ist. Solange Sie nicht new verwenden und solange das abgeleitete Objekt nicht über benutzerdefinierte Destruktoren verfügt, können Sie Glück haben.

/EDIT: Auf der anderen Seite, wenn der Code nur wie in der Frage verwendet wird, hat die Vererbung keinen Vorteil gegenüber der Zusammensetzung. Befolgen Sie einfach den Rat von m_pGladiator.

Answer 3

Ich empfehle sicherlich nicht solche seltsamen Unterklassen zu verwenden. Es wäre besser, das Design so zu ändern, dass die Komposition statt der Vererbung verwendet wird. Nur ein Mitglied machen

foo * m_pfoo;

in der Bar-Klasse und es wird die gleiche Arbeit machen.

Andere Sache, die Sie tun können, ist eine weitere Klasse FooWrapper zu machen, die die Struktur in sich mit der entsprechenden Getter-Methode enthält. Dann können Sie den Wrapper unterklassifizieren. Auf diese Weise ist das Problem mit dem virtuellen Destruktor verschwunden.

Answer 4

Ich glaube nicht, dass es ein Problem ist. Das Verhalten ist gut definiert, und solange Sie mit den Problemen der Lebensdauer vorsichtig umgehen (mischen Sie nicht und stimmen Sie die Zuweisungen zwischen C++ - und C-Code nicht überein), werden Sie tun, was Sie wollen. Es sollte über Compiler hinweg portabel sein.

Das Problem mit Destruktoren ist real, gilt aber immer dann, wenn der Destruktor der Basisklasse nicht virtuell ist, nicht nur für C-Strukturen. Es ist etwas, was Sie beachten müssen, schließt aber nicht aus, dieses Muster zu verwenden.

Answer 5

Es wird funktionieren, und portabel ABER Sie können keine virtuellen Funktionen (einschließlich Destruktoren) verwenden.

Ich würde empfehlen, dass Sie anstatt dies zu tun haben Bar enthalten ein Foo.

class Bar 
{ 
private: 
    Foo mFoo; 
}; 

Answer 6

Ich verstehe nicht, warum Sie nicht einfach re_foo eine Member-Methode machen. Ihr aktueller Weg macht Ihren Code schwer verständlich. Was ist so schwierig daran, eine echte Klasse mit einer Member-Variablen und Methoden zum Abrufen/Setzen zu verwenden?

Ich weiß, dass es möglich ist, Structs in C++ zu subklassen, aber die Gefahr ist, dass andere nicht in der Lage sind, zu verstehen, was du codiert hast, weil es so selten ist, dass jemand es tatsächlich tut. Ich würde stattdessen für eine robuste und gemeinsame Lösung gehen.

Answer 7

Es wird wahrscheinlich funktionieren, aber ich glaube nicht, dass es garantiert ist. Folgendes ist ein Zitat aus ISO C++ 10/5:

Ein Basisklassenunterobjekt kann ein Layout (3.7) haben, das sich vom Layout eines am meisten abgeleiteten Objekts desselben Typs unterscheidet.

Es ist schwer zu sehen, wie dies in der "realen Welt" tatsächlich der Fall sein könnte.

EDIT:

Unterm Strich ist, dass der Standard die Anzahl der Plätze begrenzt ist, wo eine Basisklasse subobject Layout kann mit dem gleichen Basistyp aus einem konkreten Objekt unterschiedlich sein. Das Ergebnis ist, dass alle Annahmen, die Sie möglicherweise haben, wie POD-Ness usw. nicht unbedingt für das Unterobjekt der Basisklasse gelten.

EDIT:

Ein alternativer Ansatz, und einer, dessen Verhalten definiert ist gut ist ‚foo‘ Mitglied von ‚bar‘ zu machen und einen Umwandlungsoperator zur Verfügung zu stellen, wo es notwendig ist.

class bar { 
public:  
    int my_bar() { 
     return ret_foo(foo_); 
    } 

    // 
    // This allows a 'bar' to be used where a 'foo' is expected 
    inline operator foo&() { 
    return foo_; 
    } 

private:  
    foo foo_; 
}; 

Answer 8

„ableiten nie von konkreten Klassen.“ - Sutter

„Machen Sie nicht-Blatt Klassen abstrakt.“ - Meyers

Es ist einfach falsch nicht-Interface-Klassen, Unterklasse. Sie sollten Ihre Bibliotheken umgestalten.

Technisch können Sie tun, was Sie wollen, solange Sie kein undefiniertes Verhalten durch z. B. einen Zeiger auf die abgeleitete Klasse durch einen Zeiger auf sein Basisklassenunterobjekt löschen. Sie brauchen nicht einmal extern "C" für den C++ - Code. Ja, es ist tragbar. Aber es ist schlechtes Design.

Answer 9

Dies ist vollkommen legal, obwohl es für andere Programmierer verwirrend sein könnte.

Sie können Vererbung verwenden, um C-Strukturen mit Methoden und Konstruktoren zu erweitern.

Probe:

struct POINT { int x, y; } 
class CPoint : POINT 
{ 
public: 
    CPoint(int x_, int y_) { x = x_; y = y_; } 

    const CPoint& operator+=(const POINT& op2) 
    { x += op2.x; y += op2.y; return *this; } 

    // etc. 
}; 

Erweiterung structs könnte „mehr“ böse sein, aber es ist nicht etwas, was Sie zu tun, sind verboten.

Answer 10

Dies ist vollkommen legal, und Sie können es in der Praxis mit den Klassen MFC CRect und CPoint sehen. CPoint stammt von POINT (in windef.h definiert) und CRect von RECT. Sie dekorieren einfach ein Objekt mit Elementfunktionen. Solange Sie das Objekt nicht mit mehr Daten erweitern, geht es Ihnen gut. In der Tat, wenn Sie eine komplexe C-Struktur haben, bei der die Standardinitialisierung ein Problem darstellt, ist die Erweiterung mit einer Klasse, die einen Standardkonstruktor enthält, eine einfache Möglichkeit, um mit diesem Problem umzugehen.

Auch wenn Sie dies tun:

foo *pFoo = new bar; 
delete pFoo; 

dann bist du in Ordnung, da Ihr und Destruktor trivial sind, und Sie haben keinen zusätzlichen Speicher zugewiesen.

Sie müssen auch Ihr C++ Objekt nicht mit 'extern "C' 'umhüllen, da Sie nicht tatsächlich einen C++ Typ an die C-Funktionen übergeben.