class a
{
public:
    class b
    {
    private:
        b();
        ~b();
    };

private:
    std::list<b> m_bs;
};

Zwar soll die Klasse 'b' nach außen zugänglich sein, jedoch soll die Kon- und Deskruktion von Klasse 'a' kontrolliert werden. Ist eigentlich auch zweitranging. Das Problem hier ist jetzt jedenfalls, dass die std::list ebenfalls Kon- bzw. Desktruktor von 'b' aufrufen können muss.

Ich bekomme folglich die Fehlermeldung (MSVC 10.0):

error C2248: 'a::b::~b' : cannot access private member declared in class 'a::b'

Daher habe ich die Klasse um eine friend Deklaration ergänzt:

class b
{
private:
    b();
    ~b();
    friend class std::list<b>;
};

Leider ohne Erfolg. Da der in std::list verwendete std::allocator ebenfalls über seine 'construct' bzw. 'destruct' Methode Zugriff benötigt, habe ich ihn ebenfalls als friend deklariert. Jedoch wieder ohne Erfolg.

Daraufhin habe ich die Stelle, an der der Zugriff erfolgt lokalisiert. Ein Auszug aus der <list> Implementation von Microsoft:

struct _Node
	{	// list node
	_Nodeptr _Next;	// successor node, or first element if head
	_Nodeptr _Prev;	// predecessor node, or last element if head
	_Ty _Myval;	// the stored value, unused if head

private:
	_Node& operator=(const _Node&);
	};

Das Problem ist hier die Deklaration von '_Myval'.

Die Frage ist nur, habe ich unter solchen Bedingungen keine Chance die std::list zu benutzen?

Zwar soll die Klasse 'b' nach außen zugänglich sein, jedoch soll die Kon- und Deskruktion von Klasse 'a' kontrolliert werden. Ist eigentlich auch zweitranging.

Naein, das ist erstrangig, der Rest deiner Frage ist zweitrangig. Beschreibe, was du erreichen willst und warum, nicht wie du denkst, dass dieses Ziel erreicht werden könnte.

Zwar soll die Klasse 'b' nach außen zugänglich sein, jedoch soll die Kon- und Deskruktion von Klasse 'a' kontrolliert werden.

Dein Code lässt aber std::list die Konstruktion und Destruktion von Objekten der Klasse a kontrollieren.

In diesem Fall musst du Zeiger in der list speichern damit du selber die Konstruktion/Destruktion übernehmen kannst.

Naein, das ist erstrangig, der Rest deiner Frage ist zweitrangig. Beschreibe, was du erreichen willst und warum, nicht wie du denkst, dass dieses Ziel erreicht werden könnte.

Nun, das habe ich im Endeffekt ja schon getan. Niemand soll 'b's instanziieren können außer 'a'. Warum? Weil es im Produktivcode keinen Sinn ergeben würde.

Scorcher24 schrieb:

Öhm, friend class B? In A.

Das macht leider gar keinen Sinn. Was in meinem Beispiel fehlt ist 'friend class a' in 'b', damit 'a' wie von mir erwähnt die Kon- u. Destruktion von 'b' übernehmen kann. Da hier aber nicht relevant, habe ich es weggelassen.

Shade Of Mine schrieb:

Dein Code lässt aber std::list die Konstruktion und Destruktion von Objekten der Klasse a kontrollieren.
In diesem Fall musst du Zeiger in der list speichern damit du selber die Konstruktion/Destruktion übernehmen kannst.

Mir ist das durchaus bekannt. Daher wollte ich die std::list als friend deklarieren. Gibt es hier keinen Workaround?

Mir ist das durchaus bekannt. Daher wollte ich die std::list als friend deklarieren. Gibt es hier keinen Workaround?

Du willst nie friends haben. friends sind böse.
Workaround habe ich dir schon gesagt. alternativ sind vielleicht die boost::intrusive_list Sachen eher geeignet. Das Problem ist nunmal dass die STL dir konstruktion und destruktion abnimmt - deshalb klappt es nicht so wie du es willst.

Workaround: selber konstruieren/destruieren (sprich Zeiger verwenden).

Nun, das habe ich im Endeffekt ja schon getan. Niemand soll 'b's instanziieren können außer 'a'. Warum? Weil es im Produktivcode keinen Sinn ergeben würde.

Mein Vorschlag: Vergiss diese Idee.

Mein Vorschlag: Vergiss diese Idee.

Du meinst, ich soll den Kon- und Destruktor public machen? Wollte ich eigentlich vermeiden. Wie gesagt, du würdest damit nichts anfangen können, wenn du es selbst deklarierst ...

krümelkacker schrieb:

Mein Vorschlag: Vergiss diese Idee.

Du meinst, ich soll den Kon- und Destruktor public machen? Wollte ich eigentlich vermeiden. Wie gesagt, du würdest damit nichts anfangen können, wenn du es selbst deklarierst ...

Und wenn ich dann so ein Objekt erstelle weil mir langweilig ist. Was würde dann passieren? Wäre dann irgendwas kaputt?

Und wenn ich dann so ein Objekt erstelle weil mir langweilig ist. Was würde dann passieren? Wäre dann irgendwas kaputt?

Du hättest wertvolle Zeit verschwendet und meine Ehre gekränkt ...
Du hast prinzipiell schon recht. Aber ich deklariere Dinge als private, um meinen Kollegen arbeit zu ersparen.

Du meinst, ich soll den Kon- und Destruktor public machen? Wollte ich eigentlich vermeiden. Wie gesagt, du würdest damit nichts anfangen können, wenn du es selbst deklarierst ...

Man kann das erzeugen von Klassen auch dadurch verhindern, das man die Impl nicht zugänglich macht, nicht verteilt.
.... Der Anwender/verwender bekommt dann nur ne Abstrakte Protokollklasse (Interface) zu sehen.
Was soll Dein Project eigentlich werden ? eine Biblio ? oder ne lose Sammlung von c++ Dateien ?

Ciao ...

Denkst du dann hoffentlich auch daran, den op= + Copy-CTor private zu machen?

Nein, denn man soll durch aus Objekte (zwischen-)speichern können.

RHBaum schrieb:

Was soll Dein Project eigentlich werden ? eine Biblio ? oder ne lose Sammlung von c++ Dateien ?

Spielt hier eigentlich doch keine Rolle. Die Problematik hatte ich bei der Implementation einer Klasse in einem größeren Projekt meiner Firma.

Stindel schrieb:

Denkst du dann hoffentlich auch daran, den op= + Copy-CTor private zu machen?

Nein, denn man soll durch aus Objekte (zwischen-)speichern können.

Tjo, dann hast du ein Problem. Auch zwischengespeicherte Objekte müssen zerstört werden können, wofür der Destruktor bekannt sein muss.