AHTOXA 18 25 октября, 2016 Опубликовано 25 октября, 2016 · Жалоба typedef struct { uint16_t value; } __attribute__((packed)) unaligned_uint16; ((unaligned_uint16*)bla_bla).value = ...; В вашем решении много битовых операций на ровном месте. Да ладно вам стращать:) Современные компиляторы отлично оптимизируют конструкции вида *(tmpbuf + 2) = totallen & 0xFF; *(tmpbuf + 3) = totallen >> 8; Думаю, что код, сгенерированный компилятором в вашем варианте и в этом будет эквивалентен. Зато этот вариант понятнее, к тому же он переносим. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Сергей Борщ 141 25 октября, 2016 Опубликовано 25 октября, 2016 · Жалоба memcpy при оптимизациях Os\O3 меня уже пару раз подводила.Интересно. Когда подведет еще раз - выложите сюда, вероятнее всего вы просто не умеете ее готовить. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Kabdim 0 25 октября, 2016 Опубликовано 25 октября, 2016 · Жалоба Да ладно вам стращать:) Современные компиляторы отлично оптимизируют конструкции вида Поинт был не в том. :) Согласен что эффективность будет одинаковая. Но читать код как у ТСа мне хуже чем другие варианты. Я его просто буду раз десять перечитывать что бы точно убедится что не меняется порядок байт, в др. вариантах назначение кода сразу очевидно. Во-вторых в варианте ТСа куча чисел. В спокойной обстановке всё конечно ясно, но порой код редактирует, к примеру, коллега автора и находится он не в лучшем состоянии ума и тогда возможны любые чудеса - уже испытывал это. Зато этот вариант понятнее, к тому же он переносим. Для упрощения примера я вставил сразу gcc'шный вариант, но в боевом это макросы в зависимости от платформы. Так что упакованная структура так же переносима. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
johnshadow 1 25 октября, 2016 Опубликовано 25 октября, 2016 · Жалоба Интересно. Когда подведет еще раз - выложите сюда, вероятнее всего вы просто не умеете ее готовить. Возможно. Мне тяжело сейчас предоставить "живой" пример - дело было два-три года назад. Помню, что ошибка проявлялась при совместном использовании оптимизации по размеру и LinkTimeOptimization (Os и flto). Проект был по CooCox и они только добавили опцию LTO у себя в настройках компиляции. Обошел ее используя не библиотечную реализацию: __attribute__((used)) void * memcpy(void * d1, const void * s1, size_t n) { char * d; const char * s; volatile size_t n1 = n; s = s1; d = d1; while (n1--) *d++ = *s++; return d1; } "помогало" именно создание volatile'ной переменной и дальнейшая работа с ней. в противном случае (при использовании аргументной переменной n) бесконечно висел в while - уменьшение переменной не происходило. причем висело не в моем коде, а внутри функций freertos (тогда то ли 6, то ли 7 версии). понимаю, что это все выглядит как рассказ про йети, но... :laughing: Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Kabdim 0 25 октября, 2016 Опубликовано 25 октября, 2016 · Жалоба Удалил, попутал со знаковым переполнением. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться