[haker_fox 60]

......вот так и рождается калокуб. Когда для записи одного значения в регистр периферии вызывается куча функций и получается монстр..... :laughing:

Я не знаю, что такое "калокуб", хотя наслышан о нём. А вообще, какая разница у кого что рождается, главное, чтобы у самих всё было замечательно :rolleyes:

 

Как-то мало энтузиазма.

Наверно начать надо было бы с абстрактного синглтона фабрики объектов ошибок.

На фабрике регистрировались бы все заинтересованные сторонние классы которым нужно знать и реагировать на ошибки.

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

И крышеснос готов.

Ох... житие мое :rolleyes:

 

[arhiv6 14]

А кто-нибудь использует для обработки ошибок CException или что-нибудь подобное? Вот ещё о нём: Обработка исключений на языке C.

[Forger 17]

А кто-нибудь использует для обработки ошибок CException или что-нибудь подобное?

Поделюсь своим небольшим опытом ))

 

В толстых проектах - обязательно С++ и exсeption.

В маленьких и средних тоже С++, но без тяжелых exсeption (отъедает много места у маленьких камней).

 

Стараюсь всегда избегать функций (в C++ методов), которые помимо основной своей задачи еще и возвращают код ошибки.

Максимум - такая функция возвращает bool. Это дает возможность дать фунции осмысленное имя в соотв. с построением языка носителя - английского.

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

 

Например, нужно дождаться какого-то события (освобождения мьютекса), использую такую конструкцию:

if (someSemaphore.isWaitingDone(100ms))
{
.....
}else...

 

Если нужно ждать бесконечно, то просто:

someSemaphore.wait();

 

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

Для критических ошибок лучше использовать журналирование (отладочный порт, встроенный журнал или типа того.).

 

Чем проще входная и выходная часть функции, тем проще ее применять.

Кстати, насчет входной части: если в функцию передается более двух параметров, то такая функция требует перестроения.

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

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

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

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

В случаях вынужденного использования чужого кода "as is", такие страшные функции лучше изолировать т. н. "обертками" (в С++ для этого отлично годится понятие класс).

 

Короче, сложные запутанные куски кода прячьте в простые и однозначные модули, узлы, классы и т. п.

Давайте сущностям (функции, объекты) полные и однозначные имена. Это навык в дальнейшем очень сильно пригодится.

 

 

Вы правильном мыслите в сторону exeption, но на голом C это - сто шагов назад, ближе к эпохе неолита )))

Правильный путь - изучать С++, а точнее грамотное проектирование на нем.

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

 

 

зы. недавно в своем "любимом" Keil я перешел на С++11/14 (компилятор v6.10), кстати код получается меньше и быстрее

Можно сказать "пришлось" это сделать, т. к. С++03 (компилятор v5) сильно ограничивает применение чужого кода, который в большинстве своем требует как минимум C++11.

[jcxz 184]

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

Ну да - заменяя на монстроподобный механизм exception.

 

Сейчас остается все меньше и меньше кода на голом С, он явно умирает, равно как и умер в свое время ASM в чистом виде

Сейчас всё меньше и меньше народу пишет на си, всё больше быдлокодят на абдурине. Следуя Вашей логике - так и следует делать.

И все остальные утверждения - по меньшей мере спорны, если не полностью ложны.... :laughing:

[Forger 17]

Ну да - заменяя на монстроподобный механизм exception.

exception - это не замена функции с параметром и последущими switch-case (если функции вложенные, то вообще полный швах - кода много, да толку мало)

это вообще разные вещи и применять их следует в разных ситуациях

Есть неплохие статьи на эту тему: https://habr.com/post/264417/

 

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

Причина этому у меня лично очень простая - не очень хорошая память и лень:

не могу в голове удерживать десятки невнятных функций с их кучей параметров и лень рыться в мануалах каждый раз как их использовать ))

 

 

всё больше быдлокодят на абдурине. Следуя Вашей логике - так и следует делать.

Я смотрю, ардуинщики для вас - больная тема :cranky: А быдлокодеры - это вообще отдельная каста "программеров". Приходится с ними часто работать? Тогда сочувствую (((

Кстати, редкий ардуинщик понимает, что имеет дело с вполне полноценным С++ компилятором под AVR и потому строчит он по сути на голом С.

 

 

 

[dimka76 42]

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

[jcxz 184]

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

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

А вот монстроидальность такого кода неоспоримо выше!

 

exception - это не замена функции с параметром и последущими switch-case

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

[Forger 17]

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

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

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

 

А вот монстроидальность такого кода неоспоримо выше!

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

 

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

Все там нормально работает и жрется стек не так криминально, особенно если камень выбрать правильно.

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

 

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

[jcxz 184]

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

Для аварийных событий я использую механизм ловушек основанный на SVC:

if (j) trap(TRAP_UNEXPECTED_DMA, 0, j);

даёт:

CMP      R4,#+0
BEQ.N    ??isrDMA0_2
MOVS     R2,R4
MOVS     R1,#+0
MOVW     R0,#+321
SVC      0x2                                    
??isrDMA0_2:

 

Кстати, редкий ардуинщик понимает, что имеет дело с вполне полноценным С++ компилятором под AVR и потому строчит он по сути на голом С.

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

[Forger 17]

Для аварийных событий я использую механизм ловушек основанный на SVC:

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

 

 

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

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

[AlexandrY 3]

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

Справедливости ради там был бред упертого C++-ика

Он просто не знал как это правильно делается на C-и.

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

[jcxz 184]

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

Да ладно!

экземпляр структуры, которую нужно заранее создать и вписать в нее нужные параметры.

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

struct T1 {
  int a, b, c, d;
} t1;
t1.a = a;
t1.b = b;
t1.c = c;
t1.d = d;
func(&t1);

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

 

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

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

На результат компиляции когда-нить смотрели? Окошко дизасм называется.

[Forger 17]

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

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

 

 

 

 

 

Т.е. по Вашему если вместо func(a, b, c, d) написать: и вместо одной строчки получить такой "шедевр", то это "меньше кода"??? :smile3046:

Такое "шедевры" закрываю внутри класса-обертки, чтобы и не видеть это безобразия сторонних библиотек.

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

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

 

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

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

Давайте уйдем с этой дорожки, пустой это спор.

 

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

Называется это просто - проектирование.

 

Погоня за размером кода и производительностью до окончания проектирования - пустая трата времени и сил.

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

 

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

Когда научиться это делать наоборот, станет настоящим программистом )

 

 

На результат компиляции когда-нить смотрели? Окошко дизасм называется.

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

Я сожалею об этом, но помочь ничем не могу ((

[AlexandrY 3]

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

Куски не интересны, лабуду про читаемость оставьте молодым сотрудникам. Только законченные самостоятельные проекты.

Просто интересно откуда берется такая уверенность в преимуществе ваших методов.

А то я уже наблюдаю такие фэйки, как middleware под mbed на С++

Смотрю там FF.c от ChaN-а на C++, глазам не верю.

Открываю а они там просто расширения всех файлов на cpp исправили.

Вот такой вот c++ теперь. :laughing:

 

 

[Forger 17]

Куски не интересны, лабуду про читаемость оставьте молодым сотрудникам. Только законченные самостоятельные проекты.

Целиком проект конечно же не выложу - они все коммерческие и почти все можно сказать NDA. Извините (

Opensorce библиотеки не строчу, мне жалко на это время.

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

 

Просто интересно откуда берется такая уверенность в преимуществе ваших методов.

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

Ну, и чтение нормальной литературы, написанной опытными программерами, которым не в падлу поделится своим опытом ))

 

Смотрю там FF.c от ChaN-а на C++, глазам не верю.

Открываю а они там просто расширения всех файлов на cpp исправили.

Вот такой вот c++ теперь.

На халяву и хлорка - сахар ))

Однако, хватает и нормального open-source кода, тока искать нужно тщательно.

Применять, конечно, в чистом виде все равно нельзя, но подсмотреть идеологию и какие-то решения - это святое дело ))