Как стать автором
Обновить
-3
0

Пользователь

Отправить сообщение

И это плавно перетекает в следующую проблему: кто виноват в аварии беспилотников?

Вопрос этот уже давно решён. Начиная с SAE Level 3 производитель будет нести ответственность во время работы функции, а также какое-то короткое время после запроса на перехват управления водителю. Собственно поэтому у теслы FSD - это всё ещё Level 2+.

Отказ от HD-карт и лидаров - это типа благо? Ну что же, удачи с кроссвалидацией объектов с камеры, когда верхние красные сигналы впередиедущего грузовика камера определит как красный сигнал светофора, вызывая экстренное торможение на трассе.

В премиальном сегменте ручная регулировка сидений уже давно моветон.

Без сахара стек сам себя не раскрутит и надо после каждого вызова ручками городить if (result.error) return result;, что ничем не отличается от if (error_code != 0) goto cleanup; в C.

Справедливости ради, это работает только в самом простом случае, когда типы Result совпадают у функции и у тех, кого она вызывает. Для конвертации условного IOResult в MyResult синтаксического сахара нет и это всё также надо делать ручками.

Планируемый std::expected мог бы немного улучшить ситуацию, если бы его предлагали в авторском дизайне, но увы:

Using the indirection operator for an object that does not contain a value is undefined behavior. This behavior offers maximum runtime performance.

Это стандартный дизайн типов в стандартной библиотеке C++. Например, std::optional тоже имеет UB в операторе разыменовывания, если значение не было ранее сохранено, но есть более безопасный .value(), который кидает в этом случае исключение (считай аналог unwrap() в Rust). Уверен, что и с std::expected в конце концов сделают также.

А так ли этот синтаксический сахар нужен? В C++ ничего не мешает использовать алгебраические типы данных ошибок и без него (Boost.Outcome, реализации планируемого std::expected или std::variant если уж прямо совсем лень что-то подключать).

Конечно. ISO 26262 для safety critical компонентов, MISRA, AUTOSAR чекеры для вообще всего, что есть в автомобиле.

Это всегда вопрос ресурсов, приоритетов и процессов разработки. И на мой взгляд последнее для встраиваемых систем не так уж и сильно отличается от всего остального мира. SOLID, CI/CD, парное программирование, тестирование кода и т.д. — ничего нового здесь нет.
Я был во многих крупных проектах в эмбеддинге и там, где был грамотно выстроен процесс разработки и ресурсы позволяли, везде была вполне сносная архитектура кода, которая позволяла параллельно работать десяткам и сотням людей над проектом.
Ну а если ресурсов хватает лишь на одного человека на полставки, то немудрено, что код будет тяп-ляп и готово.
Это контракт, который нигде не задокументирован, но неявно вытекает из реализации метода.
И да, и нет. Да, если ваш случай использования совпадает с тем, о чем думал автор при написании. Но часто бывает так, что всякие скрытые контракты авторы библиотек не документируют (потому что не учли), а документации красуется 100% safe.

В хороших библиотеках на С в свою очередь документируется стратегия владения объектами (потому что иначе никто не сможет это использовать) и это в обязанностях программиста следовать им.
Часто ли вы испектируете все зависимости, которые используете? А зависимости зависимостей? У меня вот на мелких проектах с 2-3 зависимостями тянется около 100 крейтов с репозитория. И что, предлагаете все их просматривать и инспектировать на предмет корректности в unsafe коде? Проще застрелиться.
То, что unsafe можно завернуть в safe обертки ещё не гарантирует memory safety для клиентского кода. Кто знает, может в этих safe обертках творится настоящий ад из утечек и повреждений памяти. Клиентский же код будет всё время находится с чувством ложной безопасности до того момента, когда всё упадёт.

Это больше всего напоминает запихивание мусора под ковёр во время уборки.
И что это доказывает? Весь крейт — это обертка над UnsafeCell и unsafe кодом. Там даже тестов нет, так что никто не знает работает ли это вообще или нет. Плюс это лишь для работы с данными внутри прерываниях. Я же говорю про глобальные объекты в целом. Всякие буферы для сетевых операций, большие жирные объекты для логики приложения где хранить как не глобально?
В embedded, куда собственно раст тоже метит, очень часто бывают нужны, потому что там нет динамической памяти и стек очень ограничен.
Даже в чистом расте unsafe бывает часто необходим, например, для доступа к глобальным переменным.
Интересная статья, хоть я с самого начала статьи подозревал, что такой подход не выстрелит. Но если вы вдруг сумеете преодолеть все вышеописанные проблемы в вашем патче, пожалуйста не забудьте также отправить патчик сюда make-linux-fast-again.com. Всё-таки, даже 1% просадки производительности — это очень больно.
В Европе — определённо нет, а в США — это серая зона, лазейками в которой, судя по всему, активно пользуется Тесла. Вся разница в подходе проведения омологации машины — процедуры получения разрешения от государства для выпуска автомобиля на рынок.

В Европе этот процесс заключается в проверке всех систем и функций автомобиля (даже чисто программных) на предмет работоспособности и безопасности использования перед выпуском на рынок. Это довольно дорогой и длительный процесс, и если после этого было внесено хоть одно изменения в омологированные части, то этот процесс нужно провести заново для всего автомобиля, а не только той изменённой части. Поэтому европейскими автопроизводителями это делается только один раз и в последующих OTA апдейтах никогда не меняются старые и не добавляются новые функции. Максимум, обновляется софт головного устройство, которое обычно не является предметом омологации.

В США же процесс другой. Там же достаточно просто сказать государству, что всё проверено ими самими же и что всё прекрасно работает, после чего они получают соответствующее разрешение. Государство же может потом когда-нибудь придти с реальной проверкой, если вдруг начались какие-то странные массовые аварии с участием этого автомобиля. Собственно, поэтому Тесла и вольна (хотя и здорово рискует) обновлять кучу функций с каждым новым апдейтом.
Не понимаю почему все сравнивают с Москвой. Москва — далеко не самый желанный город для жизни с точки зрения экологии, транспорта и недвижимости. Я вот переехал в пригород Мюнхена из Самарской области, и качество жизни после этого выросло в пару раз. Природа здесь чище, общественный транспорт гораздо лучше развит (до центра Мюнхена могу добраться за 30 минут), медицина тоже лучше (тут нет такого понятия, как «приписанный к поликлинике», выбираешь сам себе врача по отзывам).

Да, в Москве больше денег, но Москва — не вся Россия. Да и вообще, деньги — не самое главное в жизни. Есть вещи, которые в определённый момент становятся важнее денег и из-за которых люди и решают переехать.
Мы с вами немного похожи, мне тоже 29, хоть и пишу на плюсах гораздо меньше (лет 7-8 промышленной разработки). Выгорание тоже порой случалось, но каждый раз получалось из него выкарабкиваться.

Вообще, мне кажется, что в вашем деле плюсы — дело десятое. Скорее просто вы потеряли к этому интерес, потому как большой опыт этому способствует. Кажется, что ты всё уже знаешь, есть стабильная работа и нет стимула развиваться. Мне кажется, что вам просто уже не нравится та сфера, которой вы занимаетесь. Просто попробуйте найти то, что будет приносить вам удовольствие. Даже не нужно бросать плюсы, можно просто сменить область их применения. Занимались раньше сетью и хайлоадом? Попробуйте embedded, GUI, GPU computing. Ну или наоборот.

Откровенно говоря, плюсы — замечательный инструмент с уникальными возможностями. Не обязательно гнаться за последними стандартами и знать каждый кейс UB наизусть. Я даже вам немного завидую, ведь у меня на работе только недавно C++11 появился и до полноценного перехода на C++17/20 ждать ещё лет десять. Можно просто решать конкретные задачи, не используя все возможные конструкции, и это нормально. Самое главное — чтобы задача была выполнено, а как — дело десятое. Это, кстати, бич всех сеньоров-помидоров — они хотят сделать всё идеально. Но на это убивается бесконечное количество ресурсов, в том числе эмоциональных. Ведь правду говорят, «Лучшее — враг хорошего».

Что касается накопленного опыта, то не стоит трястись над ним как над сундуком с монетами. Это лишь ваш личный багаж знаний, который может помочь в различных ситуациях, но он может быть абсолютно бесполезен в других. Конкуренция на рынке никуда не девается и с каждым годом появляются новые люди с горящими глазами, готовые изучать всё новое без оглядки на старое. Поэтому крайне важно тоже всегда оставаться открытым всему новому (новый фреймворк, язык, технология и т.д.). Да, годы потихоньку берут своё, запал кончается, но надо стараться. Если совсем опустить руки, то вы можете оказаться у обочины нашей сферы (где все те программисты на Дельфи?).

Поэтому не надо бояться время от времени сбросить балласт накопленных знаний и двинуть к чему-то новому, интересному. Да, первый год будет просадка по зарплате, да придётся учиться заново как будто вам 18 лет, но это окупится со временем. Можно считать это своеобразным рефакторингом вашей личности.

Самое главное — чтобы вам нравилось то, чем занимаетесь. Не важно что это — плюсы и разведение коз. Вообще, жизнь дана на то, чтобы получить от неё удовольствие.
Это значит — переделать всё, начиная с загрузчика.

Вперёд, можете начинать! Дайте знать когда закончите.
Они в этом году уже договорились с Hyundai чтобы поставлять им решение для селфдрайвинга.
1

Информация

В рейтинге
Не участвует
Зарегистрирован
Активность