NULL und 0

Ethon_ schrieb:

#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

SeppJ schrieb:

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.

Student83

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.

314159265358979

Ein normales new gibt nie 0 zurück, es wirft eine Exception. Aber ja, in diesem Fall ist es gleichwertig.

xBlackKnightx

mit der zeile

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

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

ich schreib auch immer so

if (object) {...}

Michael E.

Student83 schrieb:

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.

Michael E. schrieb:

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

Michael E.

gewehr schrieb:

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.

krümelkacker

Student83 schrieb:

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.

Student83

Michael E. schrieb:

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.

wxSkip

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);
};

wxSkip schrieb:

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;

314159265358979

http://ideone.com/xRmN0

wxSkip

... und die Klammern bei new Object() sind auch korrekt.

Nexus

Ethon_ schrieb:

#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?
0 und #define nullptr 0 sind auch int.
NULL läßt sich auch viel einfacher zu nullptr ändern als 0, wenn man mal den neuen Std hat.

Athar

FutterBeidieTische schrieb:

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.