Определенные реализацией сужающие преобразования?

Question

Определенные реализацией сужающие преобразования?

C ++ 11 формализовал понятие сужение конверсии, и запрещено использовать один на верхнем уровне в списке инициализации.

Мне интересно, если, учитывая два типа T а также U, это может быть определено реализацией, является ли преобразование из T в U сужается. Согласно моему прочтению стандарта, это так. Вот мои рассуждения:

В соответствии с dcl.init.list (8.5.4) параграф 7, один из способов сужения преобразования — это неявное преобразование «из целочисленного типа или перечислимого типа с незаданной областью в целочисленный тип, который не может представлять все значения исходного типа».
Рассмотрим неявное преобразование из unsigned int в long,
Что касается относительных размеров int а также long, C ++ требует только, чтобы sizeof(int) <= sizeof(long),
Рассмотрим реализацию А, где sizeof(int) == sizeof(long), На этой реализации, long не может представлять все значения unsigned int, поэтому конверсия будет сужаться.
Рассмотрим реализацию B, где sizeof(int) < sizeof(long), На этой реализации, long может представлять все значения unsigned int, поэтому конверсия не будет сужаться.

Правильно ли я в своем анализе, что это может быть определено реализацией, сужается ли конверсия? Это желательно?

6

c++c++11 implicit-conversion list-initialization

Решение

Другие решения

Других решений пока нет …

Источник

Accepted Answer

Я бы действительно предпочел, чтобы «сужающее преобразование» было определено для самих типов. Таким образом, чтобы int i{long(non_constant_expression)} никогда не разрешается компилировать. Причина проста: либо вам не нужен большой радиус действия, вам следует использовать int во-первых, или вы действительно хотите «вырезать», что кажется мне достаточно редким случаем, когда требуется явное преобразование типа или приведение. Чтобы ответить на первый вопрос: это определение реализации.

Но, если честно, я почти никогда не использую этот сырой тип, просто size_t, int32_t, uint16_t и т.д., и это решает проблему автоматически. (uint16_t {uint8_t()} всегда сужается, uint16_t{uint16_t()} никогда.) Нужно только вдумчиво преобразовать size_t во что-то другое, но это всегда так.

4