private Member in DLL "verstecken"?

g.r.a.n.d.p.a

Hallo,

ich habe eine Frage bezüglich DLL-Programmierung und privaten Membern von exportierten Klassen.
Angenommen ich habe eine Klasse „DLLExport“ und diese Klasse hat private Member die ich dem DLL-Importör nicht zur Verfügung stellen will. Z.B.

class __declspec(dllexport) DLLExport
{
	public: 
		dasKannBenutztWerden();
	private:
		dasAberNicht();
}

Als Import-File würde ich jetzt zur Verfügung stellen:

class __declspec(dllimport) DLLExport
{ 
	public: 
		dasKannBenutztWerden();

}

MSVS2005 lässt das erst einmal so durch gehen. Die Frage ist aber ob diese Art zu Fehlern in meinem Programm führen?

Besten Dank

Tachyon

Wozu soll das gut sein? Private Member stehen so oder so nicht zur Verfügung.
Hast Du Angst, das der potentielle Benutzer aus dem private ein public machen könnte?

simon.gysi

Ansonsten Pimpl verwenden.
Oder Adapter Pattern.
Simon

g.r.a.n.d.p.a

Nein eigentlich geht es darum in den privaten Membern Datentypen zu deklarieren die der DLL-Importör nicht kennen soll (darf, muss) z.B.

#ifdef _DLLIMPORT_

	#define _DLL_ __declspec(dllimport)
#else
	#define _DLL_ __declspec(dllexport)
	#include "MemberWasImportörNichtKennMuss.h"
#endif

class _DLL_ DLLExport
{
    public:
        dasKannBenutztWerden();
#ifndef _DLLIMPORT_
    private:
        MemberWasImportörNichtKennMuss m_
#endif
}

Ist so was erlaubt?
Besten Dank

Shade Of Mine

Nein. Wenn du eine Klasse exportierst muss der ClientCode ja auf die Klasse zugreifen koennen. Das kann er aber nicht wenn du ihm nicht alle Daten gibts.

pimpl ist hier dein Freund.

RHBaum

Das
MemberWasImportörNichtKennMuss m_
wird der compiler so ned zulassen, weil er die klasse checkt, und dazu die grosse, d.h. die volle definition der member braucht.

ein schritt weiter und simon.gysi Tipp angenommen, waere den Typ der variablen hinnter einem pointer zu verstecken und zu forwarden, so das die abhaengigkeit da aus der klassendef rausfliegt -> siehe Pimpl Idom

Aber wenn man Implementierungsdeteils verstecken will, warum baut man dann keine schnittstellen / abstrakte Klassen ?

du gibts ueber die oeffentliche DLL schnittstelle nur die interfaces nach aussen, und die header deiner konkreten impls brauchst dann nimmer mit ausliefern.
Das heisst der kunde hat keine ahnung, und mit schmutzigen casts auf deine Interfaces wird er gar wunderliche ergebnisse erhalten ...
Positiver nebeffekt:
Interfaces werden meist als solche behandelt und mit groesserer sorgfalt definiert. Was meist dazu fuehrt das die DLL Schnittstelle konstanter bleibt, und der user der dll bei aenderungen nimmer neu kompilieren und ausliefern muss.

Ciao ...

private Member in DLL &quot;verstecken&quot;?

private Member in DLL "verstecken"?