#include <iostream>
using namespace std;

class Base
{
  public:
    void f1() { cout << "Base::f1()" << endl; }
};

int main()
{
    Base *mybase;
    mybase->f1();  // gibt "Base::f1()" aus.
    return 0;
}

ich frage mich warum das funktioniert. Warum erkennt der Compiler
nicht das mybase noch gar nicht initialsiert ist? ( in der Form
Base *mybase = new Base; )

Grüsse Mirko

Dein Programm erzeugt undefiniertes Verhalten, es könnte theoretisch auch deine Festplatte formatieren. Dass es genau das ausgibt war eben Glück. Alle Zeiger bei der Definition nullen oder schon auf ein gültiges Objekt zeigen lassen, dann kannst du ganz einfach mit (ptr == 0) prüfen ob er gültig ist. (Dangling pointers jedoch vermeiden!)

wenn ich das mache:

Base *mybase = 0;

gibt er den Text trotzdem noch aus. Muss ich also jedes mal den Zeiger prüfen bevor ich einen Methodenaufruf mache? Oder gibt es da noch eine Compileroption
um den Fehler beim compilieren zu erkennen?

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.

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.

if(!this) return;

Wer Ironie findet, kann sie behalten.

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.

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

Nimm lieber BASIC ...

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.

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.

Swordfish schrieb:

Nimm lieber BASIC ...

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

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

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

@Swordfish: Unterlass bitte dein Getrolle.

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.

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.