Erzwingen, dass eine Klasse auf dem Stack erzeugt wird?

godlikebot

volkard schrieb:

geht nicht. aber wenn du der klasse nen operator new deklarierst und nicht definiertst, werden schonmal die meisten abgeschreckt.

Danke! Das hilft mir schonmal ein ganzes Stück weiter. Aber was meinst du denn mit den "meisten"?

John Doe

Wenn ich operator new und operator new[] private deklariere, wie kann ich denn
dann noch Objekte dieser Klasse auf dem Heap allokieren ??

mfg JJ

Artchi

Das will er ja gerade verhindern!

camper

könnte mit malloc (oder irgendein new char[sizeof(..)]) und placement new gehen - oder auch nicht.

HumeSikkins

camper schrieb:

könnte mit malloc (oder irgendein new char[sizeof(..)]) und placement new gehen - oder auch nicht.

Mit placement new sicher nicht. Durch die Deklaration eines operator news innerhalb einer Klassendefinition werden alle anderen operator new-Funktionen für diese Klasse verdeckt. Auch und gerade die globalen.

Letztlich erzwingt das aber natürlich keine Stack-Objekte, da mich niemand daran hindert statische bzw. globale Objekte anzulegen. Oder halt Objektaggregationen.

John Doe

Hi Artchi,

das war eine rhetorische Frage

geht nicht

Also, verhindert meine Methode nun zuverlässig die (dynamische) Allokation vom Heap oder
nicht ??

mfg JJ

camper

class foo
{
private:
	void* operator new(size_t size);
public:
	foo() { std::cout << "foo\n"; }
};
int main()
{
	foo *bar = reinterpret_cast< foo* >( new char[ sizeof( foo ) ] );
	::new( bar ) foo;
	delete [] reinterpret_cast< char* >( bar );
}

geht wunderbar :xmas1:

John Doe

Na, so ganz wunderbar auch wieder nicht.
Für deine Beispielklasse wird kein Destruktor aufgerufen wie man
das von placement new so kennt.

virtual ~foo() { std::cout << "...foo\n"; }

Also die würde ich so schon mal nicht stehen lassen. :xmas1:

mfg JJ

camper

John Doe schrieb:

Na, so ganz wunderbar auch wieder nicht.
Für deine Beispielklasse wird kein Destruktor aufgerufen wie man
das von placement new so kennt.
virtual ~foo() { std::cout << "...foo\n"; }
Also die würde ich so schon mal nicht stehen lassen. :xmas1:

mfg JJ

ist mir auch grad aufgefallen. aber das kann man ja explizit machen hehe..

class foo
{
private:
    void* operator new(size_t size);
public:
    foo() { std::cout << "foo\n"; }
virtual ~foo() { std::cout << "...foo\n"; }
};
int main()
{
    foo *bar = reinterpret_cast< foo* >( new char[ sizeof( foo ) ] );
    ::new( bar ) foo;
    bar->~foo();
    delete [] reinterpret_cast< char* >( bar );
}

soviel zum thema: das ist krank

John Doe

Fortsetzung "krank"

Da wir sowas nicht möchten machen wir den Destruktor natürlich auch private.

mfg JJ

camper

John Doe schrieb:

Fortsetzung "krank"

Da wir sowas nicht möchten machen wir den Destruktor natürlich auch private.

mfg JJ

dummerweise ist die klasse dann gänzlich unbenutzbar - nicht bloss auf dem heap

John Doe

Das mit der Ironie will mir heute einfach nicht gelingen.

mfg JJ

hehejo

Bevor ich mich zu Tode suche:
Es wird hier (und in anderen Threads) oft von placement new gesprochen.
Was ist denn das?

Delryn

Ich hab das Wort "zwingen" überlesen, ich wusste doch das meine Antwort Müll ist

John Doe

Du allokierst dir erst "genügend" Speicher und erzeugst dann dein Objekt genau
an dieser Adresse. (Siehe code von camper)

mfg JJ

godlikebot

Also... Ich glaube ich werde den new und new[] operator private zu machen. Das sollte dann Hinweis genug sein, dass man diese Klasse nicht auf dem Heap anlegen sollte.
Ich werd' mal davon ausgehen, dass niemand wirklich versucht die Klasse per placement new auf den Heap zu drücken, aber trotzdem Danke für das Bsp. Wusste auch nicht, dass es sowas gibt.
Danke für eure Antworten :)!

Shade Of Mine

Bloede Frage: warum willst du das eigentlich?

Auf den Heap zwingen kann Sinn machen, weil man dann delete this; verwenden kann oder aehnliches. Was aber bringt es auf dem Stack?

godlikebot

Gar nicht so ne blöde Frage... Ich möchte ein paar Klassen per PImpl Idiom erstellen, bei der die öffentliche Schnittstelle automatisches reference counting für die Implementation übernimmt. Schaden würde es nicht, wenn die Klasse (das Interface) auf dem Heap angelegt wird, aber dadurch würde ein Stück der Einfachheit und des SmartPointer-Verhaltens der Klasse verloren gehen.

otze

Shade Of Mine schrieb:

Bloede Frage: warum willst du das eigentlich?

Auf den Heap zwingen kann Sinn machen, weil man dann delete this; verwenden kann oder aehnliches. Was aber bringt es auf dem Stack?

stell dir mal nen scoped_ptr aufm heap vor

groovemaster

otze schrieb:

stell dir mal nen scoped_ptr aufm heap vor

Du meinst sowas hier

scoped_ptr<scoped_ptr<foo> > p(new scoped_ptr<foo>(new foo));

:p