Уфф, даже не знаю, с чего начать… Это повлечет за собой столько боли.
Питон — отличный пример; третья версия появилась двенадцать лет назад. Вторая все еще здесь. Она все еще нужна. Ее все еще приходится ставить отдельно от третьей.
Ее приходилось поддерживать в течении 10 лет вроде.
В случае с С++ будет гораздо, гораздо хуже; представьте, что в каждой системе нужно будет держать все библиотеки в двух версиях — собранные "по-старому" и собранные "по-новому".
Не забывайте про груз обратной совместимости.
Ну и вообще, мне со своей колокольни тоже кажется, что все просто и понятно, а комитет какой-то ерундой занимается, но на самом-то деле проектировать язык на таком огромном промежутке времени — это чудовищно сложная задача; собственно поэтому все еще не существует идеального беспроблемного языка.
Собственно тот факт, что для типов без знака wraparound поддерживается и небо не землю не падает и показывает, что для компилятора это несложно поддержать.
Я и не говорю, что это сложно или что небо упадет на землю, это просто вынуждает компилятор делать дополнительные проверки, т.е. снижать производительность. UB же позволяет эти проверки переложить на программиста, вот и все.
У вас волосы дыбом встанут. Самое же страшное в нём даже не то, как он предлагает изменить стандарт, а в том, что разработчики компиляторов УЖЕ используют эти фичи новых UB, планируемые к добавлению в стандарт.
Да, я читал, и по-моему все достаточно логично.
Я не говорю "хорошо и мне нравится", просто логично, потому что сейчас это уже происходит или подразумевается, только нестандартизировано :)
И еще раз повторю, мне не нравится С. Мне не нравится UB, я не считаю, что ради двух инструкций нужно так всем сношать мозги. Не нужно меня убеждать, что С — то плохо, а Rust — хорошо, я с вами уже согласен :D
Я вам просто пытаюсь объяснить, как оправдывают наличие UB.
Вы дня начала найдите процессор, который не умеет делать wrap-around.
Вы по ссылкам посмотрели ассемблер? Учитывать, что может быть wrap around; сделать-то его не проблема, разумеется.
И из этого никак не удаётся даже warningа получить, то это, извините, не язык, а минное поле.
Таки да. Мне, собственно, очень не нравится, что многие типы UB, которые можно детектировать на этапе компиляции (или в рантайме в отладочной сборке), не детектируются вообще никак. И вместо того, чтобы починить язык, изобретаются санитайзеры и валгринд...
Запросто. Упомянутое переполнение знаковых. Нахрена это было делать UB? Код всегда будет содержать подобные ошибки, но в том же расте по крайней мере получишь панику или wrap-around.
Потому что чтобы сделать панику или wrap-around нужно ну… сделать это. Сделать проверку или учитывать, что может быть wrap-around.
А если переполнение знаковых это UB, то его не может быть. Программист обязан был это гарантировать, а значит, компилятор может делать вид, что этого не происходит никогда.
Я, собственно, тоже так и поступаю, хотя пишу под микроконтроллеры (где, кажется, есть какой-то культ оптимизации ради оптимизации).
Как человек, однажды потерявший почти готовый пост, отмечу — это научило меня, что свои посты тоже нужно гитовать :)
Уфф, даже не знаю, с чего начать… Это повлечет за собой столько боли.
Питон — отличный пример; третья версия появилась двенадцать лет назад. Вторая все еще здесь. Она все еще нужна. Ее все еще приходится ставить отдельно от третьей.
Ее приходилось поддерживать в течении 10 лет вроде.
В случае с С++ будет гораздо, гораздо хуже; представьте, что в каждой системе нужно будет держать все библиотеки в двух версиях — собранные "по-старому" и собранные "по-новому".
Не забывайте про груз обратной совместимости.
Ну и вообще, мне со своей колокольни тоже кажется, что все просто и понятно, а комитет какой-то ерундой занимается, но на самом-то деле проектировать язык на таком огромном промежутке времени — это чудовищно сложная задача; собственно поэтому все еще не существует идеального беспроблемного языка.
За всех говорить не могу.
Я лично с вами согласен и предпочел бы, чтобы эти оптимизации были исключительно по выбору.
Но имеем то, что имеем.
Ну так, Rust имел потрясающую возможность — учиться на ошибках С и С++ :)
Я и не говорю, что это сложно или что небо упадет на землю, это просто вынуждает компилятор делать дополнительные проверки, т.е. снижать производительность. UB же позволяет эти проверки переложить на программиста, вот и все.
Да, я читал, и по-моему все достаточно логично.
Я не говорю "хорошо и мне нравится", просто логично, потому что сейчас это уже происходит или подразумевается, только нестандартизировано :)
И еще раз повторю, мне не нравится С. Мне не нравится UB, я не считаю, что ради двух инструкций нужно так всем сношать мозги. Не нужно меня убеждать, что С — то плохо, а Rust — хорошо, я с вами уже согласен :D
Я вам просто пытаюсь объяснить, как оправдывают наличие UB.
Вы по ссылкам посмотрели ассемблер? Учитывать, что может быть wrap around; сделать-то его не проблема, разумеется.
Таки да. Мне, собственно, очень не нравится, что многие типы UB, которые можно детектировать на этапе компиляции (или в рантайме в отладочной сборке), не детектируются вообще никак. И вместо того, чтобы починить язык, изобретаются санитайзеры и валгринд...
Потому что чтобы сделать панику или wrap-around нужно ну… сделать это. Сделать проверку или учитывать, что может быть wrap-around.
А если переполнение знаковых это UB, то его не может быть. Программист обязан был это гарантировать, а значит, компилятор может делать вид, что этого не происходит никогда.
Пример:
https://godbolt.org/z/ocvErqG37 — unsigned int, переполнение это wrap-around
https://godbolt.org/z/481ch13ez — int, переполнение это UB
Если что, я не фанат этого момента, мне не нравится ни С, ни С++ — по разным причинам :) Просто объясняю, как сам понимаю конкретно этот момент.
Разумеется, пример высосанный из пальца, это просто демонстрация; но насколько я понимаю, почти все UB в стандарте позволяют делать похожие штуки.
Разумеется, все, что нельзя выразить в типе — нужно записать в пояснении; просто зачем туда тащить формальный тип, он ведь не будет проверятся.
Не лучше ли писать типы в type hints?
А с inline разве не потребует? Заголовочный файл ведь по-прежнему нужно инклудить везде, а определения в нем.
Я думал в стадии противня только члены Комитета :D
Кажется, процесс обсуждения С++ можно описывать семью стадиями принятия…
Как вы справляетесь с отчаянием?
Резонно, такое я даже на практике сам использовал, но боже мой, насколько все это ужасно выглядит все-таки...
Спасибо за пример :)
Ну, если два инклуда содержат объявления одних и тех же функций или типов, то это, по-моему, уже сейчас стреляние в ногу.
Не вижу, почему "необязательная" однопроходность может сломать старый код, но да, наверняка может как-нибудь максимально неожиданно. Эх.
Зачем же тогда все еще требуются эти предварительные объявления, если они не всегда требуются? Т_Т
Интересно, почему даже в 2021 году компилятор не может сделать два прохода по файлу, а не заставлять программиста писать предварительное объявление :(