Zeiger = 0;

RussianTux

Kellerautomat schrieb:

Gegen unique_ptr gibt es keinen Grund. Er ist genau gleich schnell wie ein roher Zeiger, nur besser.

Wie oft soll ich denn noch wiederholen dass es nicht meine Aufgabenstellung ist, meine ist es den Code komplett selber zu schreiben!

UND NEIN, es handelt sich gerade nicht um die Entwicklung eines Programms, sondern um DIE THEORETISCHEN ZEIGER KENNTNISSE.

Kellerautomat

"Komplett selber schreiben" ist bestimmt nicht deine Anforderung. Oder schreibst du dir die STL+Iostreams auch selbst?
Du kannst dir übrigens auch selbst einen unique_ptr implementieren.

Ethon

Ich habe ein paar Seiten davor eine Beispielsimplementierung eines shared_ptr gepostet, sowas bekommt man sehr schnell hin und es ist "selbst gemacht" ...

RussianTux

Ethon schrieb:

Ich habe ein paar Seiten davor eine Beispielsimplementierung eines shared_ptr gepostet, sowas bekommt man sehr schnell hin und es ist "selbst gemacht" ...

Und ich habe Beispielcode gepostet, nur wurde der leider ignoriert!

Bin Schritt für Schritt durchs Programm gegangen um sicherzustellen, dass es wirklich ohne Speicherleck funktionieren müsste, nur wurde auch dieser Beitrag einfach ignoriert!

RussianTux schrieb:

einen davon habe ich oben als Beispiel angegeben, was ist denn so schwer daran zu verstehen?

In dem Beispiel macht es aber keinen Sinn (wie schon ausreichend dargelegt), was ist denn so schwer daran zu verstehen?
Nexus, Ethon, Miachel, dot sind Profis. Wenn die dir sagen, es ist Quatsch, dann nimm es dir zu Herzen.
Und sei dir auch endlich über den Widerspruch im Klaren: "Ich will Zeiger lernen, und ich weiß was ich tue". Das passt nicht zusammen, oder?

Und wie bereits angetönt gehört std::unique_ptr (und std::shared_ptr) genauso zu den Standardmitteln wie std::string oder std::vector oder std::fstream usw.

RussianTux

arghonaut schrieb:

RussianTux schrieb:

einen davon habe ich oben als Beispiel angegeben, was ist denn so schwer daran zu verstehen?

In dem Beispiel macht es aber keinen Sinn

Ja das habe ich schon gehört, aber deutet jemand auch nur annähernd an was denn da sinnlos ist?! Das Programm funktioniert ohne Speicherleck, ist es nicht so?

Michael E.

RussianTux schrieb:

Und ich habe Beispielcode gepostet, nur wurde der leider ignoriert!

Wenn es dich beruhigt: Dein Beispiel sieht sicher aus, aber nur durch eine Subtilität: Wenn das new im Konstruktor eine Exception wirft, leakt das erste new für das Pointer-Objekt nicht.

Sobald du dein Beispiel aber auch nur ein bisschen erweitern willst, fliegt es dir um die Ohren:

Pointer p(Data());    // kabumm!

Data d;
Pointer p1(d);
Pointer p2 = p1;    // kabumm!

void foo(Pointer p);
foo(p1);    // kabumm!

vector<Pointer> bar;
bar.push_back(p1);    // kabumm!

Sprich: Dein Code ist nicht benutzbar.

RussianTux

Michael E. schrieb:

RussianTux schrieb:

Und ich habe Beispielcode gepostet, nur wurde der leider ignoriert!

Wenn es dich beruhigt: Dein Beispiel sieht sicher aus, aber nur durch eine Subtilität: Wenn das new im Konstruktor eine Exception wirft, leakt das erste new für das Pointer-Objekt nicht.

Sobald du dein Beispiel aber auch nur ein bisschen erweitern willst, fliegt es dir um die Ohren:
Pointer p(Data());    // kabumm!

Data d;
Pointer p1(d);
Pointer p2 = p1;    // kabumm!

void foo(Pointer p);
foo(p1);    // kabumm!

vector<Pointer> bar;
bar.push_back(p1);    // kabumm!
Sprich: Dein Code ist nicht benutzbar.

Das ist schon ne bessere Antwort, danke

Michael E.

RussianTux schrieb:

Ja das habe ich schon gehört, aber deutet jemand auch nur annähernd an was denn da sinnlos ist?! Das Programm funktioniert ohne Speicherleck, ist es nicht so?

Stell die Frage mal andersrum: Welchen Sinn hat es in deinem Beispiel, new zu benutzen? Das bedeutet nur Mehraufwand, denn auf einmal musst du die Regel der großen Drei berücksichtigen.

RussianTux schrieb:

Das ist schon ne bessere Antwort, danke

Heißt du hast verstanden, was genau an den "kabumms" passiert?

Nexus

RussianTux schrieb:

Übrigens: wenn ich das bewusst mache, muss es auch einen Grund dafür geben, ich mache mir nicht umsonst die Arbeit schwerer, oder für welchen Idioten hällst du mich, sag mir das mal.

Ich halte dich sicher für keinen Idioten. Ich habe auch nichts dergleichen gesagt, sondern nur, dass es dumm und unproduktiv sei, im Anwendungscode trotz besserem Wissen ständig new und delete zu verwenden. Das war nicht auf dich bezogen, schliesslich hast du ja nach der Problematik gefragt.

Den Grund, wieso du dir das schwerer machst, würde ich gerne erfahren. Mir ist schon klar, dass du momentan lernen willst, wie Zeiger funktionieren, und deshalb auf unique_ptr verzichtest. Doch du hast das verallgemeinert ("delete ist bei richtiger Verwendung kein Problem"). Bezüglich Low-Level meinte ich vor allem, dass dich die Abstraktionsebene nicht per se davon abhält, unique_ptr zu benutzen (oder notfalls selbst zu schreiben).

RussianTux

Nexus schrieb:

RussianTux schrieb:

Übrigens: wenn ich das bewusst mache, muss es auch einen Grund dafür geben, ich mache mir nicht umsonst die Arbeit schwerer, oder für welchen Idioten hällst du mich, sag mir das mal.

Ich halte dich sicher für keinen Idioten. Ich habe auch nichts dergleichen gesagt, sondern nur, dass es dumm und unproduktiv sei, im Anwendungscode trotz besserem Wissen ständig new und delete zu verwenden. Das war nicht auf dich bezogen, schliesslich hast du ja nach der Problematik gefragt.

Den Grund, wieso du dir das schwerer machst, würde ich gerne erfahren. Mir ist schon klar, dass du momentan lernen willst, wie Zeiger funktionieren, und deshalb auf unique_ptr verzichtest. Doch du hast das verallgemeinert ("delete ist bei richtiger Verwendung kein Problem"). Bezüglich Low-Level meinte ich vor allem, dass dich die Abstraktionsebene nicht per se davon abhält, unique_ptr zu benutzen (oder notfalls selbst zu schreiben).

Nagut, alles klar

dot

Man sollte nochmal festhalten, dass "low-level" nicht bedeutet, dass man delete händisch aufruft. Das hat überhaupt nichts damit zu tun. Ich würde dir raten, einfach mal deinen eigenen Smartpointer zu schreiben. Allerdings richtig, solange du eine Methode aufrufen musst um den Speicher freizugeben, hast du nichts besser gemacht als wenn du einfach direkt delete aufrufen würdest. Der Trick ist eben gerade, dass das delete im Destruktor des Smartpointers aufgerufen wird und der Smartpointer selbst nur einen Pointer enthält und am Stack angelegt wird. Dann stellt nämlich der Compiler sicher, dass das delete immer und unter allen Umständen aufgerufen wird, ohne dass du dich darum kümmern musst. Und genau in solchen Dingen liegt die wahre Macht von C++, nämlich dass du dir so einen Mechanismus bauen kannst ohne die Möglichkeit zur "low-level" Programmierung aufzugeben und der generierte Code ist, wenn du's richtig machst, trotzdem mindestens gleich effizient als wenn du selbst überall delete hingeschrieben hättest, da der Compiler alles inlinen wird. Smartpointer und RAII im Allgemeinen hindern einen nicht an der "low-level" Programmierung, sie unterstützten einen dabei...