В комплекте GCC в папке arm-none-eabi\include\sys\ есть файл errno.h

Читаемость - это сомнительно, скорее - наоборот: кода больше (лишнего причём), с чего бы читаемость-то тогда повысилась?
А вот монстроидальность такого кода неоспоримо выше!


Оно, насколько я помню, здорово отжирает стек. На МК да ещё с применением RTOS сиё - существенный минус.

Вовсе нет, кода как раз меньше, читается он значительно легче. К такому коду комментарии вообще не требуются.
Кстати, мне крайне редко приходится писать комментарии. А, если комментарий все же требуется, то это признак того, что этот кусок кода потребует последующего допила

По ходу, вы не знаете о чем говорите. Либо мы ведем речь о разных в корне вещах.


Все там нормально работает и жрется стек не так криминально, особенно если камень выбрать правильно.
Конечно же на маленьких камнях exception ни к чему. Он нужен лишь в больших проектах. Впрочем, это я уже указал. Вообше, к чему все это?

В голом С - некая эмуляция exception - бред, реально бред упёртого сишника, который всеми правдами и неправдами ищет способ оправдать свой страх и не желание изучать нормальный инструментарий (в частности C++)

Для аварийных событий я использую механизм ловушек основанный на SVC:
if (j) trap(TRAP_UNEXPECTED_DMA, 0, j);
даёт:



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

Аналогично, но использую для этого RTOS, точнее набор функционала от самой RTOS (я про RTX от ARM), чтобы не городить свой огород



Не спорю, но мы уходим от темы

Справедливости ради там был бред упертого C++-ика
Он просто не знал как это правильно делается на C-и.
Кстати покажите ка свой код, а то не понятно на основании чего стоит прислушиваться к вашему мнению.

Да ладно!

Т.е. по Вашему если вместо func(a, b, c, d) написать:

и вместо одной строчки получить такой "шедевр", то это "меньше кода"???


Ну да, ну да. Конечно Вы знаете, что заменив конструкцию из одной строки компилящуюся в максимум 5 команд, на приличную портянку, получается "меньше кода".
На результат компиляции когда-нить смотрели? Окошко дизасм называется.

Уточните, какие именно куски кода интересуют вас?






Такое "шедевры" закрываю внутри класса-обертки, чтобы и не видеть это безобразия сторонних библиотек.
Кстати, по мне лучше расписать параметры в структуру, дав тем самым ясное назначение каждого параметра, чем вызывать невнятную функцию и давать ей не менее невнятные параметры.
Борьба за число строк кода в данном случае обернется головной болью при каждом чтении функции, в которую суем скопом все эти параметры.


Мне лично начхать на экономию команд на пустом месте (экономия на спичках, кстати, дежавю ...). Мне важен читаемый код. Важнее мифической экономии объема прошивки или чего там.
Давайте уйдем с этой дорожки, пустой это спор.

Я лишь поделился своим подходом - сложные для чтения и понимая вещи прячу внутри простых.
Называется это просто - проектирование.

Погоня за размером кода и производительностью до окончания проектирования - пустая трата времени и сил.
Критичные куски кода можно оптимизировать в дальнейшем. Но если код спроектирован сразу правильно, то это приходится делать редко.

Ардуинщик (по вашей терминологии) скачала кодирует, а потом проектирует. Кстати, CUBE вынуждает делать именно так.
Когда научиться это делать наоборот, станет настоящим программистом )


Очевидно, я наступил на какую-то вашу больную мозоль, натертую вынужденной работой с чужим быдлокодом одного из ненависных вам ардуинщиков.
Я сожалею об этом, но помочь ничем не могу ((

Куски не интересны, лабуду про читаемость оставьте молодым сотрудникам. Только законченные самостоятельные проекты.
Просто интересно откуда берется такая уверенность в преимуществе ваших методов.
А то я уже наблюдаю такие фэйки, как middleware под mbed на С++
Смотрю там FF.c от ChaN-а на C++, глазам не верю.
Открываю а они там просто расширения всех файлов на cpp исправили.
Вот такой вот c++ теперь.

Целиком проект конечно же не выложу - они все коммерческие и почти все можно сказать NDA. Извините (
Opensorce библиотеки не строчу, мне жалко на это время.
Куски кода для примера - без проблем. Но вам они как я понял не интересны, поэтому лучше даже не читайте мои посты, а сразу проходите мимо, не навязываю


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


На халяву и хлорка - сахар ))
Однако, хватает и нормального open-source кода, тока искать нужно тщательно.
Применять, конечно, в чистом виде все равно нельзя, но подсмотреть идеологию и какие-то решения - это святое дело ))

Причём тут ардуинщики-то??? "Дизасм" это такое окошко в IDE, в котором написаны команды, полученные при компиляции исходника.
А "мозоль" - это видимо Вы о себе, раз везде их видите.

PS: И закапывание передачи аргументов внутрь неких "обёрток" ну точно никак не добавляет читаемости коду.
Хотя - каждый сходит с ума по-своему...

Я прекрасно знаю что такое "окошко дизасм", т.к. начинал свою деятельность с голого ASM, постепенно поднимаясь выше.
В конце концов, мы тут вроде как не письками мереямся (надеюсь), а делимся опытом. По крайней мере хотелось бы в это верить!


Не хочу доказывать вам обратное, лень, могу лишь посоветую лишь еще разок окунуться в литературу опытных программистов (иноземных программистов ессно, у них опыта хватает).

зы. Кругозор некоторых людей - круг с нулевым радиусом. Они называют его "точкой зрения".

А пишите как будто навязываете.
Хорошо тогда хотя бы назовите достойные по вашему мнению проекты для embedded на C++.
Но на реальном C++ с применением всего богатства библиотек шаблонов, RTOS, промежуточным софтом и проч., но не оболочки как в mbed.



Вы пока делитесь словами.
У вас же все проекты под NDA!

Ну, с этим спорить не буду. У меня такая манера, не переделать. Впрочем, разве это так важно?



Например: http://smoothieware.org/
Кстати, он open-source, создан довольно талантливыми ребятами. Некоторые решения на мой взгляд спорны, но в целом подход очень эффективный.



Куски кода с соотв. примерами и общая методология вам не интересны, а вот чужие проекты целиком - подавай.
Разберитесь, что вам от меня все-таки нужно?

Класс,
Вы даже не в курсе что это на 90% тот же mbed! и парсер grbl тоже написанный на С
Мне все ясно.

Мне это хорошо известно, но вы невнимательно читали: первая версия (V1) именно так и сделана (хотя не вижу какого-то особого криминала в применении mbed).
Текущая версия V2. Они планировали туда ставить RTOS (nutx или freertos), как щас - не в курсе, хотя это в данном случае неважно.
Я использовал их исходники (V1) в своем принтере как есть, ничего не менял (кроме файла конфигурации), благо китайцы продают клоны их плат с полной аппаратной совместимостью за гораздо меньшие деньги.
Принтер работает круглосуточно уже много месяцев, ни одного сбоя и зависания.
Если бы сам делал этот проект с нуля, то, безусловно, сразу запилил бы туда rtos и соотв библиотеки fat, eth, usb. По возможности коммерческие.


Аналогично!

Хотя, имхо, можно было бы вовсе обойтись без этих ваших попыток "померяться пиписьками"...

Ну почему же, мы успешно померились.
Вот она суть - "ничего не менял"
Эт надо было так тут делится "опытом" чтобы в конце сделать такое признание.

Возвращаясь к теме:
http://softwaremaniacs.org/blog/2005/05/15/exceptions/





Этот код я использовал в своем ЛИЧНОМ принтере, т.е. НЕ коммерческом. Поэтому мне просто начхать на его содержимое. Главное - чтобы работал.
Но некоторые полезности (см. папку src) мне лично показались интересными и познавательными.
В коммерческом продукте я бы не использовал халявный mbed, а искал коммерческие rtos и др. библиотеки (повторяюсь).


Здесь, имхо, подобные петросянские шуточки смотрятся крайне неуместно, особенно в авторстве модератора ресурса!
Если нечего сказать по теме, то не мешайте это делать другим.

Я слышал, что в С++ exception требует много ресурсов. Но я писал об CException, реализации исключений для ANSI C. Setjmp+longjmp+пару макросов ресурсов немного должны занимать.

Коллеги, маленькое лирическое отступление) Прошу не воспринимать, как офф.

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

Но вот, что я замечаю, оказывается профессионалы склонны ругать решения других профессионалов, особенно, когда эти решения кажутся им непонятными. А раз непонятные, то - априори неправильные. Если "его" методы отличаются от "моих", то он как профессионал не состоялся, и мой святой долг указать ему на это. Порой нелестными словами.

Эту ситуацию я наблюдаю на этом и других форумах. В реальной жизни. И прихожу к выводу, что дело вовсе не в том, что ты выложил творение, "достойное только радиокота", либо использовал конструктор и деструктор в ненужном месте, скатываясь к "...кубу".

Предлагаю относиться с уважением к друг другу. И если есть непонимание чужой работы, то не спешить ругать.

У меня создаётся ощущение, что вы чуть-ли не единственный на форуме, который делит людей на тех, кто выкладывает, и тех - кто нет Это не от отекущего топика, а по прочтению многих, т.к. я внимательно читаю вас, мне это интересно!

Чтож, это сугубо субъективный вопрос.

Да, прочёл статью по ссылке. Возник вопрос, а кто мне будет создавать репутацию? Ну вот выложил я проект в сеть. И что, чужие мне люди будут меня оценитьвать? А кто их репутацию мне подтвердит? Странно как-то получается...

Так выложите реализацию UART-а ногодрыгом на задержках. И получите мешок лайков от тех, кто себе это перетащит.
А если выложите что-то реально сложное, то получите только жалобы, что "я вот так делаю и ничего не работает".
Вот так и получается "репутация" от таких выкладываний. Что поделать: демократия - это власть охлоса. И чтобы получить его признание нужно что-то попроще и подоступнее для большинства.

Одын умный и успешный челавэк мне сказал в своё время: тэбэ нэ нужен ничей признаний кроме своего собственного. Пока не признаешь себя сам, никто тебя не признает

Лаврентий Павлович?

А он был успешным? Не, не пересекались)))

не получиться универсального енума, глупости это. ИМХО. Тем более 8 или всего 4 значения. У каждой функции своя задача и свои возвращаемые значения.
мой черновик функции включения вращения антенны



офф


Слышали такое слово "говнокод"? Я думаю это порождение среди прогеров с/с++. Чужой код - всегда гавно. Каким бы он ни был. Либо он "не правильный", либо простой (можно услышать "фу, это аля си"), либо сложный для понимания читателя, либо он просто написан не в том стиле вплоть до того, что табы вместо пробелов, коменты на русском и т.п. Почему среди с/с++ - потому что одно и тоже можно написать 100500 способами, в отличие от других языков. С/С++ даёт творческий подход к решению задачи, и каждый поэт волен и считает что его поэма самая крутая. Язык не ограничивает пределы фантазий. Можно замутить такой оверинженеринг - шопипец, и при этом показать "смотри какой я крутой, как я могу?"

С таким подходом весь этот ресурс можно смело закрывать

Как вы передаёте код ошибки при вложенном вызове функций? Т.е. снизу на верх?

Ну конечно слышал, как и множество других мерзких слов. Тут вопрос в другом, позволить себе использовать это по отношению к другим, или нет?

Я понял, что вы имеете в виду Мне такие намёки тоже делали. Не прямыми словами. Когда я парировал, что это мой собственный стиль написания кода, человек, оскорбивший моё творчество, сватил жёсткий "батхёрт", и начал меня учить, что стили в коде это совершенно другое. В общем его задача была обругать, а не понять. И ему мои объяснения (хотя он мне и не начальник) были совершенно не нужны. К слову, его код постоянно подвергается справедливой (на мой взгляд) критике. Не ругане, а критике. Поэтому делаю вывод (не только по этому случаю), тот кто умеет делать дело, других ругать не станет. Максимум - аккуратно посоветует, как можно по-другому. Ну, а возомнивший себя профессионалом, будет изрыгать огонь налево и направо, при этом тащась от творений себе подобных

Я постарался дать обобщенные имена ошибкам. А как их интерпретировать, зависит от того, что ее выдало. По мне, 16 имен хватит за глаза.

Чаще я ошибки обрабатываю на месте и мне не нужно их передавать выше. Если нужно выше передать, то делаю общий енум кодов ошибок для отдельного куста.

Понятно! У вас тоже общий энум всё-таки не исключён
У меня была задача передавать коды ошибок "на верх" не только через иерархию функцию, но и устройств. Т.е., например, "железяка1"-"железяка2"-"комп".

Кстати, в данное время я решил выдавать результаты POST проверок бипами, пищалкой. Вот здесь уже использую перечисление ошибок конкретных устройств. Но это - другая сущность. Тоже 16-ти штук хватит за глаза. Может быть, и не только бипами ограничусь. Есть еще куда выдать.

Можно даже скомбинировать тип устройства и тип ошибки. Можно в один байт упаковать! "Остапа понесло."

Зачем вам передавать вверх?
Это как минимум выставляет дополнительные требования ко всем программным интерфейсам снизу вверх.
Сковывает рефакторинг. Увеличивает объем кодирования. Рассеивает точку внимания. Вызывает новые зависимости.
Т.е. в чем корневая причина?
Вас заставляют так делать, делаете библиотеки, корпоративный стандарт, используете IDE с ограниченными возможностями рефакторинга или что?

Я скажем везде где можно использую глобальные переменные и синглтоны. Очень удобно и лаконично получается.

Это многое объясняет


Наверно, есть смысл разделять ошибки на критические (аналог исключений в C++) и обычные, "рабочие".
Критические это те, которые не дают нормально работать приложению, т.е. аварийные.
Бипами, имхо, стоит афишировать критические ошибки (как на многих мат. платах компов).

А обычные ошибки лучше всего обрабатывать в коде именно в том месте, где производится вызов некой функции, которая возвращает ошибку.
В идеале нужно обрабатывать ВСЕ возможные ошибки, которые может возвратить некая функция. Т.е. предусмотреть поведение кода на ЛЮБУЮ ситуацию.
А передавать эту ошибку дальше не есть хорошо - это называется "скинуть ответственность", что всегда плохо заканчивается, зачастую создавая настолько редкие баги, что потом их ищут неделями.
Самый простой случай, когда код ошибки - возврат true/false, его очень просто обрабатывать (if ... else), читать и понимать такой код тоже очень просто.
Поэтому я тоже не понимаю таких вещей как "глобальные ошибки", универсальный набор ошибок и т. п. Сопровождать и отлаживать такой код - крайне неблагодарное занятие.
Как тут уже говорили комрады: универсальные решения - зло. Каждый кусок кода (модуль) должен делать именно то, что должен, и не более того.

Если же по необходимости используется сторонняя библиотека, то передавать возвращаемые ею ошибки дальше по коду - не есть хорошо. В последствии это принесет немало геморроя (см. выше).
Поэтому я лично предпочитаю "изолировать" внешние библиотеки от основного кода т. н. обертками (wrapper), в которых скрыта вся "черновая" работа по разгребанию результатов работы "неуклюже" написанной библиотеки.
А сам функционал (интерфейс) этой "обертки" урезать до минимума, оставляя самое необходимое и реальное важное.
При использовании исключений C++ можно "кидать" некоторые действительно важные исключения, но их обязательно нужно документировать, чтобы потом в коде правильно их "отлавливать".
Так же как аналог подобных критических исключений (как тут уже говорили выше) отлично годятся SVC вызовы. Их можно использовать на asm/c/c++.

Странная идея - добавить еще кода чтобы сделать код более понятным.
На самом деле эта изоляция - это наказание любителям плюсов вокруг которых все либы написаны на C.
Они вынуждены писать изоляцию чтобы скрестить ежа с ужом.

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


Плюсы тут ни при чем. Изолировать чужой говнокод можно даже на асм-е.
Можно даже изолировать чужой C++ говнокод на голом С, если в этом, конечно, есть особая нужда.
Однако, на плюсах (или другом аналогичном языке) грамотно проектировать проект намного проще и поэтому значительно удобнее в использовании и дальнейшем сопровождении кода.
Это вам скажет любой профи, который после ручной пилы освоил электро-лобзик, бензопилу и т.п. : ручную пилу он будет использовать лишь для мелких поделок и допилов.


В который раз прихожу к выводу, что вы не достаточно знакомы с предметом этого разговора и поэтому судите весьма поверхностно. Увы
Но это вполне нормально - чего-то не знать или не уметь. Ведь это поправимо: нынче очень много полезной развивающей литературы, было бы желание

За употребление слова "говнокод" я б вас забанил.
На самом деле так называют код в котором не могут разобраться, не знают контекст в котором он писался и для кого писался.
Таким образом перенося свою эмоцию на несчастный код.
А потом еще и изолируетесь от этого кода.
Вам похоже тяжело дается чужой код.
Дам вам совет. Не воюйте с кодом, а делайте его своим.
Начните с перехода на чистый С-и с урезанными синтаксисом, лучше даже MISRA-С. Пишите на языке на котором написана основная масса вашего кода.
Освойте рефакторинг, и увидите как у вас пропадут отрицательные эмоции к коду.

Был у нас embedded-проект один, где всякие флажки функций и прочая чепуха хранилась в глобальных переменных. С ростом проекта (порядка 50 тысяч строк) глаз обывателя настолько размыливается, что никакой сути из кода понять не возможно. А приложение еще и многопоточное (15 потоков, если память не изменяет). В итоге уже сколько времени рефакторим код, поскольку оно то ломается хрен знает где, то просто встроить какой-либо функционал становится нетривиальной задачей. Мне опыта "сопровождения" такого кода лично хватит на всю жизнь. Плюс ни о какой потокобезопасности речи нет. В общем, лично я пишу с минимизацией внешних связей, обрабатываю все ошибки, возвращаемые функциями в основном локально, то есть принимаю решение на месте по коду, что делать с результатом выполнения функций. Если прямого выхода нет - сообщаю внешним функциям, что что-то пошло не так. Рано или поздно такая цепочка заканчивается сама. А сопровождать такой код становится куда проще, и читаемость хорошая. Добавлять функционал или (что еще сложнее, порой) изменять текущий - в разы легче, чем держать в голове тысячу зависимостей от всех этих глобальных переменных.

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


"Эмоция" ... это что-то новенькое! Видать, вам волей-неволей приходится работать с подобным "несчастным кодом" ...
Печально слышать

Если вижу подобный код - нафик удаляю (с SHIFT+DELETE), ибо "хранить всякий хлам на балконе" у меня никак не получается ((


Вы явно не понимаете, почему приходится "изолировать" чужой код из сторонних библиотек, в т. ч. коммерческих.
А то получается некий "разговор глухого с немым".


Ну-ну


Так и хочется сказать: "аминь", но промолчу



зы. У меня ВЕСЬ код написан на С++, вот на нем и пишу ВЕСЬ проект, сторонние библиотеки "изолированы" соотв. классами-обертками.
А обратно в "джунгли" - "чистый С-и" и уже тем более c неким "урезанными синтаксисом" - не вернусь ни за какие коврижки!










Абсолютно согласен!

В свое время (много лет назад) я тоже "наелся" последствий подобной "глобализации" ...

Это у вас весьма маленькое приложение.
В каком редакторе вы его пишите и сколько человек занимается этим проектом?

В моем публичном проекте, где большинство переменных глобальные сейчас 393654 строки, около 20 разных задач, 1100 файлов.
Это только для одного из двух процессоров.
Я отлично в нем ориентируюсь. Мгновенно нахожу любые интересующие участки кода.
Могу легко модифицировать архитектуру приложения добавляя функциональность.
Практически любую ошибку могу найти в течении дня.

Дело не в наличии или отсутствии глобальных переменных, а в том как и кто их оформляет.

А я и не говорил, что оно единственное и самое большое из всех, что писали.


Xilinx SDK (Eclipse), проектом занимался сначала один, теперь 3 человека (но это не основная работа, а факультативная - вычистить беспорядок, так сказать).


Вот в этом как раз и проблема, что только Вы (возможно) в нем отлично ориентируетесь. Другое дело новичок, открыв Ваш проект, без Вашей помощи, разберется что там и к чему?
Я тоже в своих проектах разбираюсь быстро даже спустя год после последнего открытия. А также и мои коллеги, в случае моего долгого отсутствия, могут открыть и понять, где что подправить и где какую логику дописать.
Напомнило мне недавние размышления (это так, между делом, на работе) о незаменимости сотрудников. Напишет проект человек, напишет так, что только он в нем разбирается, накидает туда своих костылей, напрограммирует там методом "bug and fix", а потом попробуй уволь такого сотрудника. Выпытывали недавно тут одного такого, мол что за бардак в прошивке, ничего не ясно (хотели взяться за сопровождение), а он в ответ - "все константы и логика - у меня в голове и точка". А блок работает серийно, нужно внести изменения, а разработчик - ни в какую. Уволить - не могут - прошивки и исходники на личной флешке, да и сама логика работы - у него в голове лишь (хотя местный дядя в погонах может за это на ж*пу посадить при надобности, но это волокита и до этого еще можно заново все разработать).


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

История с глобальными переменными как-то мне напомнила историю с электронными мозгами тойоты...

Ну это уже бардак в организации рабочего процесса. Какие могут быть личные флешки? Git, svn решают проблему. А пушить в них - обязательное требование конторы.


Ну, а как пользователь за компом узнает, что произошла ошибка на нижнем уровне? И неисправимая ошибка.

В желании диагностировать любую, даже самую мелкую ошибку на нижнем уровне.

А как бы вы поступили, к примеру в следующем случае: пользователь жмёт кнопку запуска двигателя, а у двигателя отказал датчик (любой). Запуск без датчика невозможет в принципе, либо возможен, но в ограниченном режиме. Как передать эту "мелкую" ошибку от платы датчика к плате управления двигателем, а затем - наверх скаде?

Пишу для м\к на чистом С, для приложений на пк использовал паскаль, с++ (делфи, билдер). Исключения сам обрабатываю только в по для м\к. Функция возвращает всегда, или почти всегда, результат целого типа. Положительные значения это результат (символ, беззнаковое целое, указатель в массиве или булевое значение), отрицательные это код ошибки, ноль это ок и также может быть результат (булевое значение). Код ошибки передается наверх из вложенных функций по цепочке к обработчику исключений. Если необходимо возвратить строку, float или знаковое целое, передаю во входных параметрах указатель на переменную или на массив. Кодов ошибок немного, не более 10 или меньше, в разных задачах свои, не старался их стандартизировать, описываю их в определениях в заголовке проекта, для разных проектов коды ошибок свои. Всегда стараюсь использовать только стандартные библиотеки компилятора, самые простые функции.
Если использовать коды ошибок совместно, наверно следует договориться с коллегами, думаю лучше если ведущий группы сам определит коды ошибок для всех в группе.

Да, не исключен. Но он не универсальный для всех случаев жизни. для двигателя я привел енум. Там не будет DEVICE_NOT_FOUND или ERROR_OPEN_FILE.



Я же говорил, что чужой код всегда гэ. "говнокод" - это не ругательство, а синоним слова "чужой код" (хотя может "чужой код" - это и есть ругательство ))) . У AlexandrY код то ещё ни кто не глянул, но зато уже пошла критика, и только за то, что там глобальные переменные. А может его код с глобальными переменными гораздо понятнее и безопаснее, чем ваши ООП-эшные извраты.

то, что там кто-то не может разгрести чьи-то спагетти с глобальными, так это проблема не глобальных переменных, а проблема автора и/или читателя кода. Автор мог написать вам код без глобальных переменных так, что вы бы вообще не разобрались.

если всё крутиться на ПК, то я на нижнем уровне генерирую сигнал с текстовым сообщением для юзера, а ГУИ поток этот сигнал обрабатывает слотом с выводом MessageBox и логированием.



между платой датчика и платой управления двигателя свой протокол обмена. в этом протоколе определены свои коды ошибок. плата управления двигателем обрабатывает эту ошибку. например у меня два датчика. датчик передает код ошибки "превышение вращения". Плата управления обрабатывает эту ошибку по своему алгоритму и делает соответствующие действия, в скаду передается (по совершенно другому протоколу) "превышение вращения с датчика 2". Или вообще может передаться интегральное состояние всего привода. Т.е. тут уже свой набор ошибок.

Если заметите, то в 10 главных правилах MISRA ничего не говорится о глобальных переменных, а говорится только о необходимости сузить по возможности область видимости переменных.
А что такое у меня область видимости? Это весь проект!
Если б я писал библиотеки, то наверно завернул бы все переменные в static структуры.
А так мне глобальные переменные экономят кучу кода, соответственно код становится меньше и понятнее.

Код нельзя сделать понятнее закрыв другим кодом, он становится понятнее когда его становится меньше. С этим спорить не будете?

Барр когда критикует кучу глобальных переменных ссылается на то, что на них могут случайно воздействовать сторонние программисты.
Но у Тойоты тот код мог писать один программист, либо они проблему опасных взаимодействий решают организационно, а не средствами языка.
Ведь по сути весь OOП это в основном средство решения проблем коллективного взаимодействия.
В плане личной продуктивности ООП не дает ничего.

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

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

Подумайте, разве это не противоестественно не хотеть быть незаменимым?
По моему это желание не конфликтует ни с современной моралью ни с этикой.

Ну, код как код, такого в интернетах вагон и маленькая тележка.
Гитхаб завален подобным кодом. Но как известно "дареному коню зубы не смотрят"

А действительно серьезный код с хорошей достойной документацией, сопровождением и внятным содержимым стоит соотв. денег.
Либо как щас принято - часть бесплатно (чаще всего ядро ОСи), но все остальное - за денежку.

Выдаете себя: ругаете то, чего, похоже, не понимаете

Прохожу мимо любого кода, при чтении которого "спотыкаюсь" на каждом символе.
Наверняка, многим попадались книги, написанные аналогичным образом, но судьба их проста - идут на растопку дров. С подобным кодом - аналогично.
А глобальные переменные - как лакмусовая бумажка, говорят о том, что в этом коде не все так просто - могут быть грабли в самом неожиданном месте.
Безусловно, в примитивных проектах глобальные переменные навряд ли создадут какие-то серьезные проблемы.

Кстати, в свое время мне по необходимости пришлось уйти от глобальных объектов (остались лишь максимум синглтоны или в некоторых проектах static объекты внутри соотв. "модуля").
Поэтому есть с чем сравнить. Скажу так - обратно не вернусь, ибо к хорошему привыкаешь быстро

Я - о своем. Все уже придумано до нас.
https://ru.wikipedia.org/wiki/Errno.h
Для меня этого слишком много.

а я ушел от синглтонов. Сам писал синглтоны, чужой код смотрел/сопровождал с синглтонами..... абсолютно ненужная сущность. Скажу так - обратно к синглтонам не вернусь, ибо к хорошему привыкаешь быстро

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

В некоторых моих текущих проектах он остался лишь только в одном месте:


Но в остальных уже заменен на такую конструкцию:

В принципе "static SomeApplication application" - единственный в проекте объект с квалификатором "static", а тут он еще и внутри main объявлен, что вообще напрочь закрывает к нему доступ из любого другого места даже в самом файле, где реализуется этот "main()".
Поэтому считаю такое решение пока что вполне допустимым.