Im Konstruktor feststellen, ob per operator new erzeugt?

Abent. Titel ist Programm^^ Geht das von Haus aus oder muss ich dazu operator new/delete überladen und wenn ja, wie mache ich das am besten?

Pigeon

Ghimbharth schrieb:

Abent. Titel ist Programm^^ Geht das von Haus aus oder muss ich dazu operator new/delete überladen und wenn ja, wie mache ich das am besten?

Ich glaub das geht so von Haus aus nicht.
Gib doch die Info dem Constructor per bool weiter? Was magst du denn machen?

Pigeon schrieb:

Gib doch die Info dem Constructor per bool weiter? Was magst du denn machen?

Naja die Idee mit dem Konstruktor entspricht eben genau dem, was ich vermeiden wollte. Oder besser gesagt ist es gar nicht möglich, da es sich sowieso um den Konstruktor einer abstrakten Basisklasse handelt. Der genaue Verwendungszweck wäre schwer und zeitintensiv zu erklären, also lasse ich das mal schön bleiben

Wenn ich nun also oeprator new/delete für diese Basisklasse überlade, dann werden diese operatoren für die abgeleiteten Klassen ebenfalls benutzt. (?) Wenn ich nun ein globales bool Feld benutze, welches ich im operator new auf true setze, im Konstruktor abfrage und immer auf false setze, dann kann ich theoretisch herausfinden, ob das Objekt per new allokiert wurde oder nicht. (?) Dieser Lösungsansatz geht den Bach ab, sobald mehrere Threads verwendet werden. (?)

Stimmen meine Überlegungen soweit?

asc

Ghimbharth schrieb:

Der genaue Verwendungszweck wäre schwer und zeitintensiv zu erklären, also lasse ich das mal schön bleiben...

Um dir helfen zu können, sollte man auch wissen ob es vielleicht (bessere) Alternativen gibt.

Ghimbharth schrieb:

Stimmen meine Überlegungen soweit?

Ich würde von diesen Entwurf lieber den Finger lassen, und lieber die Konstruktion kontrollieren (Thema Factorymethoden, privater Konstruktor...).

cu André

Pigeon

asc schrieb:

Ich würde von diesen Entwurf lieber den Finger lassen, und lieber die Konstruktion kontrollieren (Thema Factorymethoden, privater Konstruktor...).

cu André

Ist sowas brauchbar?

struct iWannaBeNew
{
	iWannaBeNew(bool = false);

	static void* operator new(size_t size);

	void doSthVeryIngenious() { cout << "Ich wurde genewt!! :-)" << endl; }
};

iWannaBeNew::iWannaBeNew(bool allocatedWithNew){
	if(allocatedWithNew){
		doSthVeryIngenious();
	}
}

void* iWannaBeNew::operator new(size_t size)
{
	return ::new iWannaBeNew(true);
}

int main()
{
	iWannaBeNew* winner = new iWannaBeNew;
	iWannaBeNew  looser;
}

asc

Pigeon schrieb:

Ist sowas brauchbar?

Ich würde so etwas aus QS-Sicht nicht zulassen...
Die Gefahr bei deiner Methode ist, das sie einfach missbraucht werden kann (Gute Schnittstellen vermeiden die Möglichkeit eines falschen Aufrufes soweit möglich).

Was wäre den wenn ich deine struct wie folgt verwende:

//...
int main()
{
  iWannaBeNew undNun(true);
}

cu André

asc

Eine Möglichkeit wäre es die Konstruktion wie gesagt zu kontrollieren (z.B. new zu erzwingen):

class A
{
  private:
    A() {}

  public:
    static A* Create()
    {
      return new A();
    }
};

Wobei ich solche Konstrukte eigentlich nur mit Smartpointern einsetze (z.B. boost::shared_ptr).

cu André

hustbaer

"new" zu erzwingen ist leicht, indem man den ctor private macht, wie asc das gezeigt hat. "new" zu verbieten ist IMO nicht möglich. vor allem kann man immer folgendes machen:

class no_new
{
    // some magic that prevents the use of new
};

class stupid_trickery
{
public:
    no_new m_got_you;
};

void foo()
{
    stupid_trickery* p = new stupid_trickery();
    p->m_got_you;
}

genausowenig kenne ich eine möglichkeit im ctor herauszufinden ob ein objekt mittels new oder static/auto angelegt wurde.

asc

Ich rezitiere mal ein paar kleine Buchausschnitte (Nachdem ich die Stelle gefunden habe... Hatte bei dem Thread ein Dejavu):

Mehr effektiv C++ Programmieren; Scott Meyer; Addison Wesley Verlag schrieb:

(aus: Reichtlinie 27)
...Die traurige Wahrheit ist, das es keinen portablen Weg gibt, um zu bestimmen, ob ein Objekt auf dem Heap ist; es gibt nicht einmal einen halbportablen Weg, der die meiste Zeit funktioniert...

Heapbasierte Objekte kann man mit einigen Einschränkungen (umfasst Teilweise auch die Basisklassen und wie schon von hustbaer erwähnt Objekte die die Klasse als Member beinhalten) schon auch verhindern. Hierzu verweise ich auf das gleiche Buch (Richtlinie 28).

cu André

Konrad Rudolph

Ich bin zu faul nachzuschauen, was Richtlinie 28 besagt, aber man kann natürlich einfach 'operator new' private deklarieren und nicht definieren. Nur: einen wirklichen Nutzen sehe ich nicht.

sieht mir nach der Lösung eines Problemes aus, dass man garnicht lösen müsste, wenn man ein ordentliches Design hätte.