3. nicht initialisierter Pointer auf Klasse

nicht initialisierter Pointer auf Klasse

  • N

    Jeder erfahrene C++ Programmierer weiß doch, das man die implemtierung jeder Memberfunktion noch wie folgt schützt.

    if(!this) return;

    Wer Ironie findet, kann sie behalten.

    0

  • De facto ist das ja eine "static"-Methode, da nicht auf Member (der Instanz) zugegriffen wird - und daher ist der this-Parameter (welcher auf Maschinencode-Ebene an die Funktion übergeben wird) unbenutzt und daher knallt es nicht.

    0
  • O

    Th69 schrieb:

    De facto ist das ja eine "static"-Methode, da nicht auf Member (der Instanz) zugegriffen wird - und daher ist der this-Parameter (welcher auf Maschinencode-Ebene an die Funktion übergeben wird) unbenutzt und daher knallt es nicht.

    ja kann ich bestätigen wenn ich in der f1() auf eine membervariable der Klasse zugreifen möchte gibt es einen Absturz. Mich wundert nur das C++ sowas zulässt, bzw man es nicht verhindern kann.

    0

  • offensiv schrieb:

    [...] Mich wundert nur das C++ sowas zulässt, bzw man es nicht verhindern kann.

    Nimm lieber BASIC ...

    0
  • O

    Swordfish schrieb:

    offensiv schrieb:

    [...] Mich wundert nur das C++ sowas zulässt, bzw man es nicht verhindern kann.

    Nimm lieber BASIC ...

    Danke für den wertvollen Hinweis zum Thema.

    0
  • ?

    Swordfish schrieb:

    Nimm lieber BASIC ...

    Ich hätte eher Java gesagt. Da wird dir vorgeschrieben wie du wann auf was zugreifen darfst, immer schön "safe". Ist natürlich mit entsprechenden Kosten verbunden, aber so schlimm sind die nicht. Ernsthaft, C++ schützt dich nicht vor Fehlern sondern führt jeden Mist aus den du schreibst (solange es nicht widersprüchlich ist oder nicht geht). Entweder du akzeptierst das oder du nimmst eine andere Sprache.

    0

  • nwp3 schrieb:

    Swordfish schrieb:

    Nimm lieber BASIC ...

    Ich hätte eher Java gesagt.[...]

    Bloß nicht! Da gibt es phöse NullPointerException s ...

    0
  • Mod

    @Th69: Das ist keine static -Methode (oder benutzt man das Wörtlein static auch in einem anderen Zusammenhang als als storage-specifier?). Es ist einfach eine Methode bei der nicht auf Member-Variablen zugegriffen wird. Da kann (und wird) der this -Parameter wegoptimiert werden, was dazu führt, dass das Objekt-Argument - wenn keine Seiteneffekte vorhanden sind - ebenfalls komplett wegoptimiert wird. Dadurch verschwindet auch der Teil der zu undefiniertem Verhalten führt. Laut Standard AFAICS nach wie vor ein Programm mit undefiniertem Verhalten - den interessiert ja keine Optimierung, von der erwartet er ja ein as-if Verhalten.

    Bei C/C++ gibt es nun mal einen großen Speed <> Safety Tradeoff.

    @Swordfish: Unterlass bitte dein Getrolle.

    0

  • Arcoth schrieb:

    Das ist keine static -Methode [...]

    Nochmal, extra für dich:

    Th69 schrieb:

    De facto ist das ja eine "static"-Methode, [...]

    Arcoth schrieb:

    [...] Da kann (und wird) der this-Parameter wegoptimiert werden, [...]. Dadurch verschwindet auch der Teil der zu undefiniertem Verhalten führt. Laut Standard AFAICS nach wie vor ein Programm mit undefiniertem Verhalten - den interessiert ja keine Optimierung, von der erwartet er ja ein as-if Verhalten.

    Was redest du von irgendwelchen Optimierungen und as-if?!

    ISO/IEC 14882-2011 (n3337) schrieb:

    24.2.1.5

    [...][Example: After the declaration of an uninitialized pointer x (as with int x;), x must always be assumed to have a singular value of a pointer.* —end example] Results of most expressions are undefined for singular values; [...] Dereferenceable values are always non-singular.

    mybase des OP ist also nicht dereferenzierbar. Was irgendeine bestimmte Implementierung daraus macht interessiert hier nicht und gehört allenfalls ins Compiler-/IDE-Forum, Herr Moderator.

    Arcoth schrieb:

    Unterlass bitte dein Getrolle.

    Ich trolle nicht.

    0
  • Mod

    Was irgendeine bestimmte Implementierung daraus macht interessiert hier nicht

    Nein? Merkwürdig. Ich dachte der Thread dreht sich um die Tatsache dass eine Implementierung ein ausführbares Programm generiert hat dass mit seiner Ausgabe den TE verwirrt hat. Es ging nie primär darum undefiniertes Verhalten nachzuweisen, sondern die Ausgabe zu erklären. Letzteres ist nur durch Berücksichtigung gängiger Implementierungen möglich.

    Dass ein potenziell singulärer Zeiger dereferenziert wird habe ich im Übrigen bereits selbst angemerkt. Leider hast du einen wichtigen Teil des Zitates vergessen.

    §24.2.1/10 schrieb:

    An invalid iterator is an iterator that may be singular.
    [Fußnote:]
    This definition applies to pointers, since pointers are iterators. The effect of dereferencing an iterator that has been invalidated is undefined.

    Wir wissen nämlich nicht ob der Zeiger auch singulär ist. Da er es aber sein kann, wird der Fall durch obiges Zitat abgedeckt.

    Was redest du von irgendwelchen Optimierungen und as-if?!

    Wenn der Compiler einen Teil wegoptimiert, der undefiniertes Verhalten erzeugt hätte wenn er ausgeführt worden wäre, dann garantiert der Standard dafür (AFAICS) genauso wenig wie davor. Eben wegen as-if - das vom Compiler generierte Programm muss, wenn er bestimmte Dinge anders macht als der Standard es vorschreibt, das selbe warnehmbare Verhalten erzeugen. Wenn dazu solches gehört das vom Standard undefiniert ist, so bleibt dieses undefiniert - der Standard schreibt nach wie vor das Verhalten nicht vor, oder? 🙂

    Swordfish schrieb:

    Nochmal, extra für dich:

    Das Objekt-Argument muss vorhanden sein und wird ausgewertet, was zu undefiniertem Verhalten führt. Eine static-Methode hat keinen Objekt-Parameter.

    0
Anmelden zum Antworten