(Für mich) unverständliches Ergebnis bei binärem Operator ~



  • virtuell Realisticer schrieb:

    Das haben wir bei positiven Zahlen gelernt, aber nicht bei negativen 😉

    mfg
    v R

    Ja, aber wenn ich mit -1 multipliziere ist die Zahl doch wieder positiv? Ach nein, das hängt sicher davon ab, ob die zahl negativ sein kann...
    Dann frag ich mal in die Runde: Wie kann ich mittels den binären Operatoren die Obergrenze eines vorzeichen-behafteten types ausgeben? Und wo genau ist das "Vorzeichen-bit"? Ganz "links" oder ganz "rechts"? (Auf einer x68-Architektur)



  • Es ist das höchstwertige Bit, üblicherweise ganz links dargestellt (aber das ist nur Konvention. Ich fände Spiralmuster zwar hübscher, aber die sind halt nicht so praktisch)

    Da du eigentlich überhaupt nichts über die Darstellung weißt, wird es schwierig. Vielleicht

    int i=0; while(i+1>0) ++i;
    

    . aber das dauert etwas.

    Wenn du die Kodierung kennst, geht alles natürlich ein bißchen schneller.



  • Ja, sowas hab ich auch schon, aber haste das schinmal mit long long probiert? 😃
    Woher könnte ich denn Informationen über die Darstellung beziehen? Prinzipiell müsste das Ergebnis binär gesehen ja ziemlich regelmäßig sein, bei unsigned eben 111111111111...



  • Ja, aber wenn ich mit -1 multipliziere ist die Zahl doch wieder positiv? Ach nein, das hängt sicher davon ab, ob die zahl negativ sein kann...

    Du hattest a = 0. ~a ist dann -1 und das *-1 ist 1. Was ist daran ungewoehnlich?

    Ja, sowas hab ich auch schon, aber haste das schinmal mit long long probiert? 😃
    Woher könnte ich denn Informationen über die Darstellung beziehen? Prinzipiell müsste das Ergebnis binär gesehen ja ziemlich regelmäßig sein, bei unsigned eben 111111111111...

    Wieso sollte es regelmaessig sein? In diesem Falle wuerde es eine +0 und eine -0
    geben. Und genau damit das nicht passiert, sind 32 einser-Bits -1 und nicht die
    kleinste negativ darstellbare Zahl. Damit du diese Zahl bekommst, kannst du das
    vorderste Bit auf 1 setzen:

    int a = 0;
        a = (1<<31);
    

    mfg
    v R



  • OK, und woher bekomme ich ne positive Zahl? Und warum ist long long a=(1<<63) 0?



  • Weil long long auf deinem compiler auch keine 4 bit hat?



  • long long == __int64 == 64bit? So stehts in der msdn?


  • Mod

    ich tip mal darauf,d ass der ausdruck (1<<63) zunächst als long ausgewertet und dann nach long long gecastet wird. wenn das so ist, müsste

    long long a = (long long)1 << 63;
    

    eigentlich funktionieren.



  • oder so 😉 stimmt.



  • Danke, jetzt gehts... Aber warum glaubst du, 1 wird als long gewertet? Ich würde eher auf int tippen...
    Aber dann bitte:

    long long a=(static_cast<long long>(1)<<63);
    

    Hast du nicht mehr effektiv c++ gelesen?
    Das Ergebnis ist übrigens 4611686018427387904...
    /edit:Kann net sein, wenn ich um 64 verschiebe komt -9...



  • ness schrieb:

    Danke, jetzt gehts... Aber warum glaubst du, 1 wird als long gewertet? Ich würde eher auf int tippen...

    Das ist egal, weil sizeof(int) == sizeof(long) auf 32-Bitsystemen

    Aber dann bitte:

    long long a=(static_cast<long long>(1)<<63);
    

    Hast du nicht mehr effektiv c++ gelesen?
    Das Ergebnis ist übrigens 4611686018427387904...
    /edit:Kann net sein, wenn ich um 64 verschiebe komt -9...

    Wenn du um 64-Bit shiftest, dann shiftest du ueber die Grenze deiner 64-Bit
    Variablen hinaus. Denn auch hier gillt: zaehlen von Bit 0 bis Bit 63. Ich
    wuerde sagen, dass dann das Ergebnis implementierungspezifisch ist. Hab jetzt
    grad keine Lust nachzuschauen, ob der Draft sich darueber auslaesst 🙂

    mfg
    v R


Anmelden zum Antworten