I am using MS VS2022 of version 17.12. Maybe in the newly vesion of MS VS2022 (17.13) the bug was fixed.
 
With best regards
(Vlad from Moscow)
 
You can meet me at http://cpp.forum24.ru/ or www.stackoverflow.com or http://ru.stackoverflow.com
 
  
>Пятница, 25 апреля 2025, 11:20 +03:00 от Bo Persson via Std-Discussion <std-discussion_at_[hidden]>:
>
>On 2025-04-25 at 00:38, Vladimir Grigoriev via Std-Discussion wrote:
>> In the C++20 Standard there is written (9.7.1 Enumeration declarations):
>> 7 For an enumeration whose underlying type is not fixed, the underlying
>> type is an integral type that can represent all the enumerator values
>> defined in the enumeration. If no integral type can represent all the
>> enumerator values, the enumeration is ill-formed. It is implementation-
>> defined which integral type is used as the underlying type *except that
>> the underlying type shall not be larger than int unless the value of an
>> enumerator cannot fit in an int or unsigned int*. If the enumerator-list
>> is empty, the underlying type is as if the enumeration had a single
>> enumerator with value 0.
>> However if to run this simple program
>>
>> |#include <iostream> #include <type_traits> int main() { int vals[]
>> { 2,3,5,7,11 }; enum { N = sizeof vals / sizeof vals[0] }; std::cout <<
>> std::boolalpha; std::cout <<
>> "std::is_same_v<std::underlying_type_t<decltype( N )>, size_t> = " <<
>> std::is_same_v<std::underlying_type_t<decltype( N )>, size_t> << '\n'; }|
>>
>> |then the MS VS2022 outputs *true *though size_t is an alias for the
>> type unsigned long long and the constant value used as an initializer
>> of the enumerator *N *at least can fit in an object of the type
>> unsigned int.|
>For me it outputs false, and the IDE popup says that the type is int.
>
>
>--
>Std-Discussion mailing list
>Std-Discussion_at_[hidden]
>https://lists.isocpp.org/mailman/listinfo.cgi/std-discussion