Это не предложение, а констатация факта. По действующим ПДД это или велосипед (до 0.25 кВт), или мопед, или мотоцикл. И правила соблюдать обязаны.
Речь про то, чтобы как-то выделить в другую категорию это всё.
Да, много кто оставляет отзывы, но не все, у кого поездка была небезопасной по той или иной причине пишут развёрнутый комментарий в отзыве. Люди ленивые. Даже когда вопрос касается их безопасности и безопасности окружающих.
Жаль, что мало кто оставляет отзывы. Не так давно в классе «комфорт» меня прокатили на скорости более 100 км/ч (по ЗСД), но был нюанс: правое переднее колесо — докатка, рассчитанная на 50 км/ч максимум (о чём свидетельствовала яркая жёлтая надпись, да и размеры тоже). Перед посадкой в такси не обратил внимание, а уже в аэропорту написал отзыв — через пару минут водителя уже заблокировали.
С отзывами, собственно, основная проблема в том, что не все пишут их. И если поездка прошла спокойно — это тоже не означает, что всё было хорошо. Вот не заметил бы я, что вместо нормального колеса докатка, не написал бы отзыв, он повёз бы кого-то из аэропорта снова на скорости больше 100 км/ч и в этот раз могла бы не выдержать докатка со всеми вытекающими… И если заметить докатку вместо колеса не так сложно (но не все понимают риски езды на большой скорости), то с другими потенциальными неисправностями всё может быть ещё сложнее.
Вообще, есть такая классная штука как Crew Resource Management — методика обучения персонала, позволяющая снизить человеческий фактор.
В некоторых авиакатастрофах по факту самолётом управлял один человек, хотя в кабине и находилось несколько. Просто авторитет КВС заставлял второго пилота молчать об ошибках, которые допускал КВС, а второй пилот замечал…
Неужели у MPS не нашлось хорошего евангелиста? Понятно, что инструмент весьма специфичный, да ещё и со сравнительно высоким порогом вхождения, но в некоторых отраслях вполне мог бы «выстрелить».
Да, сейчас вполне можно много чего реализовать из интеграций, причём в обе стороны, но MS не так активно интегрирует что-либо со сторонними ресурсами, как со своими. И в первую очередь, скорее всего, им было бы интереснее получить прямой доступ ко всем репозиториям (в том числе к приватным), просто указав в EULA, что пользователь с этим согласен. И на этом датасете обучать свои различные инструменты, доступ к которым далее уже будет по подписке какой-нибудь.
Возможно, Microsoft собирается немного прокачать недавно представленный IntelliCode, а также могут добавить удобные интеграции с остальными частями экосистемы: visual studio online, azure и вот это всё.
C++ оставляет меньший простор для ошибок, в сравнении с чистым C.
Согласен.
А вот те же шаблоны. То, что они раздувают код — это предания из 90-х. Если не верите, то спросите себя: насколько раздувают код те же std::array или тот же std::accumulate.
Зависит от использования. При неразумном использовании будет съедать место на FLASH. Да и сама stl будет съедать место. Придётся компилятору постараться и выкинуть всё лишнее, что не используется, а то и вовсе в несколько проходов оптимизировать, чтобы получить код, который укладывается в заданные ограничения.
единственное преимущество чистого C — это пока еще отсутствие C++ компиляторов для каких-то отдельных платформ
Под ARM более менее хорошо с компиляторами C++, а вот остальной зоопарк — вендоры не спешат делать компиляторы C++, т.к. под их микроконтроллеры большинство пишет на ассемблере или на C, а пишут они потому, что если есть возможность писать на C++, то результат требует доработки напильником или даже серьёзного разговора с компилятором. В итоге имеем порочный круг.
Ну и традиции, типа «диды писали...» :)
Компилятор C++ в среднем есть более сложная программа, чем компилятор C, и в сообществе разработчиков встроенных систем укоренились мифы (часть из которых до сих пор правда) о том, что иногда надо плясать с бубном, чтобы компилятор выдал то, что надо (особенно если весьма жёсткие ограничения по памяти или ещё какие). Поэтому, скорее всего, выбор и идёт в сторону проверенного и безотказного инструмента. Но вполне возможно, что в недалёком будущем это изменится, так как принципиальных проблем нет.
Нет, скорее обсуждаем разумность применения C++ в embedded. С одной простой демонстрацией.
С++ — это просто инструмент, для многих платформ и задач он вполне подходит и я этого не отрицаю.
По-вашему, показанный код с использованием accumulate не далеко ушел от чистого C? И шаблонный array из C++ — это все тот же чистый C?
Компилятор спокойно может из этого кода получить не менее эффективный код, чем из аналогичного на C, так что для меня они эквивалентны.
Использовать ООП с наследованием и полиморфизмом никто не заставляет.
А что использовать от C++? auto — сахар, который никак не влияет. Шаблоны — легко сожрать весь доступный килобайт FLASH. Вообще, под такую платформу даже на чистом C будут проблемы, т.к. подключив какую-нибудь библиотеку легко выйти за допустимые ограничения по памяти (килобайт FLASH — это катастрофически мало для многих библиотек).
Если же никаких шаблонов, никаких исключений, никаких RTTI, осторожная работа с памятью, то для многих контроллеров можно писать и на C++
Речь про то, чтобы как-то выделить в другую категорию это всё.
Любят избыточность.
С отзывами, собственно, основная проблема в том, что не все пишут их. И если поездка прошла спокойно — это тоже не означает, что всё было хорошо. Вот не заметил бы я, что вместо нормального колеса докатка, не написал бы отзыв, он повёз бы кого-то из аэропорта снова на скорости больше 100 км/ч и в этот раз могла бы не выдержать докатка со всеми вытекающими… И если заметить докатку вместо колеса не так сложно (но не все понимают риски езды на большой скорости), то с другими потенциальными неисправностями всё может быть ещё сложнее.
В некоторых авиакатастрофах по факту самолётом управлял один человек, хотя в кабине и находилось несколько. Просто авторитет КВС заставлял второго пилота молчать об ошибках, которые допускал КВС, а второй пилот замечал…
Согласен.
Зависит от использования. При неразумном использовании будет съедать место на FLASH. Да и сама stl будет съедать место. Придётся компилятору постараться и выкинуть всё лишнее, что не используется, а то и вовсе в несколько проходов оптимизировать, чтобы получить код, который укладывается в заданные ограничения.
Под ARM более менее хорошо с компиляторами C++, а вот остальной зоопарк — вендоры не спешат делать компиляторы C++, т.к. под их микроконтроллеры большинство пишет на ассемблере или на C, а пишут они потому, что если есть возможность писать на C++, то результат требует доработки напильником или даже серьёзного разговора с компилятором. В итоге имеем порочный круг.
Компилятор C++ в среднем есть более сложная программа, чем компилятор C, и в сообществе разработчиков встроенных систем укоренились мифы (часть из которых до сих пор правда) о том, что иногда надо плясать с бубном, чтобы компилятор выдал то, что надо (особенно если весьма жёсткие ограничения по памяти или ещё какие). Поэтому, скорее всего, выбор и идёт в сторону проверенного и безотказного инструмента. Но вполне возможно, что в недалёком будущем это изменится, так как принципиальных проблем нет.
С++ — это просто инструмент, для многих платформ и задач он вполне подходит и я этого не отрицаю.
Компилятор спокойно может из этого кода получить не менее эффективный код, чем из аналогичного на C, так что для меня они эквивалентны.
А что использовать от C++? auto — сахар, который никак не влияет. Шаблоны — легко сожрать весь доступный килобайт FLASH. Вообще, под такую платформу даже на чистом C будут проблемы, т.к. подключив какую-нибудь библиотеку легко выйти за допустимые ограничения по памяти (килобайт FLASH — это катастрофически мало для многих библиотек).
Если же никаких шаблонов, никаких исключений, никаких RTTI, осторожная работа с памятью, то для многих контроллеров можно писать и на C++