https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92338
Mick P. <mick.pearson at wildblue dot net> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|INVALID |FIXED
--- Comment #9 from Mick P. <mick.pearson at wildblue dot net> ---
I began to wonder if MSVC was just treating int as the right match in 32-bit
mode.
I did tests, with my open VS2015, in 32-bit mode, that compiled all signed
integer types, but refused to accept unsigned types (or float or double.) It
does accept unsigned variables, but not conversion operators.
The https://godbolt.org/z/Q54kFs link does the same in 32-bit (x86) mode. It
only accepts long long int in x64 mode. It seems pretty arbitrary honestly. I'm
sure compilers can do better. The MS compiler's error code is: no global []
operator accepts the class type... paraphrasing.
Converting to arbitrary int family types is lazy in both cases. The semantics
for a C-array are to search for any int type. That's how it should be
implemented. If it's supposed to mimic overloaded operator[] then it should
convert double/float to a signed int type, including pointer indexing.
(I thought MSVC's case was more sensible than it actually is. The x64 behavior
is actually pretty weird. A workaround is conversion via template, but it makes
for a much more unwieldy interface, if feasible. My use-case is a GUI
framework, so that the elements are data oriented. They are represented
graphically, but are also fields that easily convert to a string, int, or
double. The boolean type converts to bool, but the other elements are
implicit-conversion to bool only. It's clean that way. But it will have to
convert to any integer type if it's going to be used an index.)
