C++ Klassen für DLL exportieren und von dieser erben

[Patrick B. (p51d)]

Hallo zusammen

Ich stosse bis jetzt immer wieder an die gleichen Probleme und möchte 
etwas effizienter werden.
Die Basis meiner Devices ist immer die selbe. Nur die Funktion variiert. 
Damit die Basis und die Hardware Abstraktion nicht jedes mal neu codiert 
werden muss, würde ich das ganze gerne mit DLLs umgehen.

Die Basis Hardware Abstraktion sieht in etwa so aus.

///////////////////////////////////////////////////////////////
/// This class contains all informations about the ident
/// structure (Unit version, interface version, article number...)
///////////////////////////////////////////////////////////////
class CIdent
{
private:
    CModbusMaster& m_roModbusMaster;
 
public:
    static const uint8_t c__u8ArticleNumberLength = 20;
   
    CIdent(CModbusMaster& p_roModbusMaster);
    ~CIdent();
   
    bool bGetArticleNumber(char* p_pcarticleNumber, const uint8_t p__u8BufferSize);
};
 
///////////////////////////////////////////////////////////////
/// This class contains all informations about the standard
/// components on the device.
///////////////////////////////////////////////////////////////
class CNumberOfComponents
{
private:
    CModbusMaster& m_roModbusMaster;
 
public:
    CNumberOfComponents(CModbusMaster& p_roModbusMaster);
    ~CNumberOfComponents();
   
    bool bGetNumberOfInputs(uint8& p_ru8NumberOfInputs);
};
 
 
///////////////////////////////////////////////////////////////
/// Base Class for any devcies
///////////////////////////////////////////////////////////////
class CDevice
{
private:
    CModbusMaster& m_roModbusMaster;
 
public:
    CDevice(CModbusMaster& p_roModbusMaster);
    ~CDevice();
   
    CIdent m__oBootloader;
    CIdent m__oMainApplication;
   
    CNumberOfComponents m__oNumberOfComponents;
};

Die "richtigen" Devices würden dann von dieser Basis aus spezialisiert 
werden. Das könnte in etwa so aussehen:

///////////////////////////////////////////////////////////////
/// Device 1
///////////////////////////////////////////////////////////////
class CDevice1 : public CDevice
{
private:
    CModbusMaster& m_roModbusMaster;
 
public:
    CDevice1(CModbusMaster& p_roModbusMaster);
    ~CDevice1();
   
    void vFunction1();
    void vFunction2();
};
 
///////////////////////////////////////////////////////////////
/// Device 2
///////////////////////////////////////////////////////////////
class CDevice2 : public CDevice
{
private:
    CModbusMaster& m_roModbusMaster;
 
public:
    CDevice2(CModbusMaster& p_roModbusMaster);
    ~CDevice2();
   
    void vFunction1();
    void vFunction2();
};

Da ich bis jetzt nur DLLs benutzt, diese aber nie selber erstellt habe 
bin ich etwas ratlos.
Wie kann/muss ich das nun lösen?
- Eine DLL für die Basis und für jedes Device eine, die von der Basis 
"erbt" (geht das überhaupt?)
- Eine einzelne DLL für die Kombination Basis+Device

Gruss
P51D

[Dr. Sommer (Gast)]

Patrick B. schrieb:
> Wie kann/muss ich das nun lösen?
> - Eine DLL für die Basis und für jedes Device eine, die von der Basis
> "erbt" (geht das überhaupt?)
> - Eine einzelne DLL für die Kombination Basis+Device
Beides geht, du musst du selber entscheiden, was sinnvoller ist... Will 
man jedes Device einzeln austauschen können, oder nutzt man immer eine 
Sammlung an Devices auf einmal, die man so ein eine DLL zusammen packen 
könnte? Prinzipiell kannst du deine Klassen beliebig auf DLL's 
aufteilen, solange keine Klasse doppelt vorkommt.

Du solltest deine Destruktoren in der Basisklasse übrigens besser auf 
"virtual" setzen, denn sonst wird der Destruktor der abgeleiteten Klasse 
ggf. nicht aufgerufen.

[Patrick B. (p51d)]

Mhm, ich habe mir mal ein kleines Projekt aufgesetzt... und schon mit 
Problemen:

class Base
{
    ...
};

class Data
{
    ...
};

// MS Visual C++ compiler emits C4275 warning about not exported base class.
class __declspec(dllexport) Derived :
    public Base
{
    ...

public:
    Data m_data;    // C4251 warning about not exported data member.
};

Muss ich hier jetzt eine C-Wrapper Schnittstelle machen? Weil eine 
abstrake Interface-Klasse geht ja nicht, da die Member sonst nicht 
vefügbar sind.

Gruss

[Dr. Sommer (Gast)]

Ich kenn mich mit der Windows-DLL-Angelegenheit jetzt nicht so aus, hab 
das ewig nicht mehr gemacht...

Patrick B. schrieb:
> Muss ich hier jetzt eine C-Wrapper Schnittstelle machen?
Eigentlich nicht.

Patrick B. schrieb:
> Weil eine
> abstrake Interface-Klasse geht ja nicht, da die Member sonst nicht
> vefügbar sind.
Hä? Geht genauso wie ohne DLL

Patrick B. schrieb:
> // MS Visual C++ compiler emits C4275 warning about not exported base
> class.
Dann exportier die Basis Klasse halt?

[lalala (Gast)]

Warum eine DLL, und nicht einfach nur andere Compilationseinheiten und 
mit dem Linker zusammenlinken?

DLL mit C++ hat den Nachteil, dass das 'name mangling' 
Compiler-versionsspecifisch ist. D.h. keine Vorteil zu dem von mir oben 
geschriebenen Ansatz (eher sogar Nachteile).

Natürlich könnte man es auch so machen:
https://www.codeproject.com/Articles/28969/HowTo-Export-C-classes-from-a-DLL
(den mature approach)

Wenn Du das Ding nicht herausgeben willst / mit nicht C++ verwenden 
willst, lass die DLL.

[Meinungsmache (Gast)]

In Zeiten des unendlichen Speicher haben DLLs für Endanwendungen ihre 
Berechtigung verloren. Sie machen nur Probleme durch falsche Version 
oder glänzen durch Abwesenheit. LIBs sind eine adäquate Möglichkeit für 
Vorfertigung von Modulen. Am Ende alles zu einer EXE verlinkt und man 
ist sich sicher alles komplett zu haben.

[Dr. Sommer (Gast)]

Der Vorteil an DLL's ist, dass man sie austauschen kann, ohne die sie 
verwendenden Programm ändern zu müssen (wenn man es richtig gemacht 
hat). So kann man Fehlerbehebungen und Sicherheitsprobleme automatisch 
für alle Anwendungen übernehmen (auch wenn man deren Quellcode nicht 
hat). Ansonsten haben sie aber eine Menge Nachteile. Das funktioniert 
z.B. bei Java alles besser...

[Noch einer (Gast)]

> abstrake Interface-Klasse

Die Qt hat da einen Trick. Die benutzen Klassen, die nur Funktionen 
enthalten und deren H-Dateien niemals verändert wird. Jede Klasse hat 
dann einen privaten Zeiger auf eine zusätzliche Klasse, die nicht 
exportiert wird.

[Noch einer (Gast)]

>In Zeiten des unendlichen Speicher haben DLLs für Endanwendungen ihre
>Berechtigung verloren.

Eigentlich absurd. Erst machen wir so einen Aufwand mit den DLLs, dann 
verpacken wir die Programme mitsamt eigenen DLLs in Docker oder Snappy.