Обратиться к "длинным типам", как к массиву байт (в C)

[Dmitriy40]

realeugene в сообщении #1360521 писал(а):

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

Да, типизированные inline функции приятны и полезны, вот только компиляторы не под все архитектуры достаточно умны чтобы ими правильно пользоваться! Пример, недавно боролся (так и не победил): в высокоскоростном прерывании если не вызывать функции, то сохраняются только реально используемые регистры, если же вызвать хоть одну любую функцию, даже практически пустую и inline - при входе в прерывание сохраняются все регистры, которые могут измениться функцией хотя бы в принципе (по соглашению об использовании регистров), даже если конкретно эта функция их и не изменяет. А это часто намного больше и дольше! Так что иногда #define выгоднее функции. Программы на C/C++ не ограничиваются компьютерами, где компиляторы действительно довольно хороши.

[FomaNeverov]

realeugene в сообщении #1360529 писал(а):

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

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

    float xf = 0.2;
    uchar *xb = (uchar *) &xf;
    uchar abc[sizeof(xb)];

    for(int i = 0; i < sizeof(xb); i++)
    {
        abc[i] = xb[i];
    }

[realeugene]

Dmitriy40 в сообщении #1360527 писал(а):

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

И я повторю: void* - это стандартный тип указателя для нетипизированных буферов. Посмотрите, например, на прототип библиотечной функции memcpy. И правильно, что вам надоедает писать везде sizeof, когда у вас одинаковых вызовов много. Напишите набор функций-обёрток для своих типов, но не макросы. И никогда, подчеркну, никогда не кодируйте размер переменной явной константой, если вы, конечно, не любитель искать себе приключений.

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

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

-- 11.12.2018, 20:59 --

FomaNeverov в сообщении #1360534 писал(а):

Этот код может не работать?

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

[FomaNeverov]

EUgeneUS в сообщении #1360470 писал(а):

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

Ну а вопрос, как из 4-х байт сделать float - будет?

[EUgeneUS]

FomaNeverov в сообщении #1360534 писал(а):

Это то, о чём спрашивал автор темы?

Код, который Вы привели в первом своем сообщении в этой теме, конечно, не "// т.е. помещает байты флоата в массив".
Но это то, что было нужно ТС.
Вот только про этот фокус с указателем было сказано в пером же ответе.

FomaNeverov в сообщении #1360541 писал(а):

Ну а вопрос, как из 4-х байт сделать float - будет?

А зачем? К моменту Вашего сообщения у меня уже все разбиралось, сохранялось, читалось и собиралось обратно.
Но всё равно, спасибо!