C++ Friend-Deklaratio bei Klassen in DLL

[hansi_a (Gast)]

Hallo,

ich habe eine Klasse in einer DLL

class __declspec(DllExport) Ape {
public:
    friend class V3D;
    Ape ();
    ~Ape ();
private:
   int i;
};

in der Anwendung lade ich die DLL und habe dort eine Klasse V3D welche 
auf das private Member i zugreifen soll. (Die ja eigentlich Friend sein 
sollte)

Ich bekomme aber immer die Fehlermeldung, dass es private ist.

Funktinieren Friend Deklarationen nicht wenn die Klasse in einer DLL 
ist?

[tictactoe (Gast)]

hansi_a schrieb:
> Funktinieren Friend Deklarationen nicht wenn die Klasse in einer DLL
> ist?

Nein, kann damit nichts zu tun haben. Zeig mal, wie du denn auf i 
zugreifst.

[Sebastian Hepp (Gast)]

Das Problem dürfte hier sein, dass sich das Friend Schlüsselwort nur auf 
das aktuelle Projekt (also die DLL) auswirken kann. Sobald die DLL 
kompiliert und gelinkt worden ist, gibt es ja keine Informationen mehr 
für das friend, weil es in der fertigen Datei nur noch Maschinencode und 
keine Klassennamen mehr gibt.

[Rufus Τ. F. (rufus)]

Sebastian Hepp schrieb:
> Sobald die DLL kompiliert und gelinkt worden ist, gibt es ja keine
> Informationen mehr für das friend, weil es in der fertigen Datei nur
> noch Maschinencode und keine Klassennamen mehr gibt.

Nö, das ist eine C++-DLL, die nur bei Verwendung der zugehörigen 
Headerdatei (mit Klassendeklaration) verwendbar ist; die exportierten 
Symbole der DLL sind mit "name mangling" versehen, wie sie es auch bei 
einer statisch zu linkenden Library wären.

[Noch einer (Gast)]

>die exportierten Symbole der DLL

Sind die private member, auf die dein friend zugreifen will, überhaupt 
exportiert?

Mit dumpbin nachschauen.

[Noch einer (Gast)]

Eigentlich ist "friend" in einer DLL eine recht schräge Idee.

Im realen Leben sagst du ja auch nicht -- jeder der behauptet, er heisst 
"Klaus" ist mein Freund.

[Florian (Gast)]

Noch einer schrieb:
> Eigentlich ist "friend" in einer DLL eine recht schräge Idee.

Genau. "friend" verwendet man so sparsam wie möglich und nur für 
Klassen, die sehr eng mit anderen Klassen bzw. Funktionen 
zusammenarbeiten (aber eben aus verschiedenen Gründen nicht in der 
Klasse selbst implementiert werden sollen). Dementsprechend gehört der 
ganze Klumpatsch dann normalerweise auch in eine gemeinsame Bibliothek 
und wird nicht willkürlich getrennt.

[Florian (Gast)]

Florian schrieb:
> "friend" verwendet man so sparsam wie möglich und nur für
> Klassen, die sehr eng mit anderen Klassen bzw. Funktionen
> zusammenarbeiten (aber eben aus verschiedenen Gründen nicht in der
> Klasse selbst implementiert werden sollen).

Etwas wirr.
... (aber die entsprechende Funktionalität eben aus verschiedenen 
Gründen - generelles Design, Operandenreihenfolge, ... - nicht in der 
Klasse selbst implementiert werden soll oder kann, aber der Zugriff so 
effizient wie unter den gegebenen Umständen möglich sein soll). Auch 
wenn du einfach nur V3D Zugriff auf i gewähren und ansonsten nicht 
zulassen willst, gehören Ape und V3D sehr wahrscheinlich in die gleiche 
Bibliothek. Oder dein Vorgehen ist insgesamt nicht passend, aber dazu 
müsste man mehr wissen.

BTW: Rein technisch funktioniert es natürlich trotzdem.

ape.h; APEDLL_EXPORTS im DLL-Projekt definieren.

#pragma once

#ifdef APEDLL_EXPORTS
#define APEDLL_API __declspec(dllexport) 
#else
#define APEDLL_API __declspec(dllimport) 
#endif

class APEDLL_API Ape
{
public:
  friend class V3D;
private:
  int i;
};

client.cpp

#include "ape.h"

class V3D
{
public:
  void bla(Ape& ape)
  {
    ape.i = 99;
  }
};

int main()
{
  V3D v3d;
  Ape ape;
  v3d.bla(ape);

  return 0;
}

Klappt problemlos.