3. nicht initialisierter Pointer auf Klasse

nicht initialisierter Pointer auf Klasse

  • ?

    offensiv schrieb:

    Warum erkennt der Compiler nicht das mybase noch gar nicht initialsiert ist?

    Weil er dafür nicht gemacht ist. Compiler sollen schnell schnellen und korrekten Code produzieren und gehen dabei davon aus, dass du ihnen korrekten Code vorlegst. Wenn der Compiler beim kompilieren über was stolpert was nicht geht, dann wird er es dir sagen, aber das ist Bonus. Für Fehlersuche hat er keine Zeit. Wenn du automatisch Fehler finden möchtest sieh dir static code analyzer wie cppcheck an.

    offensiv schrieb:

    Muss ich also jedes mal den Zeiger prüfen bevor ich einen Methodenaufruf mache?

    Sorge dafür, dass immer alle Zeiger gültig sind und spare dir das Prüfen. Wenn du es unbedingt brauchst kannst du nullptr benutzen, aber das zieht viel nervigen redundanten fehleranfälligen Code hinterher.

    0
  • Mod

    Dein Programm erzeugt undefiniertes Verhalten,

    Weil Zeiger die singulär sein können per Definition ungültig sind und folglich nicht dereferenziert werden dürfen, was aber durch den -> -Operator implizit passiert, oder?

    es könnte theoretisch auch deine Festplatte formatieren

    Dass der Standard nichts dazu sagt, heißt nicht automatisch, dass der generierte Maschinencode auf Zufall beruht. In manchen Fällen passieren vielleicht verrückte Dinge, hier aber nicht (Implementierungen definieren AFAIR das Verhalten in diesem Fall).

    Dass es genau das ausgibt war eben Glück.

    Nicht wegen dem Maschinencode?
    Das ganze resultiert höchstwahrscheinlich (bzw. bei fast allen Implementierungen) einfach in einem Aufruf mit 0 als Argument für this (oder es wird mehr wegoptimiert), wenn ich mich nicht irre?

    @TE: Geh mal mit dem Debugger durch, da könnte dir sehr schnell klar werden was da passiert.

    0
  • 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