Verwendung von smart pointern nur um Konstruktoraufruf verzögern zu können?
-
@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