А как вызывающий должен догадаться, что функция не возвращает значения, если это функция, а не процедура (раз уж у вас есть разделение на функции и процедуры)?
К тому же, внутри функции может быть ветвление и по одной ветке значение возвращается, а по другой — нет.
Извините, но по-моему вы как будто специально footgun в язык вносите такими фишками :)
В gstreamer'e (фреймворк для работы с мультимедия) есть такие модули вывода изображений — aasink и cacasink. Позволяют выводить видео в виде ASCII-графики (например, с веб-камеры).
Статичное изображение, к сожалению, не передает всю прелесть такого видео, но хоть что-то:
Не являюсь специалистом по Go, поэтому ничего не могу сказать конкретного про него. Рискну предположить, что Go позиционируется как язык для бэкэнда и там GUI просто «нинужен».
Запрет на предприятии? Если так, то да, больно. Если нет, то при использовании FreeRTOS все более чем шикарно. Работа с динамической памятью (при достаточном выделении ресурсов под ее дефрагментацию и прочее) очень удобна.
Ну, прямого запрета нет, только рекомендации MISRA :) Но с фриртосом действительно удобно, хотя бы heap_1 можно себе позволить и стеки руками не создавать.
В самих ядрах косяков либо нет совсем, либо их не много. А вот периферия… Да.
Кхе-кхе… Миландр 1986ВЕ1… Кхе-кхе…
Но да, ошибки в периферии существенно чаще попадаются.
С опытом такие вещи достаточно быстро раскрываются. Особенно если монтаж осуществлял не ты сам.
Ну, понятное дело, что раскрываются, просто каждый раз тратится уйма времени на поиски этих ошибок. А переделать печатную плату — это дело нескольких недель; пока оплата пройдет, пока ее изготовят, пока доставят…
GCC адекватно может в C++14 (около года пишу так).
Keil, к сожалению, только частично умеет в С++11, причем стандартная библиотека осталась от С++98. А их новый компилятор armclang пока сыроват.
Подозреваю, что просто усталость от того, чем чаще занимаешься.
Я лично подустал от невозможности использовать динамическую память, от медленных компиляторов, от кривой поддержки хотя бы С++11, от безумных аппаратных косяков в процах и ошибок монтажа…
Все мы страдаем от несовершенства мира в своем углу.
По-моему, более «традиционный» подход к такому (который исповедуют всякие микропитоны и эспруино) — это интерпретатор на самом проце, с написанием кода в терминале. Не берусь судить, какой подход проще или лучше.
К тому же, внутри функции может быть ветвление и по одной ветке значение возвращается, а по другой — нет.
Извините, но по-моему вы как будто специально footgun в язык вносите такими фишками :)
И точно так же можно словить мусорное значение со стека? Чем это лучше тогда?
Зачем вообще из функций возвращаться, не возвращая значение?
Наверное, все-таки из грибка, а не из бактерии?
Статичное изображение, к сожалению, не передает всю прелесть такого видео, но хоть что-то:
Если что, я насчет Go вообще не в курсе — есть они там или нету.
Ну, прямого запрета нет, только рекомендации MISRA :) Но с фриртосом действительно удобно, хотя бы heap_1 можно себе позволить и стеки руками не создавать.
Кхе-кхе… Миландр 1986ВЕ1… Кхе-кхе…
Но да, ошибки в периферии существенно чаще попадаются.
Ну, понятное дело, что раскрываются, просто каждый раз тратится уйма времени на поиски этих ошибок. А переделать печатную плату — это дело нескольких недель; пока оплата пройдет, пока ее изготовят, пока доставят…
Keil, к сожалению, только частично умеет в С++11, причем стандартная библиотека осталась от С++98. А их новый компилятор armclang пока сыроват.
Я лично подустал от невозможности использовать динамическую память, от медленных компиляторов, от кривой поддержки хотя бы С++11, от безумных аппаратных косяков в процах и ошибок монтажа…
Все мы страдаем от несовершенства мира в своем углу.
По-моему, более «традиционный» подход к такому (который исповедуют всякие микропитоны и эспруино) — это интерпретатор на самом проце, с написанием кода в терминале. Не берусь судить, какой подход проще или лучше.
Другое дело, что такая защита действительно не является гарантией, как справедливо пишут в комментарии ниже.
Вот пара актуальных статей на тему — раз, два.