One of my friends noticed a strange behaviour of .size() method.
Link to WA submission : https://mirror.codeforces.com/contest/1307/submission/88824759
Link to AC submission : https://mirror.codeforces.com/contest/1307/submission/88824749
The bug is in the line
LL x=a[i].size()*(a[i].size()-1)/2;
In C++17 , I guess there is overflow in that expression.
But in C++17(64) , it works fine.
So does that mean the .size() operator can hold larger numbers in 64bit version?
And also what other methods show this kind of varying behaviour when the compiler changes from 32bit to 64bit??
Can anyone explain this please??
Yes. The return value of
.size()is astd::size_t. And the standard only guarantees that it is at least 16 bits long. In practice, on a 32 bit system it will be 32 bits, and on a 64 bit system it will be a 64 bit integer.Thanks for confirming. :)
Similar things happen with other integer types as well. For instance the C++ standard only guarantees that a
longinteger has at least 32 bits. On a modern Linux system with gcc it will be 32 bits, like anint, but on Windows with Visual Studio it will actually be 64 bits, like along long.Oh now I see. Few months back I had read this : https://stackoverflow.com/questions/4160945/long-long-int-vs-long-int-vs-int64-t-in-c
But couldn't clearly understand what they meant by "int64_t guarantees 64-bit allocation where as long doesn't guarantee".
That's why int32_t/int64_t are more reliable than long/long int/long long!
Thanks again!
Edit: Why downvotes on this comment?? Please correct me if I'm wrong.