Unterscheidung bei int zwischen 0 und null



  • SideWinder schrieb:

    Ein Bit + sämtliche Kombinationen aus den anderen 7 Bits.

    = 1 Bit :p



  • Im neuen Standard soll es eine Unterscheidungsmöglichkeit geben. Dort soll es dann das Keyword nullptr geben. Man kann also vergleichen, ob es sich um einen Zeiger, der auf NULL gesetzt ist habndelt, oder ob es z.B. eine Integer Variable mit dem Wert 0 handelt.

    ob man nun 0 oder NULL benutzt, mach wirklich keinen Unterschied, da es sich um das von Andrey erwähnte

    #define NULL 0
    

    handelt. Nachdem der Präprozessor die Quellen in den Fingern hatte, sieht der Compiler eh nur 0.

    Gruß Paddy



  • Naja, es gibt auch Compiler die das mit dem NULL ist 0 nicht so eng sehen und gerne mal Warnung ausgeben wenn NULL als int benutzt wird. Also völlig nutzlos ist NULL dann doch nicht.



  • @Paddy: Na, da kann man ja nur hoffen, dass es nicht zur Einführung solcher Keywords kommt. Ich will ja weiterhin:

    int* ptr = 0; // statt nullptr
    
    // und vor allem:
    
    if(!ptr)
    

    schreiben.

    MfG SideWinder



  • SideWinder schrieb:

    @Paddy: Na, da kann man ja nur hoffen, dass es nicht zur Einführung solcher Keywords kommt. Ich will ja weiterhin:

    int* ptr = 0; // statt nullptr
    
    // und vor allem:
    
    if(!ptr)
    

    schreiben.

    Warum soll ein Keyword das denn verhindern?



  • SideWinder schrieb:

    @Paddy: Na, da kann man ja nur hoffen, dass es nicht zur Einführung solcher Keywords kommt. Ich will ja weiterhin:

    int* ptr = 0; // statt nullptr
    
    // und vor allem:
    
    if(!ptr)
    

    schreiben.

    Habe das hier im Forum schon mehrmals geschrieben, wie das funktionieren wird. Habe auch schon mehrmals Links zu dem Proposal gepostet.

    Wieso man da jetzt wieder das ganze negativ sieht, wenn es endlich das Keyword nullptr geben wird, frage ich mich?

    Aber für dich gerne nochmal: Da C++2009 natürlich abwärtkompatibel ist, ist deine präferierte Schreibweise weiterhin möglich.



  • Wenn:

    int* p = 0;
    // sowieso semantisch äquivalent zu
    int* p = nullptr;
    

    sein wird, da abwärtskompatibel, frage ich mich wo der Sinn der längeren Schreibweise sein soll.

    Edit: Steht aber bestimmt in deinem Proposal, dass ich leider noch nicht gefunden habe.

    MfG SideWinder





  • #include <iostream>
    
    void foo(int *a)
    {
    	std::cout << "pointer" << std::endl;
    }
    
    void foo(int a)
    {
    	std::cout << "int" << std::endl;
    }
    
    int main()
    {
    	foo(0);
    	foo(NULL);
    	foo((int*)0);
    }
    

    Also, ich halte 0 nicht gerade für ne gute Lösung. Wenn ich nicht explizit den Pointercast angebe, wird die int-Funktion und nicht die Pointer-basierte Funktion aufgerufen. Dann kann ich auch gleich nullptr hinschreiben....



  • Hast du da auch ein Beispiel aus der Standardbibliothek, wo ich das einsetzen könnte? Ich benenne in solchen Fällen die Pointer-Funktion ganz einfach um *g*

    MfG SideWinder



  • also bei dieser nullptr geschichte kann ich im moment irgendwie nicht den vorteil erkennen. Imho auch so eine erweiterung wie http://www.c-plusplus.net/whitespace98.pdf

    @OP: nimm ruhig unsigned int und definiere für sich einfach 0xFFFF als den ungültigen wert. das ist 2^32=4.294.967.296 wann wirst du schon so eine riesenzahl gebrauchen können? und dann verlierst du nur eine einzige kombination...



  • SideWinder schrieb:

    Wenn:

    int* p = 0;
    // sowieso semantisch äquivalent zu
    int* p = nullptr;
    

    sein wird, da abwärtskompatibel, frage ich mich wo der Sinn der längeren Schreibweise sein soll.

    Edit: Steht aber bestimmt in deinem Proposal, dass ich leider noch nicht gefunden habe.

    MfG SideWinder

    #define NULL 0
    int* p1 = 0; // OK
    int* p2 = NULL; // OK
    int* p3 = nullptr; // OK
    
    int i1 = 0; // OK
    int i2 = NULL; // OK (sollte aber nicht OK sein!)
    int i3 = nullptr; // Fehler
    


  • Andrey schrieb:

    @OP: nimm ruhig unsigned int und definiere für sich einfach 0xFFFF als den ungültigen wert. das ist 2^32=4.294.967.296 wann wirst du schon so eine riesenzahl gebrauchen können? und dann verlierst du nur eine einzige kombination...

    besser -1 oder (unsigned)-1, das sollte immer alle bits auf 1 setzen, egal wie breit die integers sind.



  • vista schrieb:

    Andrey schrieb:

    @OP: nimm ruhig unsigned int und definiere für sich einfach 0xFFFF als den ungültigen wert. das ist 2^32=4.294.967.296 wann wirst du schon so eine riesenzahl gebrauchen können? und dann verlierst du nur eine einzige kombination...

    besser -1 oder (unsigned)-1, das sollte immer alle bits auf 1 setzen, egal wie breit die integers sind.

    Nö. Stichwort: Sign-and-magnitude 🤡



  • @hustbaer: Soll das so eine Art Vorteil sein? Also bis auf Artchis Ersatz bei überladenen Methoden habe ich bisher noch keinen Sinn gesehen. Da solcher Art Funktionen wohl nicht gerade dauernd vorkommen sehe ich eher schwarz, dass sich das durchsetzen wird.

    MfG SideWinder



  • TactX schrieb:

    vista schrieb:

    Andrey schrieb:

    @OP: nimm ruhig unsigned int und definiere für sich einfach 0xFFFF als den ungültigen wert. das ist 2^32=4.294.967.296 wann wirst du schon so eine riesenzahl gebrauchen können? und dann verlierst du nur eine einzige kombination...

    besser -1 oder (unsigned)-1, das sollte immer alle bits auf 1 setzen, egal wie breit die integers sind.

    Nö. Stichwort: Sign-and-magnitude 🤡

    wieso nicht? erklär bitte...



  • Er hat ja schon ein Stichwort geliefert, schlag das doch nach!

    http://en.wikipedia.org/wiki/Sign_and_magnitude

    MfG SideWinder



  • SideWinder schrieb:

    Er hat ja schon ein Stichwort geliefert, schlag das doch nach!

    geht es um ausnahmen (falls negative zahlen nicht als 2er-komplement gespeichert werden)?
    oder wie soll ich das verstehen?



  • vista schrieb:

    SideWinder schrieb:

    Er hat ja schon ein Stichwort geliefert, schlag das doch nach!

    geht es um ausnahmen (falls negative zahlen nicht als 2er-komplement gespeichert werden)?
    oder wie soll ich das verstehen?

    Ja, das meinte ich.



  • SideWinder schrieb:

    @hustbaer: Soll das so eine Art Vorteil sein? Also bis auf Artchis Ersatz bei überladenen Methoden habe ich bisher noch keinen Sinn gesehen. Da solcher Art Funktionen wohl nicht gerade dauernd vorkommen sehe ich eher schwarz, dass sich das durchsetzen wird.

    MfG SideWinder

    Klar ist das ein Vorteil. Ein Fehler mehr den der Compiler melden kann ist ein Vorteil !?!
    Ich bin gerade kein besonderer Fan der nullptr Sache, ist mir im Prinzip herzlich egal, wollte nur darauf hinweisen dass es sehrwohl einen Unterschied macht.


Anmelden zum Antworten