signed integer auf unsigned integer casten



  • tntnet, denk nochmal nach über das was du da geschrieben hast.



  • sebi707 schrieb:

    Yeah, es wird sogar garantiert:

    §3.9.1 Abs. 3 schrieb:

    [...]
    The range of non-negative values of a signed integer type is a subrange of the corresponding unsigned integer type, [...]

    Ergo kann ein signed integer nicht größer sein als sein unsigned Pendant.


  • Mod

    osdt schrieb:

    sebi707 schrieb:

    Yeah, es wird sogar garantiert:

    §3.9.1 Abs. 3 schrieb:

    [...]
    The range of non-negative values of a signed integer type is a subrange of the corresponding unsigned integer type, [...]

    Ergo kann ein signed integer nicht größer sein als sein unsigned Pendant.

    Nein. Es müssen nicht alle Bits der object representation verwendet werden - das ist nur für narrow character types der Fall:

    [basic.fundamental]/1 schrieb:

    For narrow character types, all bits of the object representation participate in the value representation. For unsigned narrow character types, each possible bit pattern of the value representation represents a distinct number. These requirements do not hold for other types.

    signed @ und unsigned @ müssen jedoch tatsächlich gleich groß sein, was durch den übernächsten Paragraphen geregelt ist:

    [basic.fundamental]/3 schrieb:

    For each of the standard signed integer types, there exists a corresponding (but different) standard unsigned integer type: […], each of which occupies the same amount of storage and has the same alignment requirements (3.11) as the corresponding signed integer type; that is, each signed integer type has the same object representation as its corresponding unsigned integer type.



  • Hab den code nun entsprechend angepasst
    http://melpon.org/wandbox/permlink/JSwzGPQ8xuOAGkk5
    Die Warnung ist weg.

    Oder seht ihr hier noch irgendwelche Probleme?



  • @Arcoth
    Und was ist mit dem von sebi707 zitierten Absatz?
    Gilt der nicht? Oder ist der aus ner älteren Standard-Version?


  • Mod

    hustbaer schrieb:

    Gilt der nicht?

    Lies doch mal meinen Beitrag genau. Der Absatz ist natürlich gültig, aber man kann nicht durch ihn auf der Typgrößen Gleichheit schließen, weil nicht jedes Bit der object representation (sprich, der Gesamtheit aller Bytes, die ein Objekt diesen Typs beansprucht) auch in der value representation (die Gesamtheit der Bits, die den Wert beeinflussen) vorkommen muss. Ich bezog mich mit meiner Verneinung auf sein "Ergo", nicht auf die Schlussfolgerung, die zwar wahr ist - aber eben aus anderen Gründen.



  • Naja kommt drauf an wie man "grösser sein" versteht 😃

    Da es hier nie um sizeof() ging sondern immer nur um Wertebereiche, hab ich "grösser sein" einfach mal so verstanden (Wertebereich). Und mich dementsprechend gewundert dass du "nein" schreibst.

    Aber OK, verstehe jetzt was du meinst. Und es ist wohl auch die (bei weitem) üblichere Interpretation von "Grösse" 😉


  • Mod

    @hustbaer: Wäre seine Aussage so zu interpretieren, wäre sie doch etwas sinnfrei, oder?



  • hustbaer schrieb:

    tntnet, denk nochmal nach über das was du da geschrieben hast.

    Oh ja, hast recht. Ist natürlich nicht so sehr Sinnvoll. War ein wenig zu schnell. Der static_cast war schon die richtige Richtung, aber der Vorschlag war blöd.



  • Arcoth schrieb:

    osdt schrieb:

    sebi707 schrieb:

    Yeah, es wird sogar garantiert:

    §3.9.1 Abs. 3 schrieb:

    [...]
    The range of non-negative values of a signed integer type is a subrange of the corresponding unsigned integer type, [...]

    Ergo kann ein signed integer nicht größer sein als sein unsigned Pendant.

    Nein. Es müssen nicht alle Bits der object representation verwendet werden - das ist nur für narrow character types der Fall:

    Da in dem zitierten Absatz von dem Wertebereich die Rede ist, bezog sich meine Aussage natürlich auf eben diesen. Ergo: der Wert eines signed integer kann nicht größer sein als der Maximalwert seines unsigned Pendants.



  • @Arcoth
    Verstehe auch nicht ganz was daran dann sinnfrei sein soll.
    Es ist garantiert dass der grösste (positive) signed XX auch in einen unsigned XX reinpasst.
    Das ist schon nützlich, speziell in dem hier diskutierten Fall.

    Ist als Erwiderung auf die von sebi707 geäusserte Unsicherheit (bezüglich "machen alle Compier so" vs. "wird vom Standard garantiert") mMn. perfekt. Abgesehen natürlich von der - wie man sieht - nicht ausreichend klaren Formulierung.



  • tntnet schrieb:

    Der static_cast war schon die richtige Richtung, aber der Vorschlag war blöd.

    Klar, der static_cast ist schon nicht verkehrt. Fehlt nur noch ne Type-Function die nen passenden Typ zurückliefert.

    Wobei man dann auch gleich ne normale Funktion nehmen kann, die zusätzlich zur Auswahl des Typs auch noch den static_cast erledigt. Womit wir dann bei make_unsigned wären 😃



  • @cpp coder
    Guck dir mal boost::numeric_cast an.
    Das wirft halt ne Exception ( boost::bad_numeric_cast ) in deinem "false" Fall. Dafür wäre es fertig und funktioniert für beliebige source und destination Typen.

    Bei float <-> double sollte man gut die Doku lesen und u.U. auch mal in die Implementierung reingucken. Dabei wird nämlich IIRC nicht darauf geachtet dass sich der Wert durch Unterschiede in der Genauigkeit nicht verändert.

    Bei Integertypen gibt's aber IIRC nix spezielles zu beachten.


  • Mod

    Ergo kann ein signed integer nicht größer sein als sein unsigned Pendant.

    Diese Aussage macht überhaupt keinen Sinn, wenn nicht von Typgröße gesprochen wird. Und "Größe" als "Maximalwert" zu interpretieren ist wirklich sehr weit hergeholt.



  • Arcoth schrieb:

    Ergo kann ein signed integer nicht größer sein als sein unsigned Pendant.

    Diese Aussage macht überhaupt keinen Sinn, wenn nicht von Typgröße gesprochen wird.

    Kann man so sagen, ja.
    Man kann aber genau so gut sagen: in einem Thread wo Typgröße völlig egal ist aber Wertebereich wichtig auf einmal von Typgröße anzufangen macht überhaupt keinen Sinn.

    Jetzt kannste dir aussuchen ob du es mit einer "sinnvoll" formulierten "sinnlosen" Aussage zu tun hast, oder mit einer "sinnlos" formulierten "sinnvollen" Aussage. Verstehste was ich meine? 🙂


Anmelden zum Antworten