Avoiding warnings about int <=> qsizetype on Windows with MSVC

Robert Hairgrove

I am trying to set up my code base so that it will compile both with Qt 5.15.5 and Qt 6.5.3 both on Linux with GCC and Windows using MSVC 2019.

On Linux Ubuntu, there are never any warnings issued concerning narrowing conversions with the default compiler settings, e.g. when returning an int from a function that calls a Qt object's size() function (as of Qt 5.10, the type returned is qsizetype).

MSVC issues the C4244 warning about possible loss of data since qsizetype is larger than a 32-bit int.

Unfortunately, there are very many places where I need to update the code since I do not want to globally surpress this warning.

Can anyone give me some tips on how to "ease the pain" here? I already saw the tip to use auto, but #ifdef qsizetype doesn't seem to work since it is a typedef and not a macro. I'm not sure that auto will work in a header file as the return value from a function.

KenAppleby 0

@Robert-Hairgrove
The least painful way I have found is

int n(list.size());

which quietly does the static_cast, whereas

int n{ list.size() };

issues the loss of data warning, and clang raises a semantic issue.

int n = list.size();

Issues no warnings;
This is using MinGW 64, but I expect this would be the same on MSVC.

I am confident none of my containers exceed 2'147'483'648 in length, at least not intentionally!

Robert Hairgrove

@KenAppleby-0 said in Avoiding warnings about int <=> qsizetype on Windows with MSVC:

int n = list.size();

Issues no warnings;
This is using MinGW 64, but I expect this would be the same on MSVC.

MSVC warns C4244 about possible loss of data here. If I do a C-style cast, as your first suggestion does, it issues no warning.

Thank you for that!

KenAppleby 0

@Robert-Hairgrove said in Avoiding warnings about int <=> qsizetype on Windows with MSVC:

If I do a C-style cast, as your first suggestion does

It's not a C-style cast, as I understand it. That would be

int n = (int)list.size();

or

int n{ (int)list.size() };

It's more an implicit static_cast. C-style casts are forbidden where I come from! :-)

J.Hilk

@KenAppleby-0 said in Avoiding warnings about int <=> qsizetype on Windows with MSVC:

C-style casts are forbidden where I come from! :-)

away to jail with you than!
int y = (int)x; and int y = int(x); are functionally the same in C++. Both are examples of explicit type casting, where the value of x is converted to an int before being assigned to y.
However, the syntax int y = int(x); is known as a functional cast, which is more similar to the syntax used by constructors in object-oriented programming. Despite the syntactic differences, both forms will perform the same type conversion operation in this context.

KenAppleby 0

@J-Hilk said in Avoiding warnings about int <=> qsizetype on Windows with MSVC:

int y = (int)x; and int y = int(x); are functionally the same in C++. Both are examples of explicit type casting, where the value of x is converted to an int before being assigned to y

Functional equivalence in one special case is not identity in general, or even in that special case.
On a 64-bit machine with a C-style cast you can do:

const uint64_t a{ 0 };
const void * b = (void *)a;

or even

const Foo * foo = (Foo *) a;

without getting even a warning. And you can't do

const void * c = void *(a);

"The C-style cast is far more dangerous than the named conversion operators because the notation is harder to spot in a large program and the kind of conversion intended ... is not explicit." Stroustrup.

I'm with Bjarne. :-)

JonB

@KenAppleby-0 said in Avoiding warnings about int <=> qsizetype on Windows with MSVC:

Functional equivalence in one special case is not identity in general, or even in that special case.

I don't see @J-Hilk said anything about this. He said:

int y = (int)x; and int y = int(x); are functionally the same in C++

which they are. I don't read that as saying there is nothing you can do with explicit casts that cannot be done with functional casts.

And you can't do
const void * c = void *(a);

typedef void *voidp;
const voidp c = voidp(a);

Is that what you are alluding to? That's why @J-Hilk said

Despite the syntactic differences

KenAppleby 0

Functional equivalence in one special case is not identity in general, or even in that special case.

@JonB said

I don't see @J-Hilk said anything about this. He said:

int y = (int)x; and int y = int(x); are functionally the same in C++

That's not what my comment says. @J-Hilk is saying that

int y = int(x);

is a C-style cast. I am saying it isn't. It may do the same thing, at the compiler's discretion, but it isn't a C-style cast. One of the reasons that it isn't is syntactical.

jsulm

@KenAppleby-0 said in Avoiding warnings about int <=> qsizetype on Windows with MSVC:

. @J-Hilk is saying that
int y = int(x);

is a C-style cast.

Where? He wrote: "int y = (int)x; and int y = int(x); are functionally the same in C++".

KenAppleby 0

@jsulm

Where?

Here: I had written

C-style casts are forbidden where I come from! :-)

he wrote

away to jail with you than!(sic)
int y = (int)x; and int y = int(x); are functionally the same in C++

I had not written "anything functionally the same as a C-style cast is forbidden" [which would forbid all named casts, so I'm unlikely to say that.]

The "away to jail" jibe makes sense only if it is asserting that int(x) isa C-style cast.

Enough.