Ich möchte das Thema (diskutiert in diesem Beitrag) nochmal aufgreifen, weil mir immer noch nicht ganz klar ist, warum man NULL bevorzügen sollte. In diesem zusammenhang bin ich auf verschiedene Meinungen gestoßen. Manch einer behauptet das wär eine Geschmackssache, häufig stellen Leute keinen wesentlichen Unterschied fest, manche sagen man soll lieber 0 nehmen, manche NULL. Eins gibt mir aber zum Nachdenken. Wenn Makros direkt aus der Hölle kommen (was ich verstehen kann), warum wird dann NULL (auch von erfahrenen Programierern, die sich der Nachteile bewusst sind) so häufig verwendet?
In Stroustrup's "The C++ Programming Language" wird auch gegen NULL argumentiert. Wie ist es nun richtig?

Grüße,
Rewind

In C++0x (d.h. dem neuen Standard der voraussichtlich dieses Jahr erscheint) wird es auch einen speziellen Nullzeiger geben, der die Diskussion ein für alle Mal beenden sollte.

Jedenfalls gibt es in C++0x dann nullptr welchen mann dann zweifellos NULL vorziehen sollte.

sieht einfach verdammt cool aus

Der neuste Stand nach 0x ist eh nullptr mit Typsicherheit und so.

nullptr hab ich lange erwartet und nutze ihn jetzt auch nur noch, trotz fehlender abwärtskompatiblität...

sieht einfach verdammt cool aus

#define nullptr 0

Löst das Problem in 99% der Fälle.

Hab ihn: http://www.c-plusplus.net/forum/282374?highlight=null

Super, danke dir. Wobei ich besagten Thread irgendwie inhaltsamer in Erinnerung hatte .

#define nullptr 0

Löst das Problem in 99% der Fälle.

Ich dachte, nullptr sei nur für diese 1% gedacht. Ihn ständig zu schreiben ist umständlich und hässlich, ich bleib lieber bei meiner schlichten 0.

Und wenn schon, dann nimmt man das nullptr -Template von Meyers, kein define.

Eisflamme schrieb:

Hab ihn: http://www.c-plusplus.net/forum/282374?highlight=null

Super, danke dir. Wobei ich besagten Thread irgendwie inhaltsamer in Erinnerung hatte .

Hm, ja, ich auch. Hätte zumindest gedacht, dass da noch ein Verweis auf nen anderen Thread ist. Na was soll's, zumindest einige Infos findet man da.

Object* object = new Object();
...
if (object != nullptr) {...}

oder

if (object) {...}

schreibe? Ich benutze die erste Variante würde mir aber die zusätzliche Schreibarbeit auch sparen wenn beides vom Compiler gleich behandelt wird.

if (object != nullptr) {...}

meint er glaub ich schon woanders. z.b. in anderen Methoden

ich schreib auch immer so

if (object) {...}

Ich habe auch eine Frage zum nullptr. Macht es einen Unterschied ob ich

Object object = new Object();
if (object != nullptr) {...}

oder

if (object) {...}

schreibe? Ich benutze die erste Variante würde mir aber die zusätzliche Schreibarbeit auch sparen wenn beides vom Compiler gleich behandelt wird.

Ohne Gewähr: Da dem Standardisierungskomitee sehr daran gelegen ist, die Bedeutung von vorhandemem Code nicht zu verändern, wird bei if (object) das Objekt object in einen bool umgewandelt, sodass letztlich nur geprüft wird, ob object auf 0 zeigt. Das ist semantisch nicht dasselbe wie eine Prüfung auf nullptr.

Ohne Gewähr: Da dem Standardisierungskomitee sehr daran gelegen ist, die Bedeutung von vorhandemem Code nicht zu verändern, wird bei if (object) das Objekt object in einen bool umgewandelt, sodass letztlich nur geprüft wird, ob object auf 0 zeigt. Das ist semantisch nicht dasselbe wie eine Prüfung auf nullptr.

Ohne Gewähr: Ich dachte, primitive Typen haben keine operator bool und werden direkt auf 0 überprüft. Ein != nullptr wäre dann semantisch genauso unsinnig wie ein != false bzw. ein == true . Letztendlich ist es in meinem Verständnis das selbe ...

Ohne Gewähr: Ich dachte, primitive Typen haben keine operator bool

int main()
{
	static_cast<bool>(42);
}

und werden direkt auf 0 überprüft.

Ich hab aber nirgends eine 0 geschrieben.

Ein != nullptr wäre dann semantisch genauso unsinnig wie ein != false bzw. ein == true .

Ergibt alles Sinn.

Letztendlich ist es in meinem Verständnis das selbe ...

nullptr tut mehr als zu prüfen, ob der Zeiger auf 0 zeigt.

Ich habe auch eine Frage zum nullptr. Macht es einen Unterschied ob ich

Object object = new Object();

Das ist kein C++. Nehmen wir an, 'object' sei ein roher Zeiger...

Student83 schrieb:

if (object != nullptr) {...}

oder

if (object) {...}

schreibe?

Das macht keinen Unterschied.

Ohne Gewähr: Da dem Standardisierungskomitee sehr daran gelegen ist, die Bedeutung von vorhandemem Code nicht zu verändern, wird bei if (object) das Objekt object in einen bool umgewandelt, sodass letztlich nur geprüft wird, ob object auf 0 zeigt. Das ist semantisch nicht dasselbe wie eine Prüfung auf nullptr.

So habe ich mir das auch vorgestellt.

krümelkacker schrieb:

Das ist kein C++. Nehmen wir an, 'object' sei ein roher Zeiger...

Deine Annahme ist richtig, war schon spät und ich hab das * vergessen.

krümelkacker schrieb:

Das macht keinen Unterschied.

Alles klar, hätte ich nicht gedacht.

Student83 schrieb:

Ich habe auch eine Frage zum nullptr. Macht es einen Unterschied ob ich

Object object = new Object();

Das ist kein C++.

class Object
{
    public:
    Object();
    Object(Object *parent);
};

krümelkacker schrieb:

Student83 schrieb:

Ich habe auch eine Frage zum nullptr. Macht es einen Unterschied ob ich

Object object = new Object();

Das ist kein C++.

class Object
{
    public:
    Object();
    Object(Object *parent);
};

Seine Aussage, das es kein C++ sei, ist vollkommen korrekt. Das kann man vielleicht in C# oder Java so schreiben.

In C++ muss man dafür ein Zeiger haben und die () sind bei leerer Parameterliste auch nicht korrekt.

Object *obj = new Object;

#define nullptr 0

Löst das Problem in 99% der Fälle.

Verwende NULL , wenn dir das reicht. Das Nullzeigerliteral nullptr wird eingeführt, gerade weil NULL einige Unzulänglichkeiten mit sich bringt (z.B. dass es ein int ist).

Gibt es eigentlich irgendwas, was gegen NULL spricht, außer dass es ein int ist, wenn man den neuen Standard nicht hat?

1. Die Verwendung von NULL gibt keine zusätzliche Typsicherheit, d.h. man kann z.B. nach wie vor einer Funktion versehentlich NULL übergeben, wenn an der Stelle eigentlich ein int o.ä. gefordert war. In Zeiten von IDEs mit Calltips passiert sowas allerdings ohnehin kaum mehr.
2. Ist länger als 0.

Dass man NULL jedoch mit einer einzigen Ersetzaktion im gesamten Projekt zu nullptr ändern kann (und notfalls auch wieder zurück) ist allerdings ein absolutes K.O.-Argument, das für NULL spricht.