Einige Fragen zu Pointern und deren richtige Nutzung?

[Peter_2498]

Hallo,

paar Dinge sind mir bei Pointern in C++ noch nicht so ganz klar.

Pointer als Parameter einer Funktion

1.So wie ich das bisher verstanden habe, nutzt man für die Argumente an erster Stelle (const) Referenzen( wenn die Objekte nicht "klein" sind oder man sich bei der Größe der Objekte nicht sicher ist) und wohl erst dann Pointer, wenn man einen Nullpointer zulassen will. Wieso würde man Nullpointer zulassen wollen?

2.Wenn man festgelegt hat einen Pointer als Parameter zu setzen, was gibt es für Gründe keinen RAW Pointer sondern einen Smart Pointer als Parameter festzulegen?

Pointer auf Objekte auf dem Heap

3.Habe ich recht, dass Pointer, die auf Objekte im Heap zeigen, möglichst Smart Pointer sein sollten?

 

[KitKat::new()]

1.So wie ich das bisher verstanden habe, nutzt man für die Argumente an erster Stelle (const) Referenzen( wenn die Objekte nicht "klein" sind oder man sich bei der Größe der Objekte nicht sicher ist) und wohl erst dann Pointer, wenn man einen Nullpointer zulassen will. Wieso würde man Nullpointer zulassen wollen?

Optionale Argumente (z.B. statt std::optional<std::reference_wrapper<T>>, weil das viele zu verbose finden)

2.Wenn man festgelegt hat einen Pointer als Parameter zu setzen, was gibt es für Gründe keinen RAW Pointer sondern einen Smart Pointer als Parameter festzulegen?

Wenn du z.B. einen unique_ptr festlegst, implizierst du Besitzübertragung des Objekts. Ähnlich verhält es sich mit shared_ptr. Oft will man das nicht.

Ergänzung (7. Januar 2022)

3.Habe ich recht, dass Pointer, die auf Objekte im Heap zeigen, möglichst Smart Pointer sein sollten?

Lass es mal anders ausdrücken: auf Objekte im Heap sollte möglichst mindestens ein Smartpointer zeigen ;-)

Zusätzliche Referenzen/Pointer sind ja wie auf dem Stack auch beim Heap kein Problem

 

[Multivac]

"Lass es mal anders ausdrücken: auf Objekte im Heap sollte möglichst mindestens ein Smartpointer zeigen ;-)"
Ich bin mir sicher ich klinge jetzt Pedantisch aber Nein ganz sicher nicht. Beispiel ein Vector wird Objekte auch so Zerstören. Es geht darum das es
Good practice" ist jedes Object welches erstellt wird auch wieder zu zerstören. grundsätzlich zu jedem new gehört ein delete in der Praxis wird es oft schwer und unübersichtlich. Smartpointer erlauben uns auch bei komplexen Programmen die Heaps clean zu halten. Viele Programmierer haben sich schon für besonders clever gehalten und am ende sieht man dann dass es memory leaks und weiters gibt. Es gibt immer ausnahmen ich kann einen custom allocator nutzen der Speicher aus einen buffer den ich auf meinen stack erstellt habe verteilt wenn der de_ctor eh nichts macht warum sollte ich logik schreib die jedes objekt einzeln freigibt wenn vorher sagen kann das ich diesen Buffer als ganzes freigeben kann.

1.) https://www.modernescpp.com/index.php/c-core-guidelines-how-to-pass-function-parameters

Es gibt auch andere gruende warum du keine copy machen kannst. Schreib mal einen wrapper um einen "File descriptor" also fopen und fclose, wenn du hier call by value machst wird dein file zwei mal geschlossen einmal durch das original und einmal durch die copy. speater wirst du sachen wie move sematic lernen Ich will hier nicht vorgreifen.

@KitKat::new()
std:ptional<std::reference_wrapper<T>>
Function Overloading wirkt da auf mich viel eleganter.

​

 

[KitKat::new()]

Function Overloading wirkt da auf mich viel eleganter.

Inwiefern spielt da "Function Overloading" mit rein?

Ergänzung (8. Januar 2022)

Ich bin mir sicher ich klinge jetzt Pedantisch aber Nein ganz sicher nicht. Beispiel ein Vector wird Objekte auch so Zerstören. Es geht darum das es

der Vector ist (erstmal) kein Objekt auf den Heap.
(Er zeigt aber intern auf den Heap und verhält sich bezüglich diesem wie ein unique_ptr)

Verstehe gar nicht, was du mit dem Kommentar bezwecken willst.

grundsätzlich zu jedem new gehört ein delete in der Praxis wird es oft schwer und unübersichtlich. Smartpointer erlauben uns auch bei komplexen Programmen die Heaps clean zu halten.

Und genau deswegen ist es sinnvoll mind 1 SP auf das Objekt im Heap zeigen zu lassen, d.h. entweder einen unique_ptr oder mehrere shared_ptr/weak_ptr

 

[Multivac]

f(in)
f()
als alternative zu
f(OPT)

 

[KitKat::new()]

ah stimmt, geht natürlich nicht immer (z.B. Rückgabewert oder Member in einer Klasse)

 

[Multivac]

3.Habe ich recht, dass Pointer, die auf Objekte im Heap zeigen, möglichst Smart Pointer sein sollten?

Wer und wann wird das Objekt auf dem Heap wieder frei? ein Zeiger der auf ein Objekt in einen std::vector zeigt sollte kein smart-pointer sein. Der Vector gibt die Resource frei so bald er aus dem Scope verwindet.
https://docs.microsoft.com/en-us/cp...-resource-management-modern-cpp?view=msvc-170
https://en.cppreference.com/w/cpp/language/raii

Es ist gute Praxis aber keine Regel ohne Ausnahme!

der Vector ist (erstmal) kein Objekt auf den Heap.
(Er zeigt aber intern auf den Heap und verhält sich bezüglich diesem wie ein unique_ptr)

ein Vector kann auch auf dem Heap erstellt werden

 auto v = new std::vector<int>();

und er kann seine Objekte auch auf den stack legen siehe stack_allocater, small vector optimization, etc.

Und genau deswegen ist es sinnvoll mind 1 SP auf das Objekt im Heap zeigen zu lassen, d.h. entweder einen unique_ptr oder mehrere shared_ptr/weak_ptr

Es ist eine guter Ansatz erst RAII zu lehren, aber es ist nicht der einzige Weg.

 

[KitKat::new()]

ein Vector kann auch auf dem Heap erstellt werden

Deswegen schrieb ich "erstmal".

Wenn du den in den Heap packen willst, sollte man wohl wiederum einen Smartpointer nutzen -> es zeigt wieder mindestens ein Smartpointer auf das Objekt im Heap.

Es ist eine guter Ansatz erst RAII zu lehren, aber es ist nicht der einzige Weg.

Ich habe nicht gesagt was man zuerst lernen soll