C++ VS Toolset 141 - 142 differences for cast

2

I am actually working on an old source code that use c-style cast.

In that code, we cast some double values to unsigned long. The cast is correctly done when the code is compiled with VS2017 toolset v141.

But now, we are migrating to VS2019 toolset v142, and the cast failed. It returns 0xffffffff !

Is there a changement in the v142 that affects the cast ? If yes, is there an option or any tricks that i can do to have the correct value ?

For example :

#include <iostream>
#include <limits>

typedef std::numeric_limits< double > dbl;

int main()
{
    double value = -699457.70832337427;
    unsigned long ulValue = (unsigned long)value;
    unsigned long sculValue = static_cast<unsigned long>(value);

    std::cout.precision(dbl::max_digits10);

    std::cout << "Value : " << value << " - C-Style Cast " << ulValue << " - Static Cast " << sculValue << "\n";
    std::cout << "Value : " << value << " - C-Style Cast " << std::hex << ulValue << std::hex << " - Static Cast " << sculValue << "\n";
}

with vs2017 and toolset v141, output is : Value : -699457.70832337427 - C-Style Cast 4294267839 - Static Cast 4294267839 Value : -699457.70832337427 - C-Style Cast fff553bf - Static Cast fff553bf

with vs2019 and toolset v142, output is : Value : -699457.70832337427 - C-Style Cast 4294967295 - Static Cast 4294967295 Value : -699457.70832337427 - C-Style Cast ffffffff - Static Cast ffffffff

The only trick i found for now is casting first the value to long and after to unsigned long but it's not really an ideal solution !

Thanks by advance !

c++
casting

2 Answers

1

Floating-integral conversions [conv.fpint]

A prvalue of a floating-point type can be converted to a prvalue of an integer type. The conversion truncates; that is, the fractional part is discarded. The behavior is undefined if the truncated value cannot be represented in the destination type.

answered on Stack Overflow Oct 3, 2019 by n. 'pronouns' m.
0

As has been pointed out, it is undefined behavior to cast a negative floating point value to an unsigned integral type. You say

The only trick i found for now is casting first the value to long and after to unsigned long but it's not really an ideal solution !

Yes, it is a bit cumbersome; but it is the only way to achive well-defined behavior (which is actually implementation-defined behavior in this case).

answered on Stack Overflow Oct 3, 2019 by j6t

User contributions licensed under CC BY-SA 3.0