Unsigned arithmetic in C++











up vote
11
down vote

favorite
2












I just observed a strange phenomenon when doing unsigned arithmetic. It's expected that b and -a have the same number 4294967286 due to wraparound, but the actual output for b and -a is -10 and 4294967286 respectively. Could anyone help give a hint?



#include <iostream>



int main() {

  unsigned int a = 10;

  int b = -a;

  std::cout << b << ", " << -a << std::endl;

}


https://repl.it/repls/ExpertDrabOrganization






c++







share|improve this question




















  • 2




    Why do you expect that an int would have the value 4294967286, which is much larger than the maximum int?
    – molbdnilo
    2 days ago








  • 1




    int b = -a; -> unsigned int b = -a;
    – Paul R
    2 days ago






  • 1




    @molbdnilo My fault. I forgot that b overflows, too.
    – Zhe Chen
    2 days ago

















up vote
11
down vote

favorite
2












I just observed a strange phenomenon when doing unsigned arithmetic. It's expected that b and -a have the same number 4294967286 due to wraparound, but the actual output for b and -a is -10 and 4294967286 respectively. Could anyone help give a hint?



#include <iostream>



int main() {

  unsigned int a = 10;

  int b = -a;

  std::cout << b << ", " << -a << std::endl;

}


https://repl.it/repls/ExpertDrabOrganization






c++







share|improve this question




















  • 2




    Why do you expect that an int would have the value 4294967286, which is much larger than the maximum int?
    – molbdnilo
    2 days ago








  • 1




    int b = -a; -> unsigned int b = -a;
    – Paul R
    2 days ago






  • 1




    @molbdnilo My fault. I forgot that b overflows, too.
    – Zhe Chen
    2 days ago















up vote
11
down vote

favorite
2









up vote
11
down vote

favorite
2






2





I just observed a strange phenomenon when doing unsigned arithmetic. It's expected that b and -a have the same number 4294967286 due to wraparound, but the actual output for b and -a is -10 and 4294967286 respectively. Could anyone help give a hint?



#include <iostream>



int main() {

  unsigned int a = 10;

  int b = -a;

  std::cout << b << ", " << -a << std::endl;

}


https://repl.it/repls/ExpertDrabOrganization






c++







share|improve this question















I just observed a strange phenomenon when doing unsigned arithmetic. It's expected that b and -a have the same number 4294967286 due to wraparound, but the actual output for b and -a is -10 and 4294967286 respectively. Could anyone help give a hint?



#include <iostream>



int main() {

  unsigned int a = 10;

  int b = -a;

  std::cout << b << ", " << -a << std::endl;

}


https://repl.it/repls/ExpertDrabOrganization






c++




c++






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited 2 days ago

























asked 2 days ago









Zhe Chen

1,42331528




1,42331528








  • 2




    Why do you expect that an int would have the value 4294967286, which is much larger than the maximum int?
    – molbdnilo
    2 days ago








  • 1




    int b = -a; -> unsigned int b = -a;
    – Paul R
    2 days ago






  • 1




    @molbdnilo My fault. I forgot that b overflows, too.
    – Zhe Chen
    2 days ago
















  • 2




    Why do you expect that an int would have the value 4294967286, which is much larger than the maximum int?
    – molbdnilo
    2 days ago








  • 1




    int b = -a; -> unsigned int b = -a;
    – Paul R
    2 days ago






  • 1




    @molbdnilo My fault. I forgot that b overflows, too.
    – Zhe Chen
    2 days ago










2




2




Why do you expect that an int would have the value 4294967286, which is much larger than the maximum int?
– molbdnilo
2 days ago






Why do you expect that an int would have the value 4294967286, which is much larger than the maximum int?
– molbdnilo
2 days ago






1




1




int b = -a; -> unsigned int b = -a;
– Paul R
2 days ago




int b = -a; -> unsigned int b = -a;
– Paul R
2 days ago




1




1




@molbdnilo My fault. I forgot that b overflows, too.
– Zhe Chen
2 days ago






@molbdnilo My fault. I forgot that b overflows, too.
– Zhe Chen
2 days ago














1 Answer
1






active

oldest

votes

















up vote
17
down vote



accepted










-a is evaluated in unsigned arithmetic, and will be a number larger than std::numeric_limits<int>::max(). The unary operator - when applied to an unsigned type acts more like a modulus operator.



Therefore the behaviour of your program is implementation defined due to an out-of-range assignment to an int.






share|improve this answer



















  • 3




    implementation defined - I.e. look at the docs, and shout at your implementer if they don't do what they promise.
    – StoryTeller
    2 days ago












  • @StoryTeller: Since which flashy new standard?
    – Bathsheba
    2 days ago






  • 1




    @StoryTeller It was implementation-defined in C++03 too.
    – Angew
    2 days ago






  • 2




    @Angew - Interestingly enough, it's implementation defined in a C99 draft I have lying around. It would seem that a conversion was always with implementation defined semantics. Overflow in arithmetic with signed types is UB, however, wherever I checked. Curious.
    – StoryTeller
    2 days ago








  • 1




    gcc implementation defined behavior: The value is reduced module 2^N. So the same for clang. For MSVC this behavior is not ensured: docs.microsoft.com/en-us/cpp/c-language/…
    – Oliv
    2 days ago











Your Answer






StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");

StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});


}
});














 

draft saved


draft discarded


















StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53388686%2funsigned-arithmetic-in-c%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown

























1 Answer
1






active

oldest

votes








1 Answer
1






active

oldest

votes









active

oldest

votes






active

oldest

votes








up vote
17
down vote



accepted










-a is evaluated in unsigned arithmetic, and will be a number larger than std::numeric_limits<int>::max(). The unary operator - when applied to an unsigned type acts more like a modulus operator.



Therefore the behaviour of your program is implementation defined due to an out-of-range assignment to an int.






share|improve this answer



















  • 3




    implementation defined - I.e. look at the docs, and shout at your implementer if they don't do what they promise.
    – StoryTeller
    2 days ago












  • @StoryTeller: Since which flashy new standard?
    – Bathsheba
    2 days ago






  • 1




    @StoryTeller It was implementation-defined in C++03 too.
    – Angew
    2 days ago






  • 2




    @Angew - Interestingly enough, it's implementation defined in a C99 draft I have lying around. It would seem that a conversion was always with implementation defined semantics. Overflow in arithmetic with signed types is UB, however, wherever I checked. Curious.
    – StoryTeller
    2 days ago








  • 1




    gcc implementation defined behavior: The value is reduced module 2^N. So the same for clang. For MSVC this behavior is not ensured: docs.microsoft.com/en-us/cpp/c-language/…
    – Oliv
    2 days ago















up vote
17
down vote



accepted










-a is evaluated in unsigned arithmetic, and will be a number larger than std::numeric_limits<int>::max(). The unary operator - when applied to an unsigned type acts more like a modulus operator.



Therefore the behaviour of your program is implementation defined due to an out-of-range assignment to an int.






share|improve this answer



















  • 3




    implementation defined - I.e. look at the docs, and shout at your implementer if they don't do what they promise.
    – StoryTeller
    2 days ago












  • @StoryTeller: Since which flashy new standard?
    – Bathsheba
    2 days ago






  • 1




    @StoryTeller It was implementation-defined in C++03 too.
    – Angew
    2 days ago






  • 2




    @Angew - Interestingly enough, it's implementation defined in a C99 draft I have lying around. It would seem that a conversion was always with implementation defined semantics. Overflow in arithmetic with signed types is UB, however, wherever I checked. Curious.
    – StoryTeller
    2 days ago








  • 1




    gcc implementation defined behavior: The value is reduced module 2^N. So the same for clang. For MSVC this behavior is not ensured: docs.microsoft.com/en-us/cpp/c-language/…
    – Oliv
    2 days ago













up vote
17
down vote



accepted







up vote
17
down vote



accepted






-a is evaluated in unsigned arithmetic, and will be a number larger than std::numeric_limits<int>::max(). The unary operator - when applied to an unsigned type acts more like a modulus operator.



Therefore the behaviour of your program is implementation defined due to an out-of-range assignment to an int.






share|improve this answer














-a is evaluated in unsigned arithmetic, and will be a number larger than std::numeric_limits<int>::max(). The unary operator - when applied to an unsigned type acts more like a modulus operator.



Therefore the behaviour of your program is implementation defined due to an out-of-range assignment to an int.







share|improve this answer














share|improve this answer



share|improve this answer








edited 2 days ago









Bakudan

13.3k84264




13.3k84264










answered 2 days ago









Bathsheba

172k27244366




172k27244366








  • 3




    implementation defined - I.e. look at the docs, and shout at your implementer if they don't do what they promise.
    – StoryTeller
    2 days ago












  • @StoryTeller: Since which flashy new standard?
    – Bathsheba
    2 days ago






  • 1




    @StoryTeller It was implementation-defined in C++03 too.
    – Angew
    2 days ago






  • 2




    @Angew - Interestingly enough, it's implementation defined in a C99 draft I have lying around. It would seem that a conversion was always with implementation defined semantics. Overflow in arithmetic with signed types is UB, however, wherever I checked. Curious.
    – StoryTeller
    2 days ago








  • 1




    gcc implementation defined behavior: The value is reduced module 2^N. So the same for clang. For MSVC this behavior is not ensured: docs.microsoft.com/en-us/cpp/c-language/…
    – Oliv
    2 days ago














  • 3




    implementation defined - I.e. look at the docs, and shout at your implementer if they don't do what they promise.
    – StoryTeller
    2 days ago












  • @StoryTeller: Since which flashy new standard?
    – Bathsheba
    2 days ago






  • 1




    @StoryTeller It was implementation-defined in C++03 too.
    – Angew
    2 days ago






  • 2




    @Angew - Interestingly enough, it's implementation defined in a C99 draft I have lying around. It would seem that a conversion was always with implementation defined semantics. Overflow in arithmetic with signed types is UB, however, wherever I checked. Curious.
    – StoryTeller
    2 days ago








  • 1




    gcc implementation defined behavior: The value is reduced module 2^N. So the same for clang. For MSVC this behavior is not ensured: docs.microsoft.com/en-us/cpp/c-language/…
    – Oliv
    2 days ago








3




3




implementation defined - I.e. look at the docs, and shout at your implementer if they don't do what they promise.
– StoryTeller
2 days ago






implementation defined - I.e. look at the docs, and shout at your implementer if they don't do what they promise.
– StoryTeller
2 days ago














@StoryTeller: Since which flashy new standard?
– Bathsheba
2 days ago




@StoryTeller: Since which flashy new standard?
– Bathsheba
2 days ago




1




1




@StoryTeller It was implementation-defined in C++03 too.
– Angew
2 days ago




@StoryTeller It was implementation-defined in C++03 too.
– Angew
2 days ago




2




2




@Angew - Interestingly enough, it's implementation defined in a C99 draft I have lying around. It would seem that a conversion was always with implementation defined semantics. Overflow in arithmetic with signed types is UB, however, wherever I checked. Curious.
– StoryTeller
2 days ago






@Angew - Interestingly enough, it's implementation defined in a C99 draft I have lying around. It would seem that a conversion was always with implementation defined semantics. Overflow in arithmetic with signed types is UB, however, wherever I checked. Curious.
– StoryTeller
2 days ago






1




1




gcc implementation defined behavior: The value is reduced module 2^N. So the same for clang. For MSVC this behavior is not ensured: docs.microsoft.com/en-us/cpp/c-language/…
– Oliv
2 days ago




gcc implementation defined behavior: The value is reduced module 2^N. So the same for clang. For MSVC this behavior is not ensured: docs.microsoft.com/en-us/cpp/c-language/…
– Oliv
2 days ago


















 

draft saved


draft discarded



















































 


draft saved


draft discarded














StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53388686%2funsigned-arithmetic-in-c%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown







-

Popular posts from this blog

Quarter-circle Tiles

Image
up vote 0 down vote favorite I have $99$ identical square tiles, each with a quarter-circle drawn on it like this: [asy] size(1.5cm); draw(Arc((2,0),1,90,180),red+1); draw((0,0)--(2,0)--(2,2)--(0,2)--(0,0)); [/asy] When I arrange the tiles in a $9times 11$ rectangular grid, each with a random orientation, what is the expected value of the number of full circles I form? I think this problem has to do with finding the chance any given 2x2 square has a circle, but I can't find it. expected-value share | cite | improve this question asked Nov 20 at 15:03 6minecraftninja 1 2
Read more

build a pushdown automaton that recognizes the reverse language of a given pushdown automaton?

Image
0 I think it's similiar to NFAs. I replace the finite states of the given automaton for start-states for my new automaton. I do it with $epsilon$ -transition from the start state to the actual finite states of the given automaton. The start state of the given automaton will be my accepting(finite) state of my new one. All transitions will be reversed of course to recognize the reversed word. But how do I have to change the stack of the pushdown automaton? That's tricky. formal-languages automata context-free-grammar share | cite | improve this question edited Nov 29 '18 at 14:20 joee
Read more

Mont Emei

Image
Mont Emei.mw-parser-output .entete.map{background-image:url("//upload.wikimedia.org/wikipedia/commons/7/7a/Picto_infobox_map.png")} Vue du sommet Wanfo du mont Emei Géographie Altitude 3 099  m , Wanfo Coordonnées 29° 31′ 11″ nord, 103° 19′ 57″ est Administration Pays   Chine Province Sichuan Ville-préfecture Leshan Géolocalisation sur la carte : Sichuan Mont Emei Géolocalisation sur la carte : Chine Mont Emei modifier   Paysage panoramique du mont Emei, incluant le paysage panoramique du grand Bouddha de Leshan *   Patrimoine mondial de l'UNESCO Passerelle en bois sur le versant ouest Pays   Chine Subdivision Sichuan Type Mixte Critères (iv) (vi) (x) Superficie 15 400 ha Numéro d’identification 779 Zone géographique Asie et Pacifique  ** Année d’inscription 1996 (20 e session) * Descriptif officiel UNESCO ** Classification géog
Read more