[jenya7 0]

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

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 7]

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

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 лежать

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

[jenya7 0]

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

 

ну я еще в планирую добавить в buf timestamp и название переменной. но главное - функции Flash_Log(log_addr, buf); UART_SendString(UART2, buf);принимают массив чаров. что вполне естественно.

[Eddy_Em 1]

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

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

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

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

Благо, обычно little-endian архитектура, а то пришлось бы еще байты туда-сюда распихивать (а ведь бывают процессоры, в которых little-endian отсутствует!).

 

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

 

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

[jenya7 0]

кстати а как мне вычислить размер void *data? sizeof тут не прокатит.

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

кстати а как мне вычислить размер void *data? sizeof тут не прокатит.

Почему не прокатит? Он вам честно выдаст размер указателя. Или я не понял, что именно вы хотели получить? Тогда компилятор вас тем более не поймет.

 

 

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

Мы рады за вас, но вы ответили не на тот вопрос, который вам задали.

 

[jenya7 0]

Почему не прокатит? Он вам честно выдаст размер указателя. Или я не понял, что именно вы хотели получить? Тогда компилятор вас тем более не поймет.

 

 

Мы рады за вас, но вы ответили не на тот вопрос, который вам задали.

а если это указатель на структуру? мне же нужен размер структуры.

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

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

Чтобы упростить себе работу по написанию новых программ. Да, все то же самое можно написать и на голом Си, но после освоения плюсов писание на голых Сях напоминает закат Солнца вручную.

 

 

а если это указатель на структуру? мне же нужен размер структуры.

Простите, но ни я, ни компилятор навыками телепатии не обладаем. Про что вы спросили - про то вам и ответили. Более того, приведя (пусть и неявно) укзатель на структру к указателю на void, вы намеренно отобрали у компилятора знание о размере этой самой структуры.

 

[Eddy_Em 1]

Мы рады за вас, но вы ответили не на тот вопрос, который вам задали.

32-битных машин еще пруд пруди! И не загорами 128-битные. Вот тогда уж вообще веселуха начнется...

А еще есть микроконтроллеры, где архитектура бывает еще и 8- и 16-битной.

И если бинарный файл писать на 16-битном МК, а потом попытаться без должных усердий прочесть на 64-битной машине, получится черт-те что.

Если же у пользователя компьютер на MIPS, то еще больше веселуха получится! Жаль, что мипсы закопали, очень впечатляющая архитектура и вполне имела бы жизнь... Но нет — дурацкие армы стали продвигать.

 

кстати а как мне вычислить размер void *data? sizeof тут не прокатит.

Как я уже неоднократно говорил, сделать структуру

#pragma pack ...
typedef struct{
    size_t reclen;  // длина одной записи
    size_t recN;    // количество записей
    size_t align;    // выравнивание по...
    void *data;     // сами данные
} adata;
#pragma pack ...

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

[jenya7 0]

Чтобы упростить себе работу по написанию новых программ. Да, все то же самое можно написать и на голом Си, но после освоения плюсов писание на голых Сях напоминает закат Солнца вручную.

 

 

Простите, но ни я, ни компилятор навыками телепатии не обладаем. Про что вы спросили - про то вам и ответили. Более того, приведя (пусть и неявно) укзатель на структру к указателю на void, вы намеренно отобрали у компилятора знание о размере этой самой структуры.

так я почему передаю void *data. я хочу чтоб функция была генерик. чтоб работала с любыми данными. наверное единственное решение то что предлагает Эдди. на этапе конфигурации определять размер.

[Eddy_Em 1]

на этапе конфигурации определять размер.

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

[esaulenka 7]

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

Можно абстрагироваться и ничего не делать вообще совсем, только языком чесать.

(по большому секрету: BTA_lib можно и нужно писать на плюсах. Там даже подвижки к объектной модели есть).

 

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

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

Только я задавал совсем другой вопрос.

[jenya7 0]

сделал такую структуру.

typedef struct LOG_PARAMS_S
{
    uint32_t ena;  //0-disable, 1-enable
    uint32_t timestamp;  //0-none, 1-time, 2-date+time
    uint32_t storage;  //sd, flash, uart
    uint32_t data_size;
    char header[32];
    void *data;  
}LOG_PARAMS;

extern LOG_PARAMS logParams[10];

а так я планирую конфигурировать логер.

void COM_Log(uint32_t argc, char** args)
{
    //log idx ena storage timestamp header data
    uint32_t idx = atoi(args[1]);
    uint32_t enable = atoi(args[2]);
    uint32_t log_storage = atoi(args[3]);
    uint32_t time_stamp = atoi(args[4]); 
    uint32_t size;
    uint32_t var_type;
      
    if (idx >= MAX_LOGS)
    {
        Parser_SendString(USART2,msg_invinp,print_out);
        return;
    }

    logParams[idx].ena = enable;
    logParams[idx].storage = log_storage;
    logParams[idx].timestamp = time_stamp;
    
    if(strlen(args[5]) > 32)
       size = 32;
    else
      size =  strlen(args[5]);
    
    memcpy (logParams[idx].header, args[5], size);
    
    void *var = SetVariable(args[6], &var_type);
    
    logParams[idx].data = (uint32_t *)var;  //pointer to data
}

Изменено 17 января, 2017 пользователем Jenya7

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

32-битных машин еще пруд пруди! И не загорами 128-битные.

Замечательно. А теперь еще раз перечитайте исходный вопрос постарайтесь ответить на него:

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

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

 

 

 

[Eddy_Em 1]

BTA_lib можно и нужно писать на плюсах

У меня мозг императивный, он ООПщину не воспринимает никак.

Только я задавал совсем другой вопрос.

Выше я на него ответил. Очень много железа распространено с не то, что не 64-битной архитектурой (таких, пожалуй, до сих пор большинство), но даже не с little-endian (тех, правда, мало).