Kurze Frage: Ist nulptr/NULL garantiert immer "0" ?



  • Nabend!

    Joa, das ist die Frage. Ich bin bislang immer davon ausgegangen, aber nur weil ich das nie hinterfragt habe.. Kann mir jemand evtl. mit einem Beleg Gewissheit verschaffen?

    Konkretes Bsp.: Kann ich garantiert identisches Verhalten erwarten, bei:

    if(ptr) //...
    //==
    if(ptr!=NULL) //...
    

    ?

    Und vielleicht noch als Anhängsel: Ist garantiert, dass nullptr == NULL ??

    MfG
    0xMöbius



  • Ja. (ptr ist dabei irgend ein Zeiger auf was, klar. Wenn ptr was anderes ist, kann man Quard und Komik überladen haben).



  • https://en.wikipedia.org/wiki/C%2B%2B11#Null_pointer_constant:

    If NULL is defined as 0 (which is usually the case in C++), the statement foo(NULL); will call foo(int), which is almost certainly not what the programmer intended, and not what a superficial reading of the code suggests.

    C++11 corrects this by introducing a new keyword to serve as a distinguished null pointer constant: nullptr. It is of type nullptr_t, which is implicitly convertible and comparable to any pointer type or pointer-to-member type. It is not implicitly convertible or comparable to integral types, except for bool. While the original proposal specified that an rvalue of type nullptr should not be convertible to bool, the core language working group decided that such a conversion would be desirable, for consistency with regular pointer types. The proposed wording changes were unanimously voted into the Working Paper in June 2008.



  • DankE. Dann bin ich ja beruhigt.
    ..Und nein, das sollte keine Fangfrage sein.. 😉

    Also ich finde die Länge des Wiki-Eintrags irgendwie demotivierend, was das C++11-Lernen angeht..



  • Du musst ja nicht alles auf einmal lernen. Angucken was es neues gibt, jede Neuigkeit so weit bis du meinst verstanden zu haben wofür sie gut ist, und dann nur diejenigen genauer angucken bzw. eben "lernen" die du glaubst am öftesten brauchen zu können.
    Und die dann halt verwenden.

    Und nach ein paar Monaten wieder drübergucken.

    Und je mehr du schon weisst/kennst, desto mehr Zeit kannst du dir dabei nehmen um zu versuchen zu verstehen warum Dinge deren Nutzen für dich nicht offensichtlich ist vielleicht doch ganz praktisch sein könnten. (Um zu vermeiden dass man etwas nicht lernt/verwendet, bloss weil man nicht sofort verstanden hat wozu es überhaupt gut ist/welches Problem es löst.)

    Bzw. natürlich auch wenn du in bestehendem Code was findet was du (noch) nicht kennst/verstehst -> nachlesen/-lernen.



  • 0xMöbius schrieb:

    Also ich finde die Länge des Wiki-Eintrags irgendwie demotivierend, was das C++11-Lernen angeht..

    Bei mir war es anders herum. Ich habe die gelesen und mich bei fast jedem Punkt gefreut, was man jetzt alles besser machen kann.



  • @Marthog
    Ich glaube das wird den meisten so gehen die C++ schon gut bis sehr gut kennen, daran interessiert sind gute/einfache/wartbare Programme zu schreiben und dafür auch gerne mal ein bisschen was dazulernen. Oder gar einige der Neuerungen schon aus Boost oder aus diversen der Standardisierung vorangegangenen Diskussionen/Vorträgen/... kennen.

    Leute die noch mit C++03 kämpfen (z.B. weil sie noch nicht genug Erfahrung damit haben) und/oder einfach kein Interesse daran haben noch etwas dazuzulernen wird C++11 aber eher abschrecken.

    Bei Möbius hab' ich den Eindruck dass er auch was C++03 angeht noch in der Lernphase ist, und verstehe daher wenn ihn die Menge der Neuerungen etwas demotiviert.

    ps
    @Möbius: Es gibt dann auch noch C++14 und C++17 kommt bald 😃



  • Schwierig da Prioritäten zu setzen.. Ist natürlich gut, wenn man soeine Zusammenstellung hat, aber trotzdem demotivierend..

    Marthog schrieb:

    Bei mir war es anders herum. Ich habe die gelesen und mich bei fast jedem Punkt gefreut, was man jetzt alles besser machen kann.

    Ich werde ja auch nur von der Länge erschlagen. Dass das alles Verbesserungen sind, davon gehe ich mal aus.
    Aber ich bin irgendwie gehemmt, altes C++ mit neuem zu mischen.

    hustbaer schrieb:

    Leute die noch mit C++03 kämpfen (z.B. weil sie noch nicht genug Erfahrung damit haben) und/oder einfach kein Interesse daran haben noch etwas dazuzulernen wird C++11 aber eher abschrecken.

    Bei Möbius hab' ich den Eindruck dass er auch was C++03 angeht noch in der Lernphase ist, und verstehe daher wenn ihn die Menge der Neuerungen etwas demotiviert.

    ps
    @Möbius: Es gibt dann auch noch C++14 und C++17 kommt bald 😃

    Naja, so nen ganz unbeschriebens Blatt bin ich, was C++ angeht, auch nicht mehr. Aber da ich das nicht auf traditionellem Weg gelernt habe, sondern alles im Selbststudium, kanns schon sein, dass da das eine oder andere bislang auf der Strecke geblieben ist..

    Die Wiki-Artikel zu C++14 und C++17 sind aber wesentlich kürzer. ...Ich glaub das lerne ich lieber direkt C++17 😉
    Außerdem muss man ja immer etwas Latenz für bugfreie Compiler einplanen..



  • 0xMöbius schrieb:

    Die Wiki-Artikel zu C++14 und C++17 sind aber wesentlich kürzer. ...Ich glaub das lerne ich lieber direkt C++17 😉

    Super Idee, die Standards bauen ja zum Glück nicht aufeinander auf. Also: neues Spiel, neues Glück :p


  • Mod

    0xMöbius schrieb:

    Außerdem muss man ja immer etwas Latenz für bugfreie Compiler einplanen..

    Die kann durchaus negativ sein. Die Compiler setzen neue Konzepte oft schon Jahre früher um, bevor sie dann offiziell standardisiert werden.



  • Fake oder Echt schrieb:

    Super Idee, die Standards bauen ja zum Glück nicht aufeinander auf.

    Ich hab nur drauf gewartet.

    Fake oder Echt schrieb:

    Also: neues Spiel, neues Glück :p

    Eben 😉

    SeppJ schrieb:

    Die kann durchaus negativ sein. Die Compiler setzen neue Konzepte oft schon Jahre früher um, bevor sie dann offiziell standardisiert werden.

    Ich meine beim gcc aufgeschnappt zu haben, dass erst der gcc ~4.7.xx (ca. 2013) ordentlich mit c++11 umgehen konnte. Ohne Gewähr - alles nur Hörensagen.


  • Mod

    0xMöbius schrieb:

    SeppJ schrieb:

    Die kann durchaus negativ sein. Die Compiler setzen neue Konzepte oft schon Jahre früher um, bevor sie dann offiziell standardisiert werden.

    Ich meine beim gcc aufgeschnappt zu haben, dass erst der gcc ~4.7.xx (ca. 2013) ordentlich mit c++11 umgehen konnte. Ohne Gewähr - alles nur Hörensagen.

    Hörensagen? Dann muss es ja richtig sein.



  • SeppJ schrieb:

    Hörensagen? Dann muss es ja richtig sein.

    Jetzt habe ich auch gehört, was du dazu sagst... Ich meine mich zu erinnern, dass es mehr Argumente dafür, als deine dagegen gegeben hat.
    Frag mich nicht welche das genau waren, aber bei dem zusätzlichen Funktionsumfang von C++11 nicht undenkbar, finde ich.
    Kann gut sein, dass es speziell um den MSVC ging - wäre ja nichts neues.. 😉


  • Mod

    Eigentlich hatte ich meinen Beitrag eher so gedacht, dass du dann vielleicht von selber darauf kommst, nach Fakten zu suchen. Schließlich hast du ja auch vor, C++ im Selbststudium zu lernen (sehr ambitioniert!), da gehören solche Fähigkeiten eigentlich dazu.

    Ich poste einfach mal eine Tabelle:
    http://en.cppreference.com/w/cpp/compiler_support
    Die Erscheinungsdaten der verschiedenen Versionen darfst du dir selber suchen, aber als Orientierung, welche Versionen Ende 2011 aktuell waren: GCC 4.6.2, Intel 12.1, MSVC 10.0, Clang 3.0(?).
    Die Liste der Features ist nicht vollständig und ich überlasse ebenfalls dir die Entscheidung, ab wann du einen gewissen Grad von C++11-Unterstützung als brauchbar ansiehst. Wobei ich aber zumindest den Tipp geben möchte, dass ein prozentuales Kriterium ("ab 50% implementierter Features ist die Implementierung brauchbar") vermutlich nichts taugt.



  • SeppJ schrieb:

    0xMöbius schrieb:

    Außerdem muss man ja immer etwas Latenz für bugfreie Compiler einplanen..

    Die kann durchaus negativ sein. Die Compiler setzen neue Konzepte oft schon Jahre früher um, bevor sie dann offiziell standardisiert werden.

    Jupp. Zum Beispiel decltype bzw __typeof__ und damit auto gabs auf gcc und msvc Jahre vorm Standard.

    Wenn ich es für absehbar halte, daß was kommen wird, code ich auch schonmal gegen die erwartete Sprache, also treffe Designentscheidungen in diese Richtung, obwohl der Code bis zum Feature dadurch umständlicher wird.



  • @SeppJ: Du scheinst nicht verstanden zu haben, worum es geht. Eine Feature-Tabelle zum Thema Bugs. Dazu fällt mir nur ein: "It's not a bug, it's a feature."
    Trotzdem Danke für deinen Rat, im Selbststudium selbst nach etwas suchen zu sollen (was wäre noch gleich die Alernative?).
    Dir scheint das Thema wichtiger zu sein, als mir. Also werde selbst aktiv, oder lass es. Im Gegensatz zu dir erwarte ich von dir mir gegenüber auch keine Rechenschaft (nebenbei einer der Vorteile eines Selbststudiums). Im Übrigen bedeute "ohne Gewähr" das, wofür es immer steht.


Log in to reply