LINUX.ORG.RU

История изменений

Исправление byko3y, (текущая версия) :

Да, но если я ничего не путаю, то ты как-то писал, что нормальные проекты буст использовать не будут

Весь буст слепо — да, не будут, это симптом рака. Но в бусте есть несколько годных либ.

Ты-то передал объект с «const», но функция дернула метод, который через глобальные ссылки поменял «константный» объект.

Предпочту держаться от такого кода подальше.

Самый-присамый каноничный пример проблемы — оператор присовоения самому себе. У него ведь тоже «const T&», но при этом он сразу же свой аргумент меняет, и потому надо обязательно это дело поднимать костылем из &arg != this.

Формально ты может и прав, но этот «костыль» используют не для того, чтобы всё не ломалось, а для оптимизации. По крайней мере, в нормальном коде

Соберу в кучу эти цитаты, чтобы подчеркнуть, что «держаться подальше» ты от операторов присваивания в крестах не сможешь, потому что это будут уже не кресты, а обычная сишка. Это хороший пример еще и потому, что конструкторы и операторы присовения образуют еще один источник бессмысленного дублирования:

https://en.cppreference.com/w/cpp/language/rule_of_three

Это уже считается нормой, что для объекта нужно создавать три-пять методов, 2-4 из которых делают по сути одно и то же. По идее ведь компилятор вообще не должен был разрешать вызов T& operator=(const T& other), если аргумент меняется в результате вызова, нарушая константность. Но константность в крестах слишком слабая, она мало от чего защищает. Хуже всего то, что создается ложное впечатление будто защита есть.

Если учесть частоту использования операторов присовения, то, грубо говоря, на десять строчек твоего кода будет два тонких малозаметных способа выстрелить себе в ногу. Но ты будешь читать код и не заметишь подобной проблемы, потому что ты годами натренировался именно эти тонкие вещи находить. Я сам в сишке надрессировался вынюхивать тончайшие намеки на трудности при выполнении, но я не испытываю иллюзии по этому поводу и понимаю, что ошибиться в сишке очень и очень просто. В отличие от некоторых наиболее отбитых здесь, которые всерьез рассказывают про «в сишке меньше ошибок, ведь больше контроля над выполнением, не ошибайся — и не будет багов».

Главное, что я не согласен с возможным выводом, что С и какой-нибудь Idris предоставляют одинаковые гарантии, при этом у тебя прослеживается именно этот аргумент

Не вижу, как из моих слов получается такой вывод. Хотя я бы согласился с тем, что стиль писания кода значит не меньше, чем сам язык.

А ты не думаешь, что это не «системному программированию» нужно, а тебе? Кто-то сидит на С и доволен, другие изобретают всякое. Объективно ты не можешь измерить какой язык лучше, только выбрать наиболее подходящий тебе

Я могу оценить ЯП с точки зрения психологии/UX, по отношению к некоторому среднему кодеру в вакууме. Потому что сам средний кодер не способен оценить, насколько удобен ему этот язык, потому что очень часто находится под влиянием синдрома утёнка.

Исходная версия byko3y, :

Да, но если я ничего не путаю, то ты как-то писал, что нормальные проекты буст использовать не будут

Весь буст слепо — да, не будут, это симптом рака. Но в бусте есть несколько годных либ.

Ты-то передал объект с «const», но функция дернула метод, который через глобальные ссылки поменял «константный» объект.

Предпочту держаться от такого кода подальше.

Самый-присамый каноничный пример проблемы — оператор присовоения самому себе. У него ведь тоже «const T&», но при этом он сразу же свой аргумент меняет, и потому надо обязательно это дело поднимать костылем из &arg != this.

Формально ты может и прав, но этот «костыль» используют не для того, чтобы всё не ломалось, а для оптимизации. По крайней мере, в нормальном коде

Соберу в кучу эти цитаты, чтобы подчеркнуть, что «держаться подальше» ты от операторов присваивания в крестах не сможешь, потому что это будут уже не кресты, а обычная сишка. Это хороший пример еще и потому, что конструкторы и операторы присовения образуют еще один источник бессмысленного дублирования:

https://en.cppreference.com/w/cpp/language/rule_of_three

Это уже считается нормой, что для объекта нужно создавать три-пять методов, 2-4 из которых делают по сути одно и то же. По идее ведь компилятор вообще не должен был разрешать вызов T& operator=(const T& other), если аргумент меняется в результате вызова, нарушая константность. Но константность в крестах слишком слабая, она мало от чего защищает. Хуже всего то, что создается ложное впечатление будто защита есть.

Если учесть частоту использования операторов присовения, то, грубо говоря, на десять строчек твоего кода будет два тонких малозаметных способа выстрелить себе в ногу. Но ты будешь читать код и не заметишь подобной проблемы, потому что ты годами натренировался именно эти тонкие вещи находить. Я сам в сишке надрессировался вынюхивать тончайшие намеки на трудности при выполнении, но я не испытываю иллюзии по этому поводу и понимаю, что ошибиться в сишке очень и очень просто. В отличие от некоторых наиболее отбитых здесь, которые всерьез рассказывают про «в сишке меньше ошибок, ведь больше контроля над выполнением, не ошибайся — и не будет багов».

Главное, что я не согласен с возможным выводом, что С и какой-нибудь Idris предоставляют одинаковые гарантии, при этом у тебя прослеживается именно этот аргумент

Не вижу, как из моих слов получается такой вывод. Хотя я бы согласился с тем, что стиль писания кода значит не меньше, чем сам язык.