3. NULL Zeiger und Vergleichsoperator

NULL Zeiger und Vergleichsoperator


  • ...

    0
  • E

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

    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.

    0
  • ?

    C++11:

    nullptr

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

    0 

  • boost::optional <>

    ist sowieso viel besser

    0
  • E

    Tim06TR schrieb:

    boost::optional <>

    ist sowieso viel besser

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

    0

  • ...

    0
  • E

    Swordfish schrieb:

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

    0
  • ?

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

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

    0
  • Mod

    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.

    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.

    0
  • ?

    Arcoth schrieb:

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

    0
  • Mod

    Auch delete ist übrigens ebenfalls primär für Overload-Resolution eingeführt worden, und weniger nur für special member functions. Defaulten spart mir die selbstständige Definition eines Move-Konstruktors, wenn ein User-definierter Kopierkonstruktor vorhanden ist (und der compiler-generierte Move-Konstruktor sicher ausreicht, aber leider standardmäßig als deleted definiert wird).

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

    0
  • ?

    Arcoth schrieb:

    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 🙂 👍

    0
Anmelden zum Antworten