seid gegrüßt!

habe folgendes Problem:

struct example {
...
...
};

example* pointer; 
pointer = NULL;

if (pointer == NULL) {     // hier kommt die Fehlermeldung
...
...

}

Also nun frage ich mich, wie kann ich die folgende Bedinung

if (pointer == NULL)

äquivalent umsetzen, so dass der Compiler das auch versteht was ich will
Bzw. was muss ich machen, damit ich den Compiler mal endlich verstehe.

Danke schonmal für etwaiger Antworten

VG

Bzw. was muss ich machen, damit ich den Compiler mal endlich verstehe.

Die Fehlermeldung lesen. Oder sie hier posten und erklären lassen.

tschuldigung für die etwas unpräzisen Angaben, nächstes mal mache ich es besser.
Habe die Fehlmeldung erst nicht verstanden... Aber jetzt ist alles klar...
kann also geschlossen werden

/close

für null zeiger immer nullptr verwenden!

0

ist kürzer.

0

ist kürzer.

Meinst du das ernst?

Allgemein muss ich sagen dass ich in C++ sehr selten in die Verlegenheit gerate einen Null-Zeiger zu erzeugen. Und wenn dann ist der Kontext klar und nullptr bringt mir keine Vorteile gegenüber 0.

nullptr

eine einheitliche Lösung für Zeiger 0, NULL, null, (void*)0 usw

ist sowieso viel besser

boost::optional <>

ist sowieso viel besser

Hängt wohl vom Einsatzgebiet ab. Wenn man den Wert per Value möchte dann recht sicher, ja.

Ethon schrieb:

Swordfish schrieb:

Ethon schrieb:

/* [ */ ptr == /* ]*/ 0

!ptr

ist kürzer.

Ja genau.
Prüfen per impliziter Umwandlung nach bool.

Wahrscheinlich bin ich einfach nur ignorant oder steh auf diversen Leitungen. Was könnte daran schiefgehen?

Nichts.

Den gleichen Vorteil haben "= default" und "= delete" in C++11.

Den gleichen Vorteil haben "= default" und "= delete" in C++11.

Quatsch. Das defaulten von bspw. Kopier- bzw. Move-konstruktoren spart viel Schreibarbeit.

nullptr hat den Vorteil, daß es die Intention des Programmierers für Leser explizit macht.

Nö, das hat NULL auch schon gemacht. nullptr 's hauptsächlicher Vorteil ist overload resolution.

großbuchstaben schrieb:

Den gleichen Vorteil haben "= default" und "= delete" in C++11.

Quatsch. Das defaulten von bspw. Kopier- bzw. Move-konstruktoren spart viel Schreibarbeit.

der Ton deines Postings gefällt mir nicht. Weniger, weil ich im Internet geschliffene Umgangsformen erwarte, sondern mehr, weil Postings in rüdem Ton oft auch inhaltlich noch Raum zur Optimierung lassen. Aber ich investiere dennoch die zwei Minuten, um zu antworten.

was = delete und = default angeht, verweise ich auf Stroustrups C++11faq, Abschnitt "control of defaults: default and delete"

Arcoth schrieb:

nullptr hat den Vorteil, daß es die Intention des Programmierers für Leser explizit macht.

Nö, das hat NULL auch schon gemacht. nullptr 's hauptsächlicher Vorteil ist overload resolution.

was nullptr angeht, verweise ich auf das dort verlinkte `A name for the null pointer`.

However, comments about copy operations and (worse) a user explicitly defining copy operations meant to give the default behavior are not uncommon. Leaving it to the compiler to implement the default behavior is simpler, less error-prone, and often leads to better object code.

Steht irgendwo etwas davon dass die Intentionen des Programmierers durch dieses Feature besser zu Tage kommen? Auch ein privat deklarierter Konstruktor oder Zuweisungsoperator gibt eigentlich dieselbe Message. Ja, es ist auch Syntaxzucker für frühere Dinge. Aber das ist nicht wichtig. Wichtig ist, dass man damit Dinge deutlich vereinfachen kann.

Konnte man etwa in C++03 Funktionen oder implizite Konvertierungen bei Funktionsaufrufen "deleten"? Bei Funktionstemplates ging das noch durch SFINAE (bzw. konnte man ja einfach per Traits was testen), aber für normale Funktionen war so etwas AFAIR nicht möglich.

Zu nullptr :

N1488 schrieb:

The result will be more readable code [Syntaxzucker, vollkommen uninteressant], better error detection [Tjoa], and better overload resolution [aha! ].

Schau nur, wie schon std::nullptr_t in die Standardbibliothek integriert wurde, bei Konstruktoren wie dem von Smart-Zeigern oder std::function .

The following example illustrates additional use cases: the ternary operator, overload resolution, and template specialization.

Vieles mehr als nur Syntaxzucker, der Intentionen verbirgt, nicht wahr? NULL war auch allbekannt. Wusste jeder drum. Von der Intention her war alles implizit klar. Das Problem mit NULL war aber nicht die gutherzige Intention des Programmierers.

Ich habe übrigens gerade festgestellt, dass du nie angedeutet hast, dass der wesentliche Vorteil von nullptr (und dem defaulten und deleten von Funktionen) darin bestünde, dass sie die Intention festlegen (was ich dank meinem beherzten Temperament implizit annahm). Daher entschuldige ich mich für mein unangebrachtes Verhalten.

Ich habe übrigens gerade festgestellt, dass du nie angedeutet hast, dass der wesentliche Vorteil von nullptr (und dem defaulten und deleten von Funktionen) darin bestünde, dass sie die Intention festlegen (was ich dank meinem beherzten Temperament implizit annahm). Daher entschuldige ich mich für mein unangebrachtes Verhalten.

angenommen