Логирование данных. Опции

[Jenya7]

Мне нужно логировать данные. Вот пишу универсальный логер. Натраиваю куда писать (SD, Flash, UART) и какие данные писать. Я планирую передавать указатель на переменную или структуру которые надо логировать. Но как быть дальше? Данные надо сериализовать (упаковать в массив) для передачи дальше. И тут я застрял.

Код

void LOG_Send(uint32_t storage, void *data, uint32_t size)
{
    char buf[size];  //size of data???
    uint32_t i = 0;
    while (data)
    {
        buf[i++] = (char *)(*data++);
    }
    
    switch (storage)
    {
        case SD:
          SD_Log("log.txt", buf);
        break;
        case FLASH:
          Flash_Log(log_addr, buf);
        break;
        case UART:
          UART_SendString(UART2, buf);
        break;
    }
}

В строке buf[i++] = (char *)(*data++); ругается на приведение типов.

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

Следующий шаг:

CODE

template<typename T>
void LOG_Send(uint32_t storage, T const & data)
{
     LOG_Send(storage, &data, sizeof(T));
}

Позволяет писать в каждой точке вызова LOG_send(storage, my_struct) вместо LOG_send(storage, &my_struct, sizeof(my_struct)) и связанных с этим ошибок.
Но противники плюсов будут привычно ныть об "увеличении объема кода и подъедании ограниченных ресурсов".

[esaulenka]

Следующий шаг:

Код

template<typename T>
void LOG_Send(uint32_t storage, T const & data)
{
     LOG_Send(storage, &data, sizeof(T));
}

Позволяет писать в каждой точке вызова LOG_send(storage, my_struct) вместо LOG_send(storage, &my_struct, sizeof(my_struct)) и связанных с этим ошибок.

Не-а. Следующий шаг - это разобраться, зачем вообще копировать данные из data в buf.

Но противники плюсов будут привычно ныть об "увеличении объема кода и подъедании ограниченных ресурсов".

Да пусть ноют. Какой смысл спорить с людьми, ни устриц не видели, ни Пастернака не читали?

скажем, на 32-битной системе int16_t скорее всего будут с выравниванием по 4 лежать

А можно примеры таких систем? Они ведь очень широко распространены, правда?

[Эдди]

Да пусть ноют. Какой смысл спорить с людьми, ни устриц не видели, ни Пастернака не читали?

Если даже абстрагироваться от этого, то есть элементарная причина не использовать С++: зачем учить лишний ЯП, если С за глаза хватает? Вы бы еще на go каком-нибудь предложили код написать ☺

А можно примеры таких систем? Они ведь очень широко распространены, правда?

Элементарно. У меня была проблема с портированием старого клиент-серверного кода на 64-битную архитектуру с 32-битной: там мало того, что бинарная структура передавалась и в памяти она безо всякого явного выравнивания хранилась, так еще и нестрогие типы данных использовались. Вот во что это в итоге превратилось. Без #pragma pack(push, 4) данные паковались бы с учетом 64-битности (аналогично и со всеми int'ами и т.п. нестрогими типами), в итоге поля структуры совершенно не соответствовали бы описанным позициям.
Благо, обычно little-endian архитектура, а то пришлось бы еще байты туда-сюда распихивать (а ведь бывают процессоры, в которых little-endian отсутствует!).

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

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

[esaulenka]

Если даже абстрагироваться от этого, то есть элементарная причина не использовать С++: зачем учить лишний ЯП, если С за глаза хватает? Вы бы еще на go каком-нибудь предложили код написать ☺

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

Элементарно. У меня была проблема с портированием старого клиент-серверного кода на 64-битную архитектуру с 32-битной:

Это всё прекрасно. Баек "как сделать плохо" я и сам могу рассказать.
Только я задавал совсем другой вопрос.