Евгений Музыченко:
ЕМ>Для его его может быть нужно выбирать неявно? Почему не следует потребовать явного приведения к целевому типу?
А для чего вообще нужны неявные преобразования? Давай везде начнём касты вставлять — то-то красота будет!
std::uint8_t x = 10;
std::uint8_t y = 20;
std::uint8_t z = x + y; // Видишь тут усекающее преобразование?
std::uint8_t x = 10;
std::uint8_t y = 20;
std::uint8_t z = x & y; // А тут?
То, что ты хочешь, наверное, можно было бы как-то формализовать, только вот правила, скорее всего, получатся ещё заметно более сложные, чем есть сейчас, при том, что в текущих правилах уже без поллитры не разберёшься.
Re[9]: Есть ли практический смысл в неявном усечении значени
Евгений Музыченко:
ЕМ>Если считать библиотеки расширения частью языка, а не исполняющей средой
Впервые вижу, чтоб standard library называли execution environment. ХЗ, откуда ты берёшь эти свои понятия, но в среде людей, имеющих непосредственное отношение к стандартизации C++ и разработке его реализаций, принято считать, что язык C++ состоит из двух основных частей: C++ core language и C++ standard library. Стандартная библиотека C++ вся целиком является неотъемлемой частью языка — так же, как и core language.
Здравствуйте, N. I., Вы писали:
ЕМ>>Для его его может быть нужно выбирать неявно? Почему не следует потребовать явного приведения к целевому типу? NI>А для чего вообще нужны неявные преобразования? Давай везде начнём касты вставлять — то-то красота будет!
Ну так в Go так и сделано. И далеко не только в нём.
NI>std::uint8_t x = 10; NI>std::uint8_t y = 20; NI>std::uint8_t z = x + y; // Видишь тут усекающее преобразование?
А зачем было нужно безусловное расширяющее, чтобы потом усекать? Можно и без него.
NI>То, что ты хочешь, наверное, можно было бы как-то формализовать, только вот правила, скорее всего, получатся ещё заметно более сложные, чем есть сейчас, при том, что в текущих правилах уже без поллитры не разберёшься.
Как раз если устранить и неявное усечение, и неявное расширение — правила станут резко проще.
И, более того, это будет стимулировать понимание сути происходящего.
The God is real, unless declared integer.
Re[7]: Есть ли практический смысл в неявном усечении значений?
netch80:
N>А зачем было нужно безусловное расширяющее, чтобы потом усекать?
Не помню уже...
N>Можно и без него.
Вот только старый код, использующий promotions, по-тихому сломается.
N>Как раз если устранить и неявное усечение, и неявное расширение — правила станут резко проще.
А со старым кодом что делать прикажете?
Re[8]: Есть ли практический смысл в неявном усечении значений?
Здравствуйте, N. I., Вы писали:
N>>А зачем было нужно безусловное расширяющее, чтобы потом усекать? NI>Не помню уже...
N>>Можно и без него. NI>Вот только старый код, использующий promotions, по-тихому сломается. N>>Как раз если устранить и неявное усечение, и неявное расширение — правила станут резко проще. NI>А со старым кодом что делать прикажете?
Опции регулирования контекста. Например, в стиле
[[promotion(off)]] int func() {
// На функцию, метод, блок или выражение
...
}
или
#pragma STDC promotion(off)
// До конца блока того же уровня
...
Без них — старый стиль поведения (если опциями компилятора не меняется), с ними — как угодно.
Точно так же контекстными опциями стоило бы регулировать
— Режим целочисленной арифметики (truncated, checked...)
— Режим плавающей арифметики (так лучше, чем через runtime настройки типа fesetenv)
— Режим алиасинга
и многое другое.
The God is real, unless declared integer.
Re[9]: Есть ли практический смысл в неявном усечении значени
netch80:
N>Опции регулирования контекста. Например, в стиле
Если перед тобой появляется куча незнакомого кода, то быстро на глазок определить, нужно ли к нему присобачивать такие опции, может быть несколько затруднительно. Кроме того, это для нас добавление в компилятор очередной опции может казаться всего лишь парой пустяков, а для разработчиков компиляторов появление новых опций совместимости — это тот ещё геморрой, т.к. усложняет и без того непростую реализацию, а также её тестирование, покуда во всех допустимых комбинациях они должны между собой дружить. Когда опций много, возможных комбинаций их использования получается ну очень много и тогда можно легко нарваться на какие-нибудь неочевидные corner cases, поскольку уследить за всеми потенциальными взаимодействиями становится просто нереально.
Собсно, стандартизаторам в пределах одной версии стандарта все правила между собой нормально согласовать не удаётся, а вы ещё хотите, чтоб разработчики компиляторов вам покусочно разные версии стандарта согласовали. Ну, предположим, сделают они вам очередную прагму, вот только далеко не факт, что она всегда будет работать так, как вы желаете.
Здравствуйте, N. I., Вы писали:
N>>Опции регулирования контекста. Например, в стиле
NI>Если перед тобой появляется куча незнакомого кода, то быстро на глазок определить, нужно ли к нему присобачивать такие опции, может быть несколько затруднительно.
С какого потолка взято про "быстро" "присобачивать"?
NI> Кроме того, это для нас добавление в компилятор очередной опции может казаться всего лишь парой пустяков, а для разработчиков компиляторов появление новых опций совместимости — это тот ещё геморрой, т.к. усложняет и без того непростую реализацию, а также её тестирование, покуда во всех допустимых комбинациях они должны между собой дружить. Когда опций много, возможных комбинаций их использования получается ну очень много и тогда можно легко нарваться на какие-нибудь неочевидные corner cases, поскольку уследить за всеми потенциальными взаимодействиями становится просто нереально.
1. Взаимодействовать тут нечему.
2. Эти отмазки слышны уже лет 20. "Кто хочет — ищет метод, кто не хочет — ищет причину".
NI>Собсно, стандартизаторам в пределах одной версии стандарта все правила между собой нормально согласовать не удаётся,
То, что я назвал, им никак тут не помешает (и не поможет, оно просто ортогонально), так же как какие-нибудь -fwrapv или -Og.
NI> а вы ещё хотите, чтоб разработчики компиляторов вам покусочно разные версии стандарта согласовали. Ну, предположим, сделают они вам очередную прагму, вот только далеко не факт, что она всегда будет работать так, как вы желаете.
netch80:
NI>>Если перед тобой появляется куча незнакомого кода, то быстро на глазок определить, нужно ли к нему присобачивать такие опции, может быть несколько затруднительно.
N>С какого потолка взято про "быстро" "присобачивать"?
С такого, что кому-то придётся тратить время на определение точного набора правил, при котором код делает то, что нужно, а не абы что.
NI>> Кроме того, это для нас добавление в компилятор очередной опции может казаться всего лишь парой пустяков, а для разработчиков компиляторов появление новых опций совместимости — это тот ещё геморрой, т.к. усложняет и без того непростую реализацию, а также её тестирование, покуда во всех допустимых комбинациях они должны между собой дружить. Когда опций много, возможных комбинаций их использования получается ну очень много и тогда можно легко нарваться на какие-нибудь неочевидные corner cases, поскольку уследить за всеми потенциальными взаимодействиями становится просто нереально.
N>1. Взаимодействовать тут нечему.
Откуда такая уверенность, если ты даже не в курсе, зачем эти promotions нужны?
N>2. Эти отмазки слышны уже лет 20. "Кто хочет — ищет метод, кто не хочет — ищет причину".
N>Таки поиск причины не делать.
Ну, да, некоторым людям вообще-то своственно рассматривать pros & cons. Трудности в реализации и поддержки с виду полезной фичи могут перевешивать её достоинства.
Re[6]: Есть ли практический смысл в неявном усечении значений?
Здравствуйте, netch80, Вы писали:
N>как это надо описать в стандарте, чтобы все согласились.
Навскидку, пара вариантов. Мягкий: запрещено любое неявное усечение, кроме следствий неявного же расширения (например, i8 = i8+i8 разрешено, а i8 = i16 запрещено). Жесткий: запрещено любое неявное усечение, без вариантов.
N>Я как раз имею в виду, что в явном варианте конверсия может быть как минимум truncating, checked, saturating...
Это уже детали, которые можно было бы указывать или конструкцией явного преобразования, или явно же задаваемым режимом.
N>Ну если у одного и того же софтостроителя в C++ long == int32_t, а в C# long == Int64, а на чуть менее чем всех платформах вокруг тоже long == int64_t, то сомнений нет, где извращение.
У меня таки сомнения. Ибо триада short-int-long устаканивалась во времена, когда 32 разрядов хватало практически на все и, с переходом к 64-разрядным платформам, бОльшую разрядность почти везде стали задавать явно.
N>Особенно учитывая, что в юниксах переход на 64 бита к тому времени состоялся, все грабли пройдены, и "собственная гордость" была тупо нелепа.
Дело не в гордости, а в том, что юниксы устаканивались в первую очередь на RISC'ах, у которых длина команды не зависит от разрядности операндов. А статистика по коду с командами переменной длины показала, что операций с 64-разрядными операндами значительно меньше, чем с 32-разрядными, и в случае родных 64-разрядных и префиксованных 32-разрядных код будет раздуваться чересчур неприлично.
EM>>По этой причине несколько лет назад переделал все переменные, хранившие даже небольшие значения типа размера, в size_t.
N>Ну так и можно было обойтись int в таких местах.
Раньше там и был int, но все время приходилось ставить явные преобразования, получая ту же длину строки, или смещение в небольшом блоке памяти. Само по себе это не напрягает, но тогда мне казалось, что это еще и бессмысленно с точки зрения оптимальности кода.
ЕМ>>криворуких программистов нужно бить по кривым рукам как можно чаще. И компилятор это сделает эффективнее любого препода или начальника.
N>Не-а. Он не бьёт, он слишком часто маскирует это.
А вот зачем? Или в комитете по стандартизации криворуких слишком много?
Re[6]: Есть ли практический смысл в неявном усечении значений?
Здравствуйте, N. I., Вы писали:
NI>То, что ты хочешь, наверное, можно было бы как-то формализовать, только вот правила, скорее всего, получатся ещё заметно более сложные, чем есть сейчас, при том, что в текущих правилах уже без поллитры не разберёшься.
Я согласен с предыдущим ответом — неявное расширение тоже следовало бы исключить. Ибо оно в одних случаях делается, в других нет, увидеть это в выражении сходу, без выяснения всех участвующих типов, невозможно. Поэтому лучше бы сложение 8-разрядных всегда работало в 8-разрядной сетке, и так далее.
Re[10]: Есть ли практический смысл в неявном усечении значени
Здравствуйте, N. I., Вы писали:
NI>принято считать, что язык C++ состоит из двух основных частей: C++ core language и C++ standard library.
Ну так суть видна из самих определений: "core language" — это именно язык (способ записи, средство выражения и т.п.), а library — это лишь набор стандартных конструкций, ничего не меняющих ни в лексике, ни в синтаксисе, ни в семантике языка. Вообще, делить язык на "core" и "весь язык" — это несколько странно, в стиле рекурсий типа "GNU not UNIX", которые выглядят забавно и изящно, но лишь до тех пор, пока их не пытаются использовать в формальных конструкциях.
NI>Стандартная библиотека C++ вся целиком является неотъемлемой частью языка — так же, как и core language.
С таким определением сразу же возникают коллизии. Например, является ли "Война и мир" составной и неотъемлемой частью русского языка? Является ли квадратный трехчлен составной и неотъемлемой частью алгебры? И является ли конкретный участок конкретной ленты для машины Тьюринга неотъемлемой частью самой машины?
Re[8]: Есть ли практический смысл в неявном усечении значений?
Здравствуйте, N. I., Вы писали:
NI>Вот только старый код, использующий promotions, по-тихому сломается.
Чтоб не сломался по-тихому, нужно сегодня объявить, что такое поведение более не комильфо, за полгода добавить в компиляторы новые предупреждения, а через пять-десять лет поменять поведение. За это время все, кто работает над кодом и меняет компиляторы, успеют поправить. Те, кто не меняет компиляторов, ничего не заметят, а те кто меняет, но над кодом не работают, будут сами себе злобные буратины.
Re[12]: Есть ли практический смысл в неявном усечении значен
Здравствуйте, N. I., Вы писали:
NI>>>Если перед тобой появляется куча незнакомого кода, то быстро на глазок определить, нужно ли к нему присобачивать такие опции, может быть несколько затруднительно. N>>С какого потолка взято про "быстро" "присобачивать"? NI>С такого, что кому-то придётся тратить время на определение точного набора правил, при котором код делает то, что нужно, а не абы что.
Ещё раз — откуда "быстро на глазок" и всё такое?
NI>>> Кроме того, это для нас добавление в компилятор очередной опции может казаться всего лишь парой пустяков, а для разработчиков компиляторов появление новых опций совместимости — это тот ещё геморрой, т.к. усложняет и без того непростую реализацию, а также её тестирование, покуда во всех допустимых комбинациях они должны между собой дружить. Когда опций много, возможных комбинаций их использования получается ну очень много и тогда можно легко нарваться на какие-нибудь неочевидные corner cases, поскольку уследить за всеми потенциальными взаимодействиями становится просто нереально.
N>>1. Взаимодействовать тут нечему.
NI>Откуда такая уверенность, если ты даже не в курсе, зачем эти promotions нужны?
О, уже начались проезды про некомпетентность собеседника. Прописку скоро спросите?
Кстати, вы явно даже не попытались понять, о чём я говорю — хотя это видно было русским по фоновому.
N>>2. Эти отмазки слышны уже лет 20. "Кто хочет — ищет метод, кто не хочет — ищет причину". N>>Таки поиск причины не делать. NI>Ну, да, некоторым людям вообще-то своственно рассматривать pros & cons. Трудности в реализации и поддержки с виду полезной фичи могут перевешивать её достоинства.
Трёп ни о чём.
The God is real, unless declared integer.
Re[7]: Есть ли практический смысл в неявном усечении значений?
Здравствуйте, Евгений Музыченко, Вы писали:
N>>как это надо описать в стандарте, чтобы все согласились. ЕМ>Навскидку, пара вариантов. Мягкий: запрещено любое неявное усечение, кроме следствий неявного же расширения (например, i8 = i8+i8 разрешено, а i8 = i16 запрещено). Жесткий: запрещено любое неявное усечение, без вариантов.
Ну вот навскидку уже видно, где нужно сделать послабление: правила для констант — чтобы не надо было писать a+(int8_t)4, если a типа int8_t, а сразу писать a+4.
А возможно, ещё несколько специфических случаев попадётся.
N>>Я как раз имею в виду, что в явном варианте конверсия может быть как минимум truncating, checked, saturating... ЕМ>Это уже детали, которые можно было бы указывать или конструкцией явного преобразования, или явно же задаваемым режимом.
Кому детали, а кому принципиальный элемент реализации. В C/C++ и так много грабель, а все эти UdB только усложняют и без того путаное. Потому я агитирую за контекстно-управляемые режимы. Примеры есть — все эти -fwrapv, -ftrapv; C# — unchecked/checked; Rust — методы типа checked_add; и так далее.
Хотя больше похоже, что продавят просто twoʼs-complement и гарантированное обрезание при усечении, а дальше, скажут, крутитесь сами как хотите.
N>>Ну если у одного и того же софтостроителя в C++ long == int32_t, а в C# long == Int64, а на чуть менее чем всех платформах вокруг тоже long == int64_t, то сомнений нет, где извращение. ЕМ>У меня таки сомнения. Ибо триада short-int-long устаканивалась во времена, когда 32 разрядов хватало практически на все и, с переходом к 64-разрядным платформам, бОльшую разрядность почти везде стали задавать явно.
32 бита на всё? Хм, даже в 90е годы это было не так. Например, FreeBSD принципиально сделала off_t 64-битным ещё в 2.0 — это чтобы потом не иметь проблем с совместимостью. А всякие Linux & Solaris протормозили с этим и имели неожиданные проблемы.
N>>Особенно учитывая, что в юниксах переход на 64 бита к тому времени состоялся, все грабли пройдены, и "собственная гордость" была тупо нелепа. ЕМ>Дело не в гордости, а в том, что юниксы устаканивались в первую очередь на RISC'ах, у которых длина команды не зависит от разрядности операндов. А статистика по коду с командами переменной длины показала, что операций с 64-разрядными операндами значительно меньше, чем с 32-разрядными, и в случае родных 64-разрядных и префиксованных 32-разрядных код будет раздуваться чересчур неприлично.
Я не вижу тут принципиальных проблем даже с x86 с его лёгким раздувательством. Всё, для чего было достаточно 32 бит, писалось в int.
EM>>>По этой причине несколько лет назад переделал все переменные, хранившие даже небольшие значения типа размера, в size_t. N>>Ну так и можно было обойтись int в таких местах. ЕМ>Раньше там и был int, но все время приходилось ставить явные преобразования, получая ту же длину строки, или смещение в небольшом блоке памяти. Само по себе это не напрягает, но тогда мне казалось, что это еще и бессмысленно с точки зрения оптимальности кода.
Я не про конкретный подход. В общем, понятно.
ЕМ>>>криворуких программистов нужно бить по кривым рукам как можно чаще. И компилятор это сделает эффективнее любого препода или начальника. N>>Не-а. Он не бьёт, он слишком часто маскирует это. ЕМ>А вот зачем? Или в комитете по стандартизации криворуких слишком много?
UdB даёт сильно больше возможностей для оптимизации. Там стараются этим пользоваться.
Вот почему при этом перекошенность, что unsigned работает по модулю, а signed не должно переполняться, и что это сохраняют до сих пор — вот это как раз вопрос к возможно... криворукости — вряд ли, а вот альтернативного мышления — таки да.
The God is real, unless declared integer.
Re[9]: Есть ли практический смысл в неявном усечении значений?
Евгений Музыченко:
ЕМ>Чтоб не сломался по-тихому, нужно сегодня объявить, что такое поведение более не комильфо, за полгода добавить в компиляторы новые предупреждения, а через пять-десять лет поменять поведение.
Не факт, что это сработает, ведь через пять-десять лет страданий над простынями из явных преобразований сообщество может и передумать
Re[13]: Есть ли практический смысл в неявном усечении значен
netch80:
N>Ещё раз — откуда "быстро на глазок" и всё такое?
Я не понял суть данного вопроса, однако на все неясные вопросы со словом "откуда" у меня есть универсально правильный ответ: от верблюда!
N>О, уже начались проезды про некомпетентность собеседника.
Не, ну прикольно же: не выяснив, в чём заключается предназначение promotions, уже мечтаем о том, как их выпилить, и наперёд знаем, что никаких негативных последствий не будет. Самоуверенности некоторых диванных аналитиков можно только позавидовать
Re[14]: Есть ли практический смысл в неявном усечении значен
Здравствуйте, N. I., Вы писали:
N>>О, уже начались проезды про некомпетентность собеседника.
NI>Не, ну прикольно же: не выяснив, в чём заключается предназначение promotions,
Ложь-1.
NI> уже мечтаем о том, как их выпилить,
Ложь-2.
NI> и наперёд знаем, что никаких негативных последствий не будет.
Ложь-3.
NI> Самоуверенности некоторых диванных аналитиков можно только позавидовать
А вот тут явная самокритика. Не знаком, но по данной дискуссии — похоже на правду.
Но всё равно конструктива нет. Спасибо за участие, больше не нужно.
The God is real, unless declared integer.
Re[15]: Есть ли практический смысл в неявном усечении значен
Здравствуйте, netch80, Вы писали:
ЕМ>>Навскидку, пара вариантов. Мягкий: запрещено любое неявное усечение, кроме следствий неявного же расширения (например, i8 = i8+i8 разрешено, а i8 = i16 запрещено). Жесткий: запрещено любое неявное усечение, без вариантов. N>Ну вот навскидку уже видно, где нужно сделать послабление: правила для констант — чтобы не надо было писать a+(int8_t)4, если a типа int8_t, а сразу писать a+4. N>А возможно, ещё несколько специфических случаев попадётся.
Данный вопрос (а именно каков должен быть тип числового литерала) и так решается: как-то же он сейчас выбирает между int, long int и long long int? Собственно ничего не мешает выводить данный тип в более широком диапазоне. Хотя конечно, тут до другого языка уже не далеко.
Re[9]: Есть ли практический смысл в неявном усечении значений?
Здравствуйте, Mystic Artifact, Вы писали:
N>>Ну вот навскидку уже видно, где нужно сделать послабление: правила для констант — чтобы не надо было писать a+(int8_t)4, если a типа int8_t, а сразу писать a+4. N>>А возможно, ещё несколько специфических случаев попадётся. MA> Данный вопрос (а именно каков должен быть тип числового литерала) и так решается: как-то же он сейчас выбирает между int, long int и long long int?
Но если мы запретим все неявные конверсии, он перестанет так решаться.
А сейчас решается он далеко не идеально. Например, у меня коллега как-то напоролся — 32-битная система, off_t 64-битный, lseek(f, -sizeof(struct data), SEEK_END) ставил совсем не туда, куда надо (смещение получалось положительным). Разобрались, заменили на -(off_t) sizeof(struct data).
Это ситуации такого рода, что пару раз протоптавшись по ним начинаешь замечать, но до того — если не читал источники типа "Внимание, здесь водятся дикие драконы", то приходит совершенно неожиданно.
MA> Собственно ничего не мешает выводить данный тип в более широком диапазоне. Хотя конечно, тут до другого языка уже не далеко.
Ну вот контексты это неплохой метод постепенной миграции к новым правилам. Хотя легаси всё равно останется, и очень тяжёлое.
И компилятор это сделает эффективнее любого препода или начальника.
