static auto_ptr ?

Gestalt

Mal ne Frage, spricht was dagegen eine TForm in einer Funktion so zu öffnen?
Gibts da eventuell irgendwelche Dinge die ich dabei noch beachten muss?

	static std::auto_ptr<TDialog_Test> mDialog;
	if(!mDialog.get())
	{
		mDialog=std::auto_ptr<TDialog_Test> (new TDialog_Test(this));
	}

	mDialog->Show();

Tyrdal

@Gestalt sagte in static auto_ptr ?:

Mal ne Frage, spricht was dagegen eine TForm in einer Funktion so zu öffnen?
Gibts da eventuell irgendwelche Dinge die ich dabei noch beachten muss?
	static std::auto_ptr<TDialog_Test> mDialog;
	if(!mDialog.get())
	{
		mDialog=std::auto_ptr<TDialog_Test> (new TDialog_Test(this));
	}

	mDialog->Show();

auto_ptr? wtf? Das Ding war von Anfang an broken by design. Sowas fässt man heutzuitage nicht mehr an, zumal das seit C++17 auch nicht mehr im Standard ist.

Gestalt

Dieser Beitrag wurde gelöscht!

Gestalt

@Tyrdal sagte in static auto_ptr ?:

@Gestalt sagte in static auto_ptr ?:
Mal ne Frage, spricht was dagegen eine TForm in einer Funktion so zu öffnen?
Gibts da eventuell irgendwelche Dinge die ich dabei noch beachten muss?
	static std::auto_ptr<TDialog_Test> mDialog;
	if(!mDialog.get())
	{
		mDialog=std::auto_ptr<TDialog_Test> (new TDialog_Test(this));
	}

	mDialog->Show();
auto_ptr? wtf? Das Ding war von Anfang an broken by design. Sowas fässt man heutzuitage nicht mehr an, zumal das seit C++17 auch nicht mehr im Standard ist.

schön und was macht man an Stelle dessen nu ? unique_ptr nehmen ?

Tyrdal

@Gestalt sagte in static auto_ptr ?:

@Tyrdal sagte in static auto_ptr ?:
@Gestalt sagte in static auto_ptr ?:
Mal ne Frage, spricht was dagegen eine TForm in einer Funktion so zu öffnen?
Gibts da eventuell irgendwelche Dinge die ich dabei noch beachten muss?
	static std::auto_ptr<TDialog_Test> mDialog;
	if(!mDialog.get())
	{
		mDialog=std::auto_ptr<TDialog_Test> (new TDialog_Test(this));
	}

	mDialog->Show();
auto_ptr? wtf? Das Ding war von Anfang an broken by design. Sowas fässt man heutzuitage nicht mehr an, zumal das seit C++17 auch nicht mehr im Standard ist.
schön und was macht man an Stelle dessen nu ? unique_ptr nehmen ?

Das wäre auf jeden Fall besser, aber warum willst den überhaupt auf die Art anlegen?

*john 0

@Gestalt sagte in static auto_ptr ?:

schön und was macht man an Stelle dessen nu ? unique_ptr nehmen ?

shared_ptr wäre der funktionierende Ersatz für auto_ptr.

Quiche Lorraine

@Gestalt
Mehrere Dinge fallen mir zusätzlich zu den vorhergehenden Beiträgen auf:

1.) Vermeide soweit wie möglich new sondern nutze std::make_unique bzw. std::make_shared.

2.) Bei static Variablen (hier mDialog) bekomme ich immer etwas Bauchschmerzen. Denn sind die Daten in mDialog stets gültig? Schlimmer noch, du nutzt zur Konstruktion den this Zeiger. Im schlimmsten Fall speicherst du den Zeiger in mDialog und bindest so die Lebenszeit von this an die Lebenszeit von mDialog. Das ist ein unnötiger und fehleranfälliger Seiteneffekt.

Gestalt

@Quiche-Lorraine
ich verstehe was Du meinst - aber this ist in dem Fall die Hauptform - und dieser wird niemals seine Gültigkeit verlieren solange das Programm läuft.

ich guck mir das mal an in wie weit ich Formulare mit std::make_unique bzw. std::make_shared ins leben rufen kann.

static kann ich auch vermeiden in dem ich den Zeiger einfach global declariere, was wieder auch alles nicht schön sein soll.

Gestalt

@Tyrdal
ohne static ploppt das Fenster kurz auf und schließt sich dann automatisch da die Funktion abgearbeitet wurde.

Ohne static geht es nur wenn ich den Zeiger gloabal deklariere.

Gestalt

Dieser Beitrag wurde gelöscht!

Gestalt

@john-0 sagte in static auto_ptr ?:

shared_ptr wäre der funktionierende Ersatz für auto_ptr.

und warum nicht unique_ptr? will das Formular nicht kopieren oder ähnliches

DocShoe

@Gestalt sagte in static auto_ptr ?:

@Tyrdal
ohne static ploppt das Fenster kurz auf und schließt sich dann automatisch da die Funktion abgearbeitet wurde.

Ohne static geht es nur wenn ich den Zeiger gloabal deklariere.

Das liegt daran, dass du das Fenster mit Show() anzeigst, das ist dann nicht-modal und dein Programmcode wird weiter abgearbeitet. Der auto_ptr geht out-of-scope und löscht das gehaltene CDlg Objekt. Das static benutzt du als Krücke, weil du nicht verstanden hast (nicht böse sein, bitte), wann und warum Objekte zerstört werden.
Wenn das Fenster bestehen bleiben soll musst du dir über die Lebenszeit deines smart_ptrs im Klaren sein und den ggf. da halten, wo er nicht sofort wieder zerstört wird (zB als Member der Klasse).

Gestalt

@DocShoe es ist richtig was Du sagst, und ja ich weiß daß das Object zerstört wird nachdem die Funktion abgearbeitet ist, also bastel ich mir Möglichkeiten dies zu verhindern. Meistens öffne ich ein Fenster MODAL dann gibt es diese Probleme nicht, aber in seltenen Fällen benötige ich eben wie in diesen Fall ein nicht-modales Fenster. Und wegen der Lebenszeit kann ich ja auch global deklarieren ohne static zu benutzen oder ebend dort wo er nicht gleich wieder zerstört wird. Und wieso sollte ich static nicht benutzen wenn es sowas gibt? Auch wenn es eine "Krücke" sein soll - funktioniert doch gut - aber woher soll ich wissen das man das so nicht machen sollte wenn es doch aber geht? Und wenn ich mir mit smart-pointern nicht mal Gedanken machen muss über Speicher löschen dann ist doch die IT-Welt in Ordnung.

*john 0

@Gestalt sagte in static auto_ptr ?:

und warum nicht unique_ptr? will das Formular nicht kopieren oder ähnliches

Weil autor_ptr zu einer Zeit (C++ 1998) in C++ eingeführt wurde, in der ein unqiue_ptr unmöglich gewesen wäre. Man hat aber schnell festgestellt, dass auto_ptr nicht funktioniert und es meines Wissen bereits in C++ 2003 wieder entfernt bzw. als obsolet gekennzeichnet. Die erste funktionierende Smart Pointer Klasse war boost::shared_ptr, die bereits mit C++ 1998 funktionierte.

Erst mit C++ 2011 wurde dann die notwendigen Fähigkeiten in die Sprache integriert, um std::unique_ptr in die Sprache einzuführen. Gleichzeitig wurde std::shared_ptr in die Sprache aufgenommen.

Welcher Smart Pointer an dieser Stelle sinnvoll ist, ist ein anderes Thema und es gab bereits dazu Postings.

P.S. In welcher Dokumentation hast Du auto_ptr ausgegraben? Das ist ja Leichenfledderei.

Leon0402

@john-0 sagte in static auto_ptr ?:

@Gestalt sagte in static auto_ptr ?:

und warum nicht unique_ptr? will das Formular nicht kopieren oder ähnliches

Weil autor_ptr zu einer Zeit (C++ 1998) in C++ eingeführt wurde, in der ein unqiue_ptr unmöglich gewesen wäre. Man hat aber schnell festgestellt, dass auto_ptr nicht funktioniert und es meines Wissen bereits in C++ 2003 wieder entfernt bzw. als obsolet gekennzeichnet. Die erste funktionierende Smart Pointer Klasse war boost::shared_ptr, die bereits mit C++ 1998 funktionierte.

Erst mit C++ 2011 wurde dann die notwendigen Fähigkeiten in die Sprache integriert, um std::unique_ptr in die Sprache einzuführen. Gleichzeitig wurde std::shared_ptr in die Sprache aufgenommen.

Welcher Smart Pointer an dieser Stelle sinnvoll ist, ist ein anderes Thema und es gab bereits dazu Postings.

P.S. In welcher Dokumentation hast Du auto_ptr ausgegraben? Das ist ja Leichenfledderei.

Ich kannte es auch ohne veraltete Bücher oder sonstiges. Zumindest hier https://en.cppreference.com/w/cpp/memory/auto_ptr ist es auch erst seit C++11 obsolet bzw. C++17 entfernt.

Gestalt

@john-0 sagte in static auto_ptr ?:

P.S. In welcher Dokumentation hast Du auto_ptr ausgegraben? Das ist ja Leichenfledderei.

da muss ich scholzen, kann mich daran nicht mehr erinnern