Коды завершения функции Опции

[ViKo]

Иногда приходится придумывать некие коды, информирующие о той или иной ошибке при выходе из функции. К EXIT_SUCCESS и EXIT_FAILURE добавляются дополнительные. Не задавались ли вы целью привести коды в систему, чтобы пользоваться во всех случаях? Если да, поделитесь, пожалуйста идеями.

[twix]

...

Сообщение отредактировал twix - Apr 24 2018, 10:21

[arhiv6]

Например, есть стандартные системные наборы кодов ошибок: windows, linux.

[ViKo]

Хорошие коды. Но для встроенной программы избыточны. Я предполагаю использовать максимум 8, и то не знаю, зачем мне столько. Есть у кубовского HAL 4 значения.

[Arlleex]

Я обычно пишу модульно. То есть есть драйвер, допустим, EEPROM-памяти. Он оформлен парой файлов EEPROM.c и EERPOM.h.
Ну и для каждого драйвера свои сигнатуры завершения функций.

Код

unsigned int ReturnValue = EEPROM_LoadParameters(&EEPROM);
if(ReturnValue == EEPROM_LOAD_ERROR_CRC)
  printf("WARNING! The EEPROM checksum does not match!\n\n\r");
else if(ReturnValue == EEPROM_LOAD_ERROR_ID)
  printf("WARNING! Installed someone else's EEPROM. Read and write operations will be invalid!\n\n\r");

В файле EEPROM.h при этом где-то в самом верху:

Код

#define EEPROM_LOAD_OK        0
#define EEPROM_LOAD_ERROR_CRC 1
#define EEPROM_LOAD_ERROR_ID  2

Но еще лучше сделать их не #define-ми, а enum-ами. В отладчике проще жить станет.

Ну а вот так, допустим, у меня выглядит заголовочный файл драйвера обмена:

CODE

#ifndef _EXCHANGE_H_
#define _EXCHANGE_H_

#define EXCHANGE_RECEIVE_BUFFER_SIZE 32

#define EXCHANGE_RECEIVE_OK 0
#define EXCHANGE_RECEIVE_ERROR 1

#define EXCHANGE_TRANSMIT_OK 0
#define EXCHANGE_TRANSMIT_ERROR 1

#define EXCHANGE_MESSAGE_HANDLING_OK 0
#define EXCHANGE_MESSAGE_HANDLING_ERROR 1

// структура дескриптора транзакций
typedef struct
{
void *Data;
volatile unsigned int Size;
}TExchangeDescriptor;

// структура принимаемых сообщений
typedef struct
{
#define EXCHANGE_RECEIVE_COMMAND_SYSTEM_RESET 0x12345678
unsigned int Command;
}TExchangeReceiveMessage;

// функция приема данных по внешнему каналу обмена
unsigned int EXCHANGE_ReceiveData(TExchangeDescriptor *ExchangeRxDescriptor, unsigned int Timeout);
// функция отправки данных по внешнему каналу обмена
unsigned int EXCHANGE_TransmitData(TExchangeDescriptor *ExchangeTxDescriptor);
// функция обработки принятых сообщений
unsigned int EXCHANGE_ReceiveMessageHandler(TExchangeReceiveMessage *ExchangeReceiveMessage);

#endif

Я обычно в коде логгирую все исключительные ситуации или просто поведение системы в критических участках или интересующих меня местах, поэтому в коде довольно просто писать лог (см. первый блок кода). Но это все дело вкуса, ИМХО.

Сообщение отредактировал Arlleex - Apr 24 2018, 06:41

[ViKo]

Меня немного смущает, что имя тип возвращаемого кода выглядит "солиднее" имени самой функции.
fpgaConfigRetcode_t Fpga_config(void)

В HAL имеется следующее:
typedef enum
{
HAL_OK = 0x00U,
HAL_ERROR = 0x01U,
HAL_BUSY = 0x02U,
HAL_TIMEOUT = 0x03U
} HAL_StatusTypeDef;

[ViKo]

Ну, вот такой набор прикинул, скомпилировал из разных источников. Годится?
typedef enum {
SUCCESS_OK, // 0
ERROR_GENERAL_FAILURE, // 1 _UNSPECIFIED
ERROR_INVALID_FUNCTION, // _INVALID_HANDLE, _NOT_IMPLEMENTED
ERROR_INVALID_PARAMETER, // _INVALID_ARGUMENT, _BAD_COMMAND
ERROR_NOT_FOUND, // _FILE, _PATH
ERROR_DEVICE_FAILED, // _DEVICE_NOT_EXIST
ERROR_INVALID_ACCESS, // _ACCESS_DENIED, _LOCK
ERROR_NOT_READY, // _BUSY, _LOCK
ERROR_TIMEOUT,
ERROR_MEMORY, // _OUT_OF_MEMORY, _BUFFER_EXCEEDED
ERROR_POINTER,
ERROR_INVALID_DATA, // _READ_FAULT
ERROR_WRITE_FAULT,
ERROR_PROTECT, // _WRITE_PROTECT
ERROR_VERIFY, // _INVALID_CRC, _INVALID_PASSWORD
ERROR_UNEXPECTED // _ABORT
}

[haker_fox]

Ну, вот такой набор прикинул, скомпилировал из разных источников. Годится?

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

CODE

enum TRetVal {
    /* Common result values */
    rvOK = 0x00,        // Операция завершена без ошибок
    rvFAILED = 0x01,        // Операция завершена с ошибкой (общая ошибка)
    rvCRC_FAILED = 0x02,        // Подсчитанная КС неверна
    rvSETTING_ERROR = 0x03,     // Параметры настроек заданы неверно
    rvTIME_OUT = 0x05,      // Операция завершена с таймаутом
    rvUSER_CANCEL = 0x06,       // Выполнение операции прервано пользователем
    rvPARAM_INCORRECT = 0x0b, /** В функцию переданы неверные параметры */
    rvVIRT_FUNC = 0x0c, /** Функция виртуальная, нет реализации */
    rvNULL_POINTER = 0x0d, /** Попытка обратиться по нулевому указателю */
    rvBUSY = 0x0f, /** Процесс занят */
    rvNOT_CONNECTED = 0x11, /* Соединение не установлено */
    rvOUT_OF_MEMORY = 0x12, /* Закончилась память в куче */

    /*CIRCLE BUFFER*/
    rvBUFFER_OVERFLOW = 0x57, /** Переполнение буфера */
    rvBUFFER_EMPTY = 0x58, /** Буфер данных пуст */
    rvBUFFER_FULL = 0x59, /** Буфер данных заполнен */

    /* Measure core */
    rvOFFSET_ERROR = 0x60, /** Погрешность смещения в одном из токовых каналов */
    rvCANT_CALIBRATE = 0x61, /** Невозможно откалибровать */
    rvNOT_CALIBRATED = 0x62,        // Прибор не откалиброван
    rvALRDY_RUN = 0x63, /** Сбор данных уже запущен */
    rvALRDY_STOPPED = 0x64, /** Сбор данных уже остановлен */

    /* Non-Volatile Memory */
    rvDISK_WRITE_ERROR = 0x70, /** Ошибка записи в микросхему памяти */
    rvDISK_NOT_FOUND = 0x71, /** Не найдена микросхема памяти */

    /* Drivers */
    rvCLOSE = 0x80, /* Устройство закрыто */
    rvOPEN_ERROR = 0x81, /* Ошибка открытия драйвера, например не можем считать ID-микросхемы*/
};

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

[ViKo]

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

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

Спасибо, изучу. Идентифицировать буду сразу по возвращению из вызываемой функции, не дожидаясь завершения работы вызывающей функции.
Мне столько кодов не нужно. А если случится непредвиденная ошибка, можно выдать код из наиболее подходящих, или unspecified.

[one_eight_seven]

Ну, вот такой набор прикинул, скомпилировал из разных источников. Годится?

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

Сообщение отредактировал one_eight_seven - Apr 24 2018, 10:19

[ViKo]

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

Я всегда делаю для себя. Но так, чтобы другим было не стыдно показать.
Писал выше, мне много кодов не надо. Сначала хотел 4, потом 8, остановлюсь на 16. Полбайта займет, цэ гарно.

[one_eight_seven]

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

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

Сообщение отредактировал one_eight_seven - Apr 24 2018, 10:32

[ViKo]

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

[Kabdim]

Кстати, у меня ещё вопрос: а как по возвращаемому значению идентифицировать функцию, где произошла ошибка? Так сказать "размотать стек"?

Возвращать PC/LR и по мап файлу смотреть что откуда?

[HardEgor]

Иногда приходится придумывать некие коды, информирующие о той или иной ошибке при выходе из функции. К EXIT_SUCCESS и EXIT_FAILURE добавляются дополнительные. Не задавались ли вы целью привести коды в систему, чтобы пользоваться во всех случаях? Если да, поделитесь, пожалуйста идеями.

Идея одна - у всех функций коды разные. Тем более функции живут на разных уровнях иерархии. Группировать смысла немного.
Поэтому есть 0 = SUCCESS, остальные коды пишутся и обзываются по порядку появления в функции.
Название формирую из уровня иерархии, например HAL_ плюс библиотека _UART и сокращенное название. Сокращенные названия можно брать из стандартных систем, типа Windows/UNIX

[haker_fox]

Возвращать PC/LR и по мап файлу смотреть что откуда?

Тогда функции должны возращать результаты в виде структур, где, собственно говоря, код завершения, и некая служебная информация.

[Kabdim]

У вас в чипе 4Гб памяти? Но в общем, если не паковать - да, структура, так будет проще. Насколько я помню функция может использовать до 4 32битных регистров для возвращения значения. В функциональном мире вроде из функций обычно возвращают Result<T, E>.

[k155la3]

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

Я использую "двуполярный" (положительный и отрицательный) enum.
Критичные ошибки - минус, ноль и плюс - без ошибок и некритичные.
Использую также "битовую" структуру. Взведенный старший бит - флаг наличия ошибки.
Для возврата ошибок через несколько уровней вызова, без использования try-catch,
самый "нижний" код ошибки транслируется "верхними" ф-ми с умножением на 10.
(по разрядности полученной ошибки можно судить с какого уровня "прилетело").

[jcxz]

Насколько я помню функция может использовать до 4 32битных регистров для возвращения значения.

Это в каком компиляторе??

ЗЫ: Имхо - для таких тем нужно завести особую ветку форума. Озаглавить её "Конструирование сферических коней в вакууме". И разрешить вход только истинным кавалеристам.

[ViKo]

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

[jcxz]

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

Мне это известно. Только я всегда думал, что размер структуры в этом случае ограничен sizeof(int)*2. По-крайней мере в IAR for ARM.
Может где-то по-другому?

[AlexandrY]

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

Ща модно говорить - объект. Объект ошибки.
Слово "сруктура" непроизвольно выдает склонность к ископаемым языкам.

[ViKo]

Ща модно говорить - объект. Объект ошибки.
Слово "сруктура" непроизвольно выдает склонность к ископаемым языкам.

Действия и поступки структура и объект - одно и то же (, Айсман)!

[AlexandrY]

Действия и поступки структура и объект - одно и то же (, Айсман)!

Дело не в семантике.
Язык определяет сознание
Поэтому от "структур" уже время отказаться.

[ViKo]

А как насчет высказывания jcxz?

Только я всегда думал, что размер структуры в этом случае ограничен sizeof(int)*2. По-крайней мере в IAR for ARM.

Я думаю, он нагло ошибается.

Дело не в семантике.
Поэтому от "структур" уже время отказаться.

"В свое время мы поговорим и об этом."

[jcxz]

Я думаю, он нагло ошибается.

Может иногда всё-таки лучше почитать мануал?

Код

If the function returns a structure larger than 32 bits, the memory location where the
structure is to be stored is passed as an extra parameter. Notice that it is always
treated as the first parameter.

это о возврате структур.

Код

The registers available for returning values are R0 and R0:R1.
...
long long and double-precision (64-bit) return values: R0:R1

А это - о том как всё-таки можно вернуть структуру размером sizeof(int)*2 в двух регистрах.

[ViKo]

Первая цитата не показывает, что размер структуры ограничен двумя словами.
Вторая цитата не содержит слова "структура".
"Об чем вы, дядя Сидор?"

[Kabdim]

Это в каком компиляторе??
...
Только я всегда думал, что размер структуры в этом случае ограничен sizeof(int)*2.

Вы правы, я неправильно запомнил. Хотя мне казалось логичным сделать Argument = result = scratch, но инфоцентр 5.1.1 Core registers определяет по другому. И по передаче структур больше слова, тоже. Блин на х86 это сделано разумнее.

[haker_fox]

У вас в чипе 4Гб памяти?

ОЗУ? 140 кБ встроенной, и снаружи 32 Мб.

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

Да, это верно. Возвращаем,и даже не задумываемся.

Мне это известно. Только я всегда думал, что размер структуры в этом случае ограничен sizeof(int)*2. По-крайней мере в IAR for ARM.
Может где-то по-другому?

Не совсем понял, о чём вы?

[jcxz]

Первая цитата не показывает, что размер структуры ограничен двумя словами.
Вторая цитата не содержит слова "структура".

Если не умеете читать и понимать даже выдержки из даташита - Ваши проблемы.
Может приведёте какие-то аргументы? Я аргументы привёл, от Вас - только трёп.

Не совсем понял, о чём вы?

О том, что компилятор IAR (for ARM) позволяет использовать для возвращаемых значений до двух регистров (R0,R1).
Если кто-то знает другое (или про компилятор использующий большее число регистров) - плиз приведите аргументы.

[Kabdim]

ОЗУ? 140 кБ встроенной, и снаружи 32 Мб.

Вряд ли эта ОЗУ вся забита кодом, т.е. реально упаковать код ошибки + pc в 32битное слово, или +lr и возвращать 64 бита.

[ViKo]

Если не умеете читать и понимать даже выдержки из даташита - Ваши проблемы.
Может приведёте какие-то аргументы? Я аргументы привёл, от Вас - только трёп.

О том, что компилятор IAR (for ARM) позволяет использовать для возвращаемых значений до двух регистров (R0,R1).
Если кто-то знает другое (или про компилятор использующий большее число регистров) - плиз приведите аргументы.

5.4 Result Return
The manner in which a result is returned from a function is determined by the type of that result.
For the base standard:
 A Half-precision Floating Point Type is converted to single precision and returned in r0.
 A Fundamental Data Type that is smaller than 4 bytes is zero- or sign-extended to a word and returned in r0.
 A word-sized Fundamental Data Type (e.g., int, float) is returned in r0.
 A double-word sized Fundamental Data Type (e.g., long long, double and 64-bit containerized vectors) is
returned in r0 and r1.
 A 128-bit containerized vector is returned in r0-r3.
 A Composite Type not larger than 4 bytes is returned in r0. The format is as if the result had been stored in
memory at a word-aligned address and then loaded into r0 with an LDR instruction. Any bits in r0 that lie
outside the bounds of the result have unspecified values.
 A Composite Type larger than 4 bytes, or whose size cannot be determined statically by both caller and
callee, is stored in memory at an address passed as an extra argument when the function was called (§5.5,
rule A.4). The memory to be used for the result may be modified at any point during the function call.

[jcxz]

И откуда сиё взято? В "IAR C/C++ Development Guide" поиск даже просто любого из слов "containerized" или "128-bit" - Not found.

Вряд ли эта ОЗУ вся забита кодом, т.е. реально упаковать код ошибки + pc в 32битное слово, или +lr и возвращать 64 бита.

Не понятна эта фраза.
Вы предлагаете к адресу возврата прибавлять некое число, которое и является результатом? Тогда после каждой точки вызова этой функции придётся располагать таблицу из N*2 инструкций B (где N - максимальное возвращаемое значение). И на си такое будет сложно проделать.

[ViKo]

http://infocenter.arm.com/help/topic/com.a...0042F_aapcs.pdf
Я, правда, процитировал предыдущую версию. Там есть небольшое отличие, для данной темы несущественное.

[haker_fox]

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

Я вообще никогда не задумывался над этим. Возвращал стурктуры, и всё. Методами класса. Т.к. использую Си++, но это наверно сути не меняет. Возвращал структуры до 100 байт размером. Думаю, что если есть ограничение, компилятор какую-то подстановку выполняет. Но разве это имеет значение?

Вряд ли эта ОЗУ вся забита кодом, т.е. реально упаковать код ошибки + pc в 32битное слово, или +lr и возвращать 64 бита.

По-прежнему не понимаю вас)
Вот пример возвращаемой структуры:

CODE

typedef struct FuncResult {
    CodeResult result;
    uint32_t lrReg;
    uint32_t pcReg;
};

Правильно?

[Kabdim]

Не понятна эта фраза.

Просто битовая упаковка структуры.

По-прежнему не понимаю вас)
Вот пример возвращаемой структуры:

Код

typedef struct FuncResult {
    CodeResult result;
    uint32_t lrReg;
    uint32_t pcReg;
};

Правильно?

В стартовом варианте, до уапковки - да. Только я бы добавил еще bool для детектирование ошибка/без ошибок. Без ошибки значения структуры нужно использовать для возвращения собственно результата.
Т.е. скорее

Код

template<class T, class E>struct Result {
    bool is_valid;
    union {
        T t;
        struct {
            E e;
            uint32_t lrReg;
            uint32_t pcReg;
        }
    }
}

[jcxz]

Я, правда, процитировал предыдущую версию. Там есть небольшое отличие, для данной темы несущественное.

И что? Я разве отрицал, что возможно возвращать более чем два регистра? Да, раз R0-R3, R12 - scratch registers, то (согласно логике) можно хоть все их использовать для return.
Но мне неизвестен такой компилятор, который так делает. Про него и спрашивал.
Вам такой известен?

Я вообще никогда не задумывался над этим. Возвращал стурктуры, и всё. Методами класса. Т.к. использую Си++, но это наверно сути не меняет. Возвращал структуры до 100 байт размером. Думаю, что если есть ограничение, компилятор какую-то подстановку выполняет. Но разве это имеет значение?

А следует задумываться. Конечно имеет. Такой возврат будет выполняться на стеке. И это место на стеке выделяется вызывающим кодом. В точке вызова. Соответственно - в стеке должно быть достаточно места.

[haker_fox]

Только я бы добавил еще bool для детектирование ошибка/без ошибок.

Я бы добавил в эту структуру конструктор для установки членов структуры в значения по умолчанию. Можно добавить метод isError(), isSuccess() и т.д. и т.п.

[one_eight_seven]

Думаю, что если есть ограничение, компилятор какую-то подстановку выполняет. Но разве это имеет значение?

Ну, значение, находящееся в регистрах можно использовать сразу же. Значение, которое сначала сохраняется в память, а потом из неё читается в регистры, чтобы его можно было использовать - запускает как минимум 2 операции работы с памятью, что гораздо медленее, особенно, если у вашей машины нет кэша. Операции с памятью, они, вообще, достаточно дорогие в плане производительности. А, возвращаясь к первоначальному вопросу - возвращению кода ошибки... 2^800 кодов ошибок - это уже слишком В этом случае лучше вернуть наличие/отсутствие ошибки через регистр, а остальное поместить в память, и пусть оно (остальное) считывается, только если нужно.

Сообщение отредактировал one_eight_seven - Apr 25 2018, 09:08

[jcxz]

Я бы добавил в эту структуру конструктор для установки членов структуры в значения по умолчанию. Можно добавить метод isError(), isSuccess() и т.д. и т.п.

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

[Kabdim]

Я бы добавил в эту структуру конструктор для установки членов структуры в значения по умолчанию. Можно добавить метод isError(), isSuccess() и т.д. и т.п.

Конечно, а еще макрос unwrap что бы делал ранний возврат из ошибок и насыпать функциональных map, flat_map, filter. Но это уже другой разговор.

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

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

[jcxz]

возвращаясь к первоначальному вопросу - возвращению кода ошибки... 2:800 кодов ошибок - это уже слишком

Тема изначального вопроса: изобретение сферического коня на все случаи жизни. Наверняка найдётся такой случай который потребует столько значений. А значит и для функции из одной строки возвращающей истина/ложь надо этого коня запрячь. Со всеми вытекающими.

PS: Как показывает практика - универсальные кони нафиг не нужны в реальных проектах. В каждом конкретном случае формат возвращаемых значений следует выбирать наиболее оптимальным для этого конкретного случая. Всё универсальное - неоптимально по определению и годится только для быдлокодерства в ардуино-стиле.

[one_eight_seven]

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

А если не "универсальное", а "унифицированное"?

[Сергей Борщ]

Вот пример возвращаемой структуры:

CODE

typedef struct FuncResult {
    CodeResult result;
    uint32_t lrReg;
    uint32_t pcReg;
};

Правильно?

Неаккуратненько Должно быть как минимум так:

CODE

typedef struct FuncResult {
    CodeResult result;
    uintptr_t lrReg;
    uintptr_t pcReg;
};

[AlexandrY]

Я бы добавил в эту структуру конструктор для установки членов структуры в значения по умолчанию. Можно добавить метод isError(), isSuccess() и т.д. и т.п.

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

[haker_fox]

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

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

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

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

[arhiv6]

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

[Forger]

А кто-нибудь использует для обработки ошибок 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]

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

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

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

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

[Forger]

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

exception - это не замена функции с параметром и последущими switch-case (если функции вложенные, то вообще полный швах - кода много, да толку мало)
это вообще разные вещи и применять их следует в разных ситуациях
Есть неплохие статьи на эту тему: https://habr.com/post/264417/

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

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

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

[dimka76]

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

[jcxz]

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

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

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

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

[Forger]

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

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

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

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

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

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

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

[jcxz]

Я лично использую 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]

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

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

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

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

[AlexandrY]

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

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

[jcxz]

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

Да ладно!

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

Т.е. по Вашему если вместо 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);

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

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

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

[Forger]

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

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

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

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

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

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

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

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

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

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

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

[AlexandrY]

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

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

[Forger]

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

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

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

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

Смотрю там FF.c от ChaN-а на C++, глазам не верю.
Открываю а они там просто расширения всех файлов на cpp исправили.
Вот такой вот c++ теперь.

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

[jcxz]

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

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

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

[Forger]

"Дизасм" это такое окошко в IDE, в котором написаны команды, полученные при компиляции исходника.

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

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

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

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

[AlexandrY]

... не навязываю

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

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

а делимся опытом. По крайней мере хотелось бы в это верить!

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

[Forger]

А пишите как будто навязываете.

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

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

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

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

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

[AlexandrY]

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

Разберитесь, что вам от меня все-таки нужно?

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

[Forger]

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

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

Мне все ясно.

Аналогично!

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

[AlexandrY]

Я использовал их исходники (V1) в своем принтере как есть, ничего не менял
Хотя, имхо, можно было бы вовсе обойтись без этих ваших попыток "померяться пиписьками"...

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

[Forger]

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

Вот она суть - "ничего не менял"

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

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

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

[arhiv6]

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

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

[haker_fox]

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

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

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

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

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

[haker_fox]

Вы как будто оправдываетесь за то что ничего не выкладываете.

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

И я честно не верю в профессионалов у которых нет открытых проектов для души.

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

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

[jcxz]

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

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

[haker_fox]

И получите мешок лайков от тех, кто себе это перетащит.

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

[ViKo]

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

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

[haker_fox]

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

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

[juvf]

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

Код

/*
* -1 если нет связи с двигателем.
* -2 если двигатель уже вкл.
* -3 если есть превышение ветра или нет связи с анемометром при включении
* -4 если нет связи с датчиком вращения антенны
* -5 если открыт люк
* -6 если антенна заброкированна
*  1 включен двигатель 1
*  2 включен двигатель 2
*  0 выключены оба двигателя
*/

офф

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

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

[Forger]

Чужой код - всегда гавно

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

[haker_fox]

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

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

Слышали такое слово "говнокод"?

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

Чужой код - всегда гавно. Каким бы он ни был.

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

[ViKo]

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

[juvf]

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

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

[haker_fox]

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

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

[ViKo]

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

[ViKo]

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

[AlexandrY]

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

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

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

[Forger]

... везде где можно использую глобальные переменные ...

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

Кстати, в данное время я решил выдавать результаты POST проверок бипами, пищалкой.

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

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

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

[AlexandrY]

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

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

[Forger]

Странная идея - добавить еще кода чтобы сделать код более понятным.

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

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

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

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

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

[AlexandrY]

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

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

[Arlleex]

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

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

[Forger]

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

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

Таким образом перенося свою эмоцию на несчастный код.

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

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

А потом еще и изолируетесь от этого кода.

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

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

Ну-ну

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

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



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

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

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

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

[AlexandrY]

С ростом проекта (порядка 50 тысяч строк) глаз обывателя настолько размыливается, что никакой сути из кода понять не возможно. А приложение еще и многопоточное (15 потоков, если память не изменяет).

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

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

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

[Arlleex]

Это у вас весьма маленькое приложение.

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

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

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

Я отлично в нем ориентируюсь. Мгновенно нахожу любые интересующие участки кода.
Могу легко модифицировать архитектуру приложения добавляя функциональность.

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

Практически любую ошибку могу найти в течении дня.

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

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

Сообщение отредактировал Arlleex - May 3 2018, 19:30

[haker_fox]

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

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

Зачем вам передавать вверх?

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

Т.е. в чем корневая причина?

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

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

[AnatolyT]

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

[juvf]

Понятно! У вас тоже общий энум всё-таки не исключён

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

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

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

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

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

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

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

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

[AlexandrY]

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

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

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

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

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

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

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

[Forger]

У AlexandrY код то ещё ни кто не глянул, но зато уже пошла критика, и только за то, что там глобальные переменные.

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

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

чем ваши ООП-эшные извраты.

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

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

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

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

[ViKo]

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

[juvf]

остались лишь максимум синглтоны или в некоторых проектах static объекты внутри соотв. "модуля").

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

[Forger]

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

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

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

Код

class SomeApplication: public Application<.......>, public Singleton<BootLoader>
{
...
}

int main()
{
    SomeApplication::getInstance().initialize();
    SomeApplication::getInstance().run();
}

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

Код

class SomeApplication: public Application<.......>
{
...
}

int main()
{
    static SomeApplication application;

    application.initialize();
    application.run();
}

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