Информация об изменениях

Сообщение Re: Есть ли практический смысл в неявном усечении значений? от 14.10.2018 3:56

Изменено 14.10.2018 3:57 netch80

Re: Есть ли практический смысл в неявном усечении значений?
Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Есть ли какое-то практическое обоснование тому, что в C++ до сих разрешено неявное усечение значений (например, int до char)?


Спроси в std-proposals, как это лучше ограничить...

Вообще, там в целочисленной арифметике и без этого паршиво.

ЕМ>Все бы ничего, но при вызове перегруженных функций из шаблонов других функций это превращается в кошмар. Например, для фактической комбинации параметров (short, int) компиляторы считают подходящими и (int, int), и (short, short), и (char, char). Что мешает в такой ситуации выбрать единственно безопасный (int, int)?


Ну если на то пошло, то автоматически должен выбираться только (short, int), все остальные только по явной конверсии.
Если уж делаете строгость типизации в этом месте — то не должно быть неявных конверсий вообще.
Разве что для констант.

ЕМ>Ради чего это неявное усечение продолжают тянуть? Из старого кода вроде бы уже давно должны быть вычистить требующие его конструкции, а за использование их в новом коде — расстреливать на месте. Но в C++14 на эту тему все по-прежнему (текст C++17 сходу не нашелся).


А как поддерживать легаси?

Я вижу пока только один вариант — вводить [атрибутами]] контексты, где действуют новые правила.
Re: Есть ли практический смысл в неявном усечении значений?
Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Есть ли какое-то практическое обоснование тому, что в C++ до сих разрешено неявное усечение значений (например, int до char)?


Спроси в std-proposals, как это лучше ограничить...

Вообще, там в целочисленной арифметике и без этого паршиво.

ЕМ>Все бы ничего, но при вызове перегруженных функций из шаблонов других функций это превращается в кошмар. Например, для фактической комбинации параметров (short, int) компиляторы считают подходящими и (int, int), и (short, short), и (char, char). Что мешает в такой ситуации выбрать единственно безопасный (int, int)?


Ну если на то пошло, то автоматически должен выбираться только (short, int), все остальные только по явной конверсии.
Если уж делаете строгость типизации в этом месте — то не должно быть неявных конверсий вообще.
Разве что для констант.

ЕМ>Ради чего это неявное усечение продолжают тянуть? Из старого кода вроде бы уже давно должны быть вычистить требующие его конструкции, а за использование их в новом коде — расстреливать на месте. Но в C++14 на эту тему все по-прежнему (текст C++17 сходу не нашелся).


А как поддерживать легаси?

Я вижу пока только один вариант — вводить [[атрибутами]] контексты, где действуют новые правила.