Zeiger = 0;

RussianTux

Nexus schrieb:

RussianTux schrieb:

Aber das ist doch keine Schuld des Operators?! Es ist das Problem des Programmierers ob er Fehler macht oder nicht

Nein.

Manuelle Speicherverwaltung ist ein Sprachmittel, das -- wenn es im normalen Anwendungscode verwendet wird -- eine enorme Fehleranfälligkeit provoziert. In vielen Situationen haben machen selbst Programmierer, die new und delete kennen müssten, Fehler, siehe Beispiel von dot.

1. Im Beispiel von Dot handelt es sich nicht um meinen Code den ich schreiben würde.
2. Ich habe auch nicht vor im ganz normalen Code new und delete zu nutzen, nur in einigen Spezialfällen, einen davon habe ich oben als Beispiel angegeben, was ist denn so schwer daran zu verstehen?
3. Das heißt nicht sofort dass jeder automatisch Fehler machen muss, ob ich das mache oder nicht ist mein Problem, meine Frage richtete sich nur auf Funktionalität und Theorie der Zeiger.

Nexus schrieb:

RussianTux schrieb:

2. Mein Ziel ist es nicht möglichst viel Zeit zu sparen nach dem Motto: "Hauptsache es läuft richtig", mein Ziel ist schon von Anfang an die Low-Level Programmierung gewesen.

Natürlich besteht die Hauptsache darin, dass ein Programm richtig läuft. Ich weiss gar nicht, wie man das anders sehen kann. Ein Programm, das nicht macht, was es soll, ist nutzlos.

Ja die Hauptsache ist in der tat das korrekte Verhalten des Programms, jedoch kann man sich z.b. Zeit ersparen wenn man die Mittel der Standardbibliothek nutzt und nicht selbst sozusagen das Rad erfindet.

Nexus schrieb:

Und nein, du willst nicht Low-Level-Programmierung

Und noch mal bin ich gezwungen diese Worte zu wiederholen: Ich muss selber wissen was ich vor habe.

Nexus schrieb:

zumindest nicht so wie du den Begriff verstehst.

Warum bist du dir denn so sicher dass ich keinen blassen Schimmer davon habe, was dies bedeuten könnte? Vielleicht begründest du ja deine Meinung?

Nexus schrieb:

Es spricht rein gar nichts dafür, im normalen Code dauernd new und delete zu verwenden und bewusst auf die besseren Alternativen wie std::unique_ptr zu verzichten. Warum sollte man das tun, wenn man die Problematik kennt? Sowas ist dumm und unproduktiv.

Siehe oben 2.

Ü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.

Kellerautomat

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

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...