Zeiger = 0;

[Kellerautomat]

Hacker schrieb:

@Kellerautomat: Wieso Pufferst du da? Du brauchst doch tmp gar nicht.

Weißt du überhaupt, was puffern ist?
Ohne scheiß, hör mal auf zu posten. Deine restlichen Posts sind auch voller Humbug.

Und um deine falsch gestellt Frage zu beantworten: Exception-Safety. Stichwort: Starke Garantie.

Michael E. schrieb:

Kellerautomat: Dein Code tut nicht mal mehr dasselbe.

Hab ich irgendwo was falsch kopiert? Hab darauf jetzt nicht geachtet.

Michael E. schrieb:

Ganz davon abgesehen, dass dein Code nicht Exception-safe ist.

Wo denn?

[hustbaer]

RussianTux schrieb:

ich weiß was ich tue

nicht mal annähernd

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.

siehe oben. da du keine ahnung hast wovon du redest, ...

aber ist gut dass du dich so gut mit Hacker verstehst. der hat auch keinen tau von irgendwas, kann dir also im keinen-tau-haben gut weiterhelfen.

[RussianTux]

hustbaer schrieb:

RussianTux schrieb:

ich weiß was ich tue

nicht mal annähernd

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.

siehe oben. da du keine ahnung hast wovon du redest, ...

aber ist gut dass du dich so gut mit Hacker verstehst. der hat auch keinen tau von irgendwas, kann dir also im keinen-tau-haben gut weiterhelfen.

Ich bin oben das Beispiel Schritt für Schritt durchgegangen und der Theorie zur Folge müsste es doch keinen Speicherleck geben? Wäre besser wenn du mir hierbei helfen würdest anstatt andere anzuprangern die vielleicht so wenig Ahnung haben wie ich

[Michael E.]

Kellerautomat schrieb:

Hab ich irgendwo was falsch kopiert? Hab darauf jetzt nicht geachtet.

Betrachte mal den Ablauf, wenn hell_yeah() zu false evaluiert wird. Oder wenn bla == true ist. Oder...

Michael E. schrieb:

Ganz davon abgesehen, dass dein Code nicht Exception-safe ist.

Wo denn?

Z.B. double delete bei hell_yeah() == true, hohoho() == true, bla == false, solo == true . Oder der einfachste Fall, wenn hell_yeah() == false .

[Kellerautomat]

Michael E. schrieb:

Z.B. double delete bei hell_yeah() == true, hohoho() == true, bla == false, solo == true . Oder der einfachste Fall, wenn hell_yeah() == false .

Also gut, es fehlt ein delete nach dem try-catch. Aber sonst seh ichs grad nicht.

[Michael E.]

Kellerautomat schrieb:

Also gut, es fehlt ein delete nach dem try-catch.

Nicht nach dem catch, sondern am Ende des try-Blocks.

Aber sonst seh ichs grad nicht.

Mit den eben genannten Parametern hast du folgenden Ablauf:

void a(int* x)
{
  if (bla)                                                          // 9
    return;

  if (solo)                                                         // 10
    throw std::runtime_error("i have a bad feeling about this");    // 11
}

void get_santa(int* x)
{
  if (hohoho())                                                     // 4
  {
    int* tmp = new int(42);                                         // 5
    delete x;                                                       // 6 -> erstes delete
    x = tmp;                                                        // 7
    a(x);                                                           // 8
  }
}

void foo()
{
  int* x = new int;                                                 // 1

  try
  {
    if (hell_yeah())                                                // 2
      get_santa(x);                                                 // 3
  }

  catch(...)                                                        // 12
  {
    delete x;                                                       // 13 -> zweites delete auf demselben Objekt
    throw;
  }
}

Weitere Fehler nenne ich, wenn du zum Originalcode äquivaltenten Code schreibst.

[Kellerautomat]

Michael E. schrieb:

Nicht nach dem catch, sondern am Ende des try-Blocks.

Das ist doch genau dasselbe.

Michael E. schrieb:

Mit den eben genannten Parametern hast du folgenden Ablauf:

void a(int* x)
{
  if (bla)                                                          // 9
    return;

  if (solo)                                                         // 10
    throw std::runtime_error("i have a bad feeling about this");    // 11
}

void get_santa(int* x)
{
  if (hohoho())                                                     // 4
  {
    int* tmp = new int(42);                                         // 5
    delete x;                                                       // 6 -> erstes delete
    x = tmp;                                                        // 7
    a(x);                                                           // 8
  }
}

void foo()
{
  int* x = new int;                                                 // 1

  try
  {
    if (hell_yeah())                                                // 2
      get_santa(x);                                                 // 3
  }

  catch(...)                                                        // 12
  {
    delete x;                                                       // 13 -> zweites delete auf demselben Objekt
    throw;
  }
}

Und bei 7 wird ein neuer Wert zugewiesen, also nirgens double delete.

[Nexus]

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.

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.

Und nein, du willst nicht Low-Level-Programmierung, zumindest nicht so wie du den Begriff verstehst. 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.

[Th69]

Hallo Kellerautomat,

Kellerautomat schrieb:

Und bei 7 wird ein neuer Wert zugewiesen, also nirgens double delete.

Aber du weist in get_santa() nur der lokalen Variablen x einen neuen Wert zu (und das x aus foo() hat immer noch seinen ursprünglichen Wert)

[Ethon]

Man braucht garnicht zu diskutieren, durch die Anwesenheit von Exceptions ist RAII Pflicht. Du kannst praktisch nie sicher wissen, ob eine Funktion wirft oder nicht.

Wieso zur Hölle legst du überhaupt etwas mit new an? Muss ich fast nie.

[Kellerautomat]

Th69 schrieb:

Hallo Kellerautomat,

Kellerautomat schrieb:

Und bei 7 wird ein neuer Wert zugewiesen, also nirgens double delete.

Aber du weist in get_santa() nur der lokalen Variablen x einen neuen Wert zu (und das x aus foo() hat immer noch seinen ursprünglichen Wert)

Ah, jetzt kommen wir der Sache schon näher.
Daran hab ich jetzt wirklich nicht gedacht, sollte natürlich ein int*& sein...

[Michael E.]

Kellerautomat schrieb:

Michael E. schrieb:

Nicht nach dem catch, sondern am Ende des try-Blocks.

Das ist doch genau dasselbe.

In diesem Fall hast du Recht, weil du weiterwirfst. Im Allgemeinen macht es natürlich einen Unterschied.

Versucht sich noch jemand an der Aufgabe von dot? Bis jetzt wurde noch keine zufriedenstellende Lösung gepostet.

[Ethon]

So vielleicht?

void foo()
{
    int* x = new int;

    decltype(hell_yeah()) result;
    try
    {
        result = hell_yeah();
    }
    catch(...)
    {
        delete x;
        throw;
    }

    if(result)
        goto get_santa;

    // ...

a:

    if (bla)
    {
        delete x;
        return;
    }

    if (solo)
    {
        delete x;
        throw std::runtime_error("i have a bad feeling about this");
    }

    // ...

    delete x;
    return;

get_santa:
    try
    {
        decltype(hohoho()) result;
        try
        {
            result = hohoho();
        }
        catch(...)
        {
            delete x;
            throw;
        }

        if(result)
        {
            delete x;
            x = new int(42);
            goto a;
        }
    }
    catch(std::bad_alloc const& e)
    {
        throw;
    }

    delete x;
}

[Michael E.]

Ethon schrieb:

So vielleicht?

bla kann bei der Konvertierung zu bool werfen. decltype(hell_yeah()) muss nicht default-constructible sein.

[Ethon]

bla ist doch nirgendswo definiert, deswegen bin ich von einem Integer ausgegangen.
Die if-Abfrage müsste man einfach in das try hineinziehen, dann hat man doch Problem mit nicht-defaultkonstruierbaren Typen nicht.

[Michael E.]

Ethon schrieb:

bla ist doch nirgendswo definiert, deswegen bin ich von einem Integer ausgegangen.

Die Aufgabenstellung war "immer und unter allen Umständen". Deshalb darfst du nicht vom einfachsten Fall ausgehen :p

Die if-Abfrage müsste man einfach in das try hineinziehen, dann hat man doch Problem mit nicht-defaultkonstruierbaren Typen nicht.

Willst du dann auf den ganzen decltype-Kram verzichten oder wie ist das gemeint?

[Ethon]

Hmm so? Denke es wird noch fälscher sein, da das irgendwie den Kopf zum Rauchen bringt:

void foo()
{
    int* x = new int;

    try
    {
        if(hell_yeah())
            goto get_santa;
    }
    catch(...)
    {
        delete x;
        throw;
    }

    // ...

a:
    bool bbla, bsolo;
    try
    {
        bbla = bla;
        bsolo = solo;
    }
    catch(...)
    {
        delete x;
        throw;
    }

    if (bbla)
    {
        delete x;
        return;
    }

    if (bsolo)
    {
        delete x;
        throw std::runtime_error("i have a bad feeling about this");
    }

    // ...

    delete x;
    return;

get_santa:
    bool bhohoho;
    try
    {
        bhohoho = hohoho();
    }
    catch(...)
    {
        delete x;
        throw;
    }

    if(bhohoho)
    {
        delete x;
        x = new int(42);
        goto a;
    }

    delete x;
}

[Michael E.]

Sieht schon besser aus, wobei ich natürlich nicht ausschließen möchte, dass ich etwas bzgl. Exceptions übersehen habe.

Kommen wir also nun zum nächsten Teil. Du hast einige lokale Variablen eingeführt. Sie können einen Stack Overflow provozieren.

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