[jcxz 184]

24 минуты назад, Arlleex сказал:

и вот теперь: беда. Мы договорились, что в протоколе обмена все кадры имеют CRC последним членом.

А почему не первым, раз так удобнее? Просто передоговориться по новой и всё.

[Arlleex 131]

Только что, jcxz сказал:

А почему не первым, раз так удобнее?

Ды кто его теперь знает. Исторически в конец всегда запихивал.

А сейчас понимаю, что с точки зрения языка программирования это очень выходит костыльно.

[jcxz 184]

14 минут назад, Arlleex сказал:

Ды кто его теперь знает. Исторически в конец всегда запихивал.

У меня в разных проектах - по-разному. Где как удобнее. Где-то и в середине есть. 

 

Кстати - почему Вы в своих исходниках применяете такие имена?:

6 часов назад, Arlleex сказал:

#ifndef _UART_HPP_
#define _UART_HPP_

Разве имена, начинающиеся с _ или с __ не зарезервированы для компиляторов (или их встроенных библиотек)?

[x893 35]

19 minutes ago, jcxz said:

Мы договорились, что в протоколе обмена все кадры имеют CRC последним членом.

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

18 minutes ago, jcxz said:

Разве имена, начинающиеся с _ или с __ не зарезервированы для компиляторов (или их встроенных библиотек)?

Ну таких 

_UART_HPP_

компилятор наверняка не использует. Хотя можно напороться на ошибку. Опять же будет возможность создать ноую тему на форуме.

[jcxz 184]

1 минуту назад, x893 сказал:

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

Не нужно мне приписывать чужие слова!

1 минуту назад, x893 сказал:

Ну таких 

_UART_HPP_

компилятор наверняка не использует. Хотя можно напороться на ошибку. Опять же будет возможность создать ноую тему на форуме.

Уверены? Чем подтвердите?

Например из документации IAR:

Цитата

Symbols that are either prefixed by _X, where X is a capital letter, or that contain __ (double underscore) are reserved for toolset vendors.

В других компиляторах тоже видел нечто подобное.

[Arlleex 131]

1 час назад, jcxz сказал:

Разве имена, начинающиеся с _ или с __ не зарезервированы для компиляторов (или их встроенных библиотек)?

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

Но на самом деле сколько своего писал, сколько чужого лопатил - пока что ни разу не удалось нарваться на конфликт дефайнов))

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

[Baser 5]

4 часа назад, Arlleex сказал:

Ды кто его теперь знает. Исторически в конец всегда запихивал.

А сейчас понимаю, что с точки зрения языка программирования это очень выходит костыльно.

Исторически CRC в конце всегда идет не просто так, а потому что при аппаратной реализации протокола, когда CRC считается на сдвиговых регистрах и XOR-ах (в каком-нибудь ASICе или FPGA), так само собой и получается.
Представляю, как ругался бы разработчик ASICа, если ему нужно было бы реализовать такой протокол с CRC в начале пакета: буфер строить, ресурсы тратить.

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

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

5 часов назад, Arlleex сказал:

и вот теперь: беда. Мы договорились, что в протоколе обмена все кадры имеют CRC последним членом. Тут (примера ради) его не было показано. Но этот CRC подразумевался.

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

[Arlleex 131]

9 часов назад, Сергей Борщ сказал:

Обернуть в структуру-шаблон, в котором CRC есть. И уже этот шаблон инстанцировать в union со всеми возможными вариантами кадров.

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

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

[Arlleex 131]

11 часов назад, Baser сказал:

Исторически CRC в конце всегда идет не просто так, а потому что при аппаратной реализации протокола, когда CRC считается на сдвиговых регистрах и XOR-ах (в каком-нибудь ASICе или FPGA), так само собой и получается.

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

[Sergey_Aleksandrovi4 1]

On 5/12/2021 at 10:33 AM, Arlleex said:

Моя цель - сохранить качество/производительность результирующего бинарного кода при синтаксическом упрощении исходников.

@Arlleex По прошествии 3х лет с открытия этой темы, удалось достигнуть желаемого? Состоялся переход с Си на C++?

[EdgeAligned 53]

Ну переход то - "плавный" же! Не резко рвать с места на новом, а помаленьку потихоньку по буковке 😄 
Тут ведь не только переписать всё на class и struct, тут же еще как-то с этим всем теперь управляться надо. Там ведь следующим этапом будут всякие там наследования, виртуальные классы-методы, вся вот эта тягомотина жеж.