Verwendung von smart pointern nur um Konstruktoraufruf verzögern zu können?
-
@manni66 Habe im Quellcode gesucht. Ich verstehe es so, dass man auch
nullptr
übergeben können soll.
-
@titan99_ sagte in Verwendung von smart pointern nur um Konstruktoraufruf verzögern zu können?:
@manni66 Habe im Quellcode gesucht. Ich verstehe es so, dass man auch
nullptr
übergeben können soll.Man könnte zwei Konstruktoren anbieten, wenn der Parameter nur optional sein soll. Was auch immer: es wird nicht erklärt, was mit den Attributen passiert.
-
@Bushmaster sagte in Verwendung von smart pointern nur um Konstruktoraufruf verzögern zu können?:
wenn man mit pointern hantieren muss, aber sich vor fehlern fürchtet, die bei der benutzung roher pointer passieren können.
-
@hustbaer sagte in Verwendung von smart pointern nur um Konstruktoraufruf verzögern zu können?:
@Bushmaster sagte in Verwendung von smart pointern nur um Konstruktoraufruf verzögern zu können?:
wenn man mit pointern hantieren muss, aber sich vor fehlern fürchtet, die bei der benutzung roher pointer passieren können.
du findest wohl smartpointer wenig sinnvoll. bist wohl ein oldschool-c-coder.
-
@Bushmaster Nein. Ich verwende ausschliesslich Smart-Pointer. Aber nicht weil ich Angst habe, sondern weil alles andere Quatsch ist.
-
@manni66 sagte in Verwendung von smart pointern nur um Konstruktoraufruf verzögern zu können?:
@titan99_ sagte in Verwendung von smart pointern nur um Konstruktoraufruf verzögern zu können?:
context = std::make_unique<wxGLContext>(this, nullptr, &context_attributes);
WxWidgets ist wirklich der letzte Schrott! Wenn der wxGLContext keine Kopie der Attribute macht (er nimmt einen Pointer, die Doku sagt nichts dazu), ist dein Objekt am Ende des Konstruktors kaputt.
wxWidgets ist zwar manchmal etwas altbacken, aber Schrott ist es bei weitem nicht. Die meisten Dinge sind konsitent und ganz gut durchdacht. Es steht unter einer echten OpenSource Lizenz und braucht keinen spezial Compilier. Es gibt zwar immer mal Ecken, wo man sich etwas ärgert, aber an und für sich, kann man mit wxWidgets ganz brauchbar GUIs erstellen.
In dem Fall, werden die Attribute Kopiert (ich hab grade mal in die Sourcen geschaut).
Ist halt ein optionaler Parameter. Entweder muss man zwei Konstruktoren machen, einen für den Fall, dass man den Parameter nicht übergeben möchte und einen für die Übergabe, dann kann man eine const Referenz nehmen, oder man handelt das in einem Konstruktor ab, muss dann aber über den Pointer gehen um nullptr als Auswahl für nicht vorhanden zu erlauben.
Wenn man dahingehend die Doku verbessern kann, ist die wxWidgets Community bestimmt dankbar, wenn man da ein ein Vorschlag einreicht. Ist halt eine Community Sache, ohne eine Firma dahinter.
@Bushmaster sagte in Verwendung von smart pointern nur um Konstruktoraufruf verzögern zu können?:
@titan99_ sagte in Verwendung von smart pointern nur um Konstruktoraufruf verzögern zu können?:
Allgemein gefragt, wann verwendet man smart pointer, also z.B. std::unique_ptr.
Nur um heap-memory als Speicher zu verwenden? Oder gibt es noch andere Gründe?wenn man mit pointern hantieren muss, aber sich vor fehlern fürchtet, die bei der benutzung roher pointer passieren können.
Immer, wenn man mit rohen Pointern hantieren muss, die Objekte "besitzen".
-
@hustbaer sagte in Verwendung von smart pointern nur um Konstruktoraufruf verzögern zu können?:
Nein. Ich verwende ausschliesslich Smart-Pointer.
ich verzichte ganz auf pointer und maschinennahe konzepte wie adressen. brauchste nicht in c++.
wird langsam zeit dass pointer rausfliegen. https://www.fluentcpp.com/2018/04/01/cpp-will-no-longer-have-pointers/
-
@Bushmaster
this article, released on April Fool date, was an April Fool joke.
Ja dann ist ja alles gut ...
-
@manni66 sagte in Verwendung von smart pointern nur um Konstruktoraufruf verzögern zu können?:
this article, released on April Fool date, was an April Fool joke.
über sowas macht man keine witze!
-
@Bushmaster je mehr ich von dir lese meine ich dass du ausschliesslich witze machst. aber irgendwie komische. wenn du nie pointer verwendest, gut, in bestimmten anwendungen geht das schön. aber nicht überall. wenn du das nicht verstehst, dann fehlt dir vermutlich etwas die erfahrung über den tellerrand hinaus.
-
@hustbaer sagte in Verwendung von smart pointern nur um Konstruktoraufruf verzögern zu können?:
wenn du nie pointer verwendest, gut, in bestimmten anwendungen geht das schön. aber nicht überall. wenn du das nicht verstehst, dann fehlt dir vermutlich etwas die erfahrung über den tellerrand hinaus.
Wenn man nur stack-memory verwendet?
Edit: Glaube doch nicht, weil z.B. vector auch heap-memory verwendet.
-
EDIT: Falschen Thread erwischt
-
//Note: // You may wonder why OpenGL initialization was not done at wxGLCanvas ctor. // The reason is due to GTK+/X11 working asynchronously, we can't call // SetCurrent() before the window is shown on screen (GTK+ doc's say that the // window must be realized first). // In wxGTK, window creation and sizing requires several size-events. At least // one of them happens after GTK+ has notified the realization. We use this // circumstance and do initialization then.
Also es gibt eine zweite Verzögerung bzw. ein Aufruf während der Initialization, die aber erst nach bestimmten anderen Aufrufen geschehen kann.
GetParent()->Show(); SetCurrent(context); int gladLoaded = gladLoadGL();
Also das Fenster muss angezeigt sein, erst dann sollte der OpenGL context SetCurrent übergeben werden und erst danach kann glad (in dem Fall) oder glew initialisiert werden. Und erst danach kann die GraphicEngine allokiert werden.
graphic_engine = std::make_unique<GraphicEngine>(); graphic_engine->Setup();
Die Verzögerung ist immer noch durch smartpointer bzw.
new
ermöglicht. Wird GraphicEngine vor gladLoadGL() allokiert, kommt beim ersten(?) OpenGL-Funktionsaufruf -glGenVertexArrays(1, &VAO);
eine Fehlermeldung: Access violation executing location 0x0000000000000000.
-
@Bushmaster sagte in Verwendung von smart pointern nur um Konstruktoraufruf verzögern zu können?:
@hustbaer sagte in Verwendung von smart pointern nur um Konstruktoraufruf verzögern zu können?:
Nein. Ich verwende ausschliesslich Smart-Pointer.
ich verzichte ganz auf pointer und maschinennahe konzepte wie adressen. brauchste nicht in c++.
Interessantes Konzept. Würde ich gerne mal im Bereich Backends/Server umgesetzt sehen. Also so ganz ohne Rohe Pointer und Smartpointer.
-
@hustbaer sagte in Verwendung von smart pointern nur um Konstruktoraufruf verzögern zu können?:
SendMessage geht nur dann über die Message-Queue, ...
Hast du das falsche Thema erwischt und wolltest eigentlich in Absturz wenn DLL ein Child Fenster erzeugt dessen Parent ein Form ist posten?
-
@Th69 sagte in Verwendung von smart pointern nur um Konstruktoraufruf verzögern zu können?:
@hustbaer sagte in Verwendung von smart pointern nur um Konstruktoraufruf verzögern zu können?:
SendMessage geht nur dann über die Message-Queue, ...
Hast du das falsche Thema erwischt und wolltest eigentlich in Absturz wenn DLL ein Child Fenster erzeugt dessen Parent ein Form ist posten?
Völlig richtig. Danke!
-
@It0101 sagte in Verwendung von smart pointern nur um Konstruktoraufruf verzögern zu können?:
Würde ich gerne mal im Bereich Backends/Server umgesetzt sehen. Also so ganz ohne Rohe Pointer und Smartpointer.
du meinst wenn man pakete bauen muss, wie sie von einem bestimmten protokoll verlangt werden? dafür könnte man arrays nehmen.
oder es werden automatisch smartpointer verwendet, wenn der compiler auf pointer-syntax trifft.pointer sind ein relikt aus alten plain-c-tagen. ebenso wie new/delete, diese rohen heap-befehle.
am schrecklichsten finde ich mehrfachpointer, sowas wie "int ***ppptr" // pointer auf pointer auf pointer auf ein int.
-
@Bushmaster sagte in [Verwendung von smart pointern nur um Konstruktoraufruf verzögern zu können?]
oder es werden automatisch smartpointer verwendet, wenn der compiler auf pointer-syntax trifft.
Die hast auf Hustbaers "ich verwende ausschließlich Smart-Pointer" geantwortet mit "ich verzichte komplett".
Ich ging daher davon aus, du würdest nicht nur auf rohe Pointer sondern auch auf Smartpointer verzichten. Das man mit Smartpointern alles machen kann, ist mir auch klar. Nur wie es komplett ohne Pointer und Smartpointer ginge, würde mich interessieren.
-
@manni66 sagte in Verwendung von smart pointern nur um Konstruktoraufruf verzögern zu können?:
Es wird ein Pointer auf wxGLContextAttrs übergeben. Das macht man in C++ dann, wenn man sich diese Adresse merken will, statt das Objekt zu kopieren. Für Attribute ist das eine eher ungewöhnliche Vorgehensweise. Die Doku schweigt sich darüber aus.
void ProjectionShader::SetProjectionMatrix(const mat4& value) const { glUniformMatrix4fv(projection, 1, GL_FALSE, glm::value_ptr(value)); }
An
glUniformMatrix4fv
übergebe ich auch die Matrix als Pointer, obwohl der Pointer auf eine temporäre lokale Variable zeigt, die eigentlich nach dem Aufruf oder zumindest nach dem Ende der Funktion ungültig werden sollte.
-
@titan99_ sagte in Verwendung von smart pointern nur um Konstruktoraufruf verzögern zu können?:
An
glUniformMatrix4fv
übergebe ich auch die Matrix als Pointer, obwohl der Pointer auf eine temporäre lokale Variable zeigt, die eigentlich nach dem Aufruf oder zumindest nach dem Ende der Funktion ungültig werden sollte.OpenGL ist allerdings auch eine C-API, wärend wxWidgets C++ verwendet. In C gibt es keine Referenzen, daher muss man das hier mit Pointern machen.
Bei ordentlich implementierten Bibliotheken sollte es eigentlich auch kein Problem sein, Pointer zu übergeben, die nur während des Funktionsaufrufs auf gültigen Speicher verweisen. Ich würde dazu auch nur dann einen (deutlichen!) Hinweis in der Doku erwarten, wenn das bei einer Funktion nicht der Fall ist.
Ein Beispiel für so einen Doku-Hinweis aus der C++-Welt findet sich z.B. bei
string_view
:
It is the programmer's responsibility to ensure thatstd::string_view
does not outlive the pointed-to character array.
https://en.cppreference.com/w/cpp/string/basic_string_view