int instead of ptrdiff_t in xt:view spams the output in VS 2022

[risa2000]

I was updating my project with the recent libs and tools, i.e.

VS 2022 (Microsoft (R) C/C++ Optimizing Compiler Version 19.33.31629 for x64)
xtensor v0.24.2

and when compiling this pattern:

#include <xtensor/xview.hpp>

typedef xt::xtensor<double, 2> harray2d_t;

int main(int argc, char* argv[])
{
    const size_t ptcount = 100;
    harray2d_t::shape_type shape{ptcount, 3};
    harray2d_t points{shape};
    const auto tcol = xt::view(points, xt::all(), 2);

    return 0;
}

I was getting a quite a list of "notes", initiated by a single warning, being caused by the xt::view(points, xt::all(), 2) call.

The output is here build.log

All complains disappear when I change the code to:

const auto tcol = xt::view(points, xt::all(), static_cast<ptrdiff_t>(2));

(size_t type silences the compiler too and probably other compatible - unsigned - types). While the fix is trivial I believe using 2 is perfectly valid. Also, I am not sure if it is because of an overly caring MSVC compiler, or something in xtensor, but if it could be helped in xtensor it would save quite a lot of wasted output lines.

[tdegeus]

Honestly I don't think that this can be easily avoided. Personally I think that any function that will cast a variable to unsigned should take a variable as unsigned. But that it would be a so great if the compiler would recognise that when you type 2 that it is unsigned and it would not have to worry about it. Instead it thinks: 2 is an integer, that could have been unsigned.

[risa2000]

@tdegeus Yes, I guess, it is not really a problem in xtensor, but the compiler being too picky. I would however leave the comment here and possibly make a point at Microsoft dev tools forum. It does not make sense to complain note about 2 not being of particular type when the type is basically inferred by the compiler on the fly.