Да подождите вы, люди еще не созрели до понимания того что дело в правящем классе а не именах президентов) хоть обсменяйся там. Максимум «реформ» которые можно от этого получить, передвижение часовых поясов и легализация электросамокатов, я не знаю. Глупо думать что человек придет на должность и скажет «ой чет олигархи засиделись на газовой трубе, надо их разогнать. А еще войны все прекратить.»
я дико извиняюсь, а что у Хабра (или ТМ) сейчас в России? они вроде «10 правил ведения бизнеса в России» лет 5-10 как выполнили) ну только я так понимаю что часть редакторов/админов хабра физически сами как люди в РФ, но вроде это единственное. Я ошибаюсь?
Не очень понял в контексте «исключения проектировались раньше», ну да, это середина 90-х, вроде еще до шаблонов, как это связано с тем что в статье обсуждаются сегодняшние способы решения (и возможное завтра?)
со slonopotamus согласен, если зацепиться только за «легко проигнорировать» это ну неплохое решение (остается не забывать втыкать атрибут, что тут поделать).
Расширения, хз зачем, nodiscard давно поддерживается. Если рабоаешь в проекте где не завезли 17 плюсы, там куда больше проблем и болей чем «как бы тут клево ошибки обработать»
начиная с C++11 если вы не объявили деструктор throw(...) / noexcept(..), он и так считается noexcept. Это кстати breaking change было, у кого-то даже что-то ломалось от этого :D
я работал с легаси кодовой базой где были исключения в деструкторах, но я не дожил до ее миграции на С++11.
Судя по его цитате «народ принимает решение о том нравится ему специалист или нет» в самом начале статьи у него там полный швах со софт-скиллами, так что неудивительно, что не берут.
думаю по фразе «народ принимает решение о том нравится ему специалист или нет» можно сделлать некоторые выводы. Скорее всего с автором и правда чертовски сложно работать, но фидбек он не в состоянии усвоить.
Да, если у тебя софт скиллы на нуле, не поднимешься выше $3000 не только на PHP, но в любой другой сфере.
Ну лично мне когда я «переустанавливал винды» девушки только что разве кружку кофе на спину не ставили, как Рою из IT Crowd ;)
Для этого надо было еще красивым быть а не просто шарить.
Да что там ffmpeg, это канонический пример сложности командного интерфейса, взять просто тот самый Git, которым разработчики-то уж каждый день пользуются. Я думаю тот кто скажет что со всеми командами гита в консоли разбирался по его справке комнадной строки — немного слукавит.
Если что я сам стараюсь использовать CLI для всех вещей которые приходятся повторять часто. Но спорить с тем что новые штуки куда легче найти в GUI уж точно не буду. Проблемы «не найти крутилку в лабиринте UI» для меня никогда не стояло
Первые несколько абзацев статьи были мысли «шо, опять?», но, к моменту про constexpr проверки позиций настрой сменился на «неплохо, годно».
Я не поклонник шахмат, не знаю, найдут ли полезное в статье именно любители шахмат, но как материал для раздумий над реализацией позиционных игр сгодится (у меня в моем проекте была часть с тактической битвой, что-то похожее применял).
Писать код без него — подобно искусству каллиграфии.
В плане, что так же бесмыссленно на практике?
UB это контракт между программистом и компилятором, чтобы компилятор мог генерировать наиболее оптимальный код.
Я, такой-то такой-тович, со своей стороны, и GCC, именуемый Компилятор, с другой стороны договариваемся:
1. Я пишу такую логику, что обращение к данным по nullptr — недопустимо, а Компилятор может использовать эту информацию и не делать лишних проверок при работе с ссылками/указателями.
2. Я пишу такую логику, что нигде в программе не может быть переполнения знакового числа, и компилятор опять же может использовать это для оптимизации.
3. Я сам контролирую и отвечаю за лайфтайм объектов. Если я куда-то передал ссылку и потом удалил объект, компилятор не обязан за меня как-то чудесным образом следить за тем что ссылка на область памяти не протухла (и опять же не вставлять дополнительных проверок).
и тд и тп.
Т.е. я чисто не согласен с аналогией про каллиграфию) в остальном-то полностью разделяю ваше заявление.
(т.к. люди не представляют на что подписываются, да более того нигде этот «договор» по пунктам не изложен — комитет только в прошлом году озадачился «ой а давайте у нас в одном месте будет список всех UB собран») — способов выстрелить в ногу тысячи.
Ай ладно, написал, перечитал, не, не, согласен про каллиграфию, не так уж и далеко :D
ну его там почти «as is» из буста взяли.
по итогу в стандарт попала версия где все функции продублированы — с исключениями и кодами возврата. (комитет на тот момент не определился, какая стратегия обработка ошибок целевая). Но этого мало, потом пришлось с некоторых версий с кодом возврата снимать noexcept т.к. они таки могут кинуть исключения. сурпрайз (уверен 99% юзеров std::filesystem этого не знают). Ах да, часть функций чисто в одном варианте, т.к. оператор ++ например не сделать с кодом возврата.
Понятно, что на базовом уровне все круто, но если ты делаешь решение которое должны юзать в миллиардах строк кода по всему миру, там немножко выше планка качества) если чо, все выше сказанное это мое высасывание из пальца, это про что сами члены комитета говорят.
скорее:
«Любой язык без той херни которая мне не нужна:»
(клочок туалетной бумаги)
Лично меня как С++ разраба факт появления новых фич не беспокоит. Меня больше беспокоят случаи торопливого добавления фич. Которые по итогу оказываются непродуманными. std::filesystem, модули, да много таких примеров.
Ну как сказать, у меня вот обширный опыт на С++, хелоуворлды на rust с циклами и арифметикой без проблем, но как только попытался что-то более сложное — наследования нет, виртуальных методов нет, вместо коллбеков и каррирования — делай вася агрегирование доп. классов с методами и тд и тп.
Эксперименты с Java/C# чет у меня такого дискомфорта не вызывали, там все плюс минус такое же имеется (ну иногда многословнее, а иногда и поудобнее).
Изучать я Rust однозначно буду и дальше. Но больна.
Ну так существующие пользователи и не будут покупать новую версию если их все устраивает. Как продавать снова и снова (в идеале для бизнеса по подписке) продукт который «просто работает»?
Конечно надо делать редизайны и вносить баги, чтобы оправдать платную поддержку :D
Как программисту на С++ мне это слушать как страшную сказку приходится) Сочувствую Go-разработчикам. Не, строгость это хорошо. Это одобряю. Но вот этот вот AddUint32Uint32 ужасно же.
Не очень понял в контексте «исключения проектировались раньше», ну да, это середина 90-х, вроде еще до шаблонов, как это связано с тем что в статье обсуждаются сегодняшние способы решения (и возможное завтра?)
со slonopotamus согласен, если зацепиться только за «легко проигнорировать» это ну неплохое решение (остается не забывать втыкать атрибут, что тут поделать).
Расширения, хз зачем, nodiscard давно поддерживается. Если рабоаешь в проекте где не завезли 17 плюсы, там куда больше проблем и болей чем «как бы тут клево ошибки обработать»
начиная с C++11 если вы не объявили деструктор throw(...) / noexcept(..), он и так считается noexcept. Это кстати breaking change было, у кого-то даже что-то ломалось от этого :D
я работал с легаси кодовой базой где были исключения в деструкторах, но я не дожил до ее миграции на С++11.
Да, если у тебя софт скиллы на нуле, не поднимешься выше $3000 не только на PHP, но в любой другой сфере.
Для этого надо было еще красивым быть а не просто шарить.
Если что я сам стараюсь использовать CLI для всех вещей которые приходятся повторять часто. Но спорить с тем что новые штуки куда легче найти в GUI уж точно не буду. Проблемы «не найти крутилку в лабиринте UI» для меня никогда не стояло
Первые несколько абзацев статьи были мысли «шо, опять?», но, к моменту про constexpr проверки позиций настрой сменился на «неплохо, годно».
Я не поклонник шахмат, не знаю, найдут ли полезное в статье именно любители шахмат, но как материал для раздумий над реализацией позиционных игр сгодится (у меня в моем проекте была часть с тактической битвой, что-то похожее применял).
Про это я в курсе.
Это никак не отменяет того что в целом использование перегрузки операторов не вяжется с обработкой ошибок через коды возврата.
Пойду пару советов в issue закину
В плане, что так же бесмыссленно на практике?
UB это контракт между программистом и компилятором, чтобы компилятор мог генерировать наиболее оптимальный код.
Я, такой-то такой-тович, со своей стороны, и GCC, именуемый Компилятор, с другой стороны договариваемся:
1. Я пишу такую логику, что обращение к данным по nullptr — недопустимо, а Компилятор может использовать эту информацию и не делать лишних проверок при работе с ссылками/указателями.
2. Я пишу такую логику, что нигде в программе не может быть переполнения знакового числа, и компилятор опять же может использовать это для оптимизации.
3. Я сам контролирую и отвечаю за лайфтайм объектов. Если я куда-то передал ссылку и потом удалил объект, компилятор не обязан за меня как-то чудесным образом следить за тем что ссылка на область памяти не протухла (и опять же не вставлять дополнительных проверок).
и тд и тп.
Т.е. я чисто не согласен с аналогией про каллиграфию) в остальном-то полностью разделяю ваше заявление.
(т.к. люди не представляют на что подписываются, да более того нигде этот «договор» по пунктам не изложен — комитет только в прошлом году озадачился «ой а давайте у нас в одном месте будет список всех UB собран») — способов выстрелить в ногу тысячи.
Ай ладно, написал, перечитал, не, не, согласен про каллиграфию, не так уж и далеко :D
по итогу в стандарт попала версия где все функции продублированы — с исключениями и кодами возврата. (комитет на тот момент не определился, какая стратегия обработка ошибок целевая). Но этого мало, потом пришлось с некоторых версий с кодом возврата снимать noexcept т.к. они таки могут кинуть исключения. сурпрайз (уверен 99% юзеров std::filesystem этого не знают). Ах да, часть функций чисто в одном варианте, т.к. оператор ++ например не сделать с кодом возврата.
Понятно, что на базовом уровне все круто, но если ты делаешь решение которое должны юзать в миллиардах строк кода по всему миру, там немножко выше планка качества) если чо, все выше сказанное это мое высасывание из пальца, это про что сами члены комитета говорят.
«Любой язык без той херни которая мне не нужна:»
(клочок туалетной бумаги)
Лично меня как С++ разраба факт появления новых фич не беспокоит. Меня больше беспокоят случаи торопливого добавления фич. Которые по итогу оказываются непродуманными. std::filesystem, модули, да много таких примеров.
Эксперименты с Java/C# чет у меня такого дискомфорта не вызывали, там все плюс минус такое же имеется (ну иногда многословнее, а иногда и поудобнее).
Изучать я Rust однозначно буду и дальше. Но больна.
Конечно надо делать редизайны и вносить баги, чтобы оправдать платную поддержку :D