[jcxz 206]

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

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

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

[Arlleex 153]

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

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

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

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

[jcxz 206]

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

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

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

 

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

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

#ifndef _UART_HPP_
#define _UART_HPP_

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

[x893 45]

19 minutes ago, jcxz said:

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

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

18 minutes ago, jcxz said:

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

Ну таких 

_UART_HPP_

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

[jcxz 206]

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

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

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

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

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

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

[Baser 5]

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

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

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

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

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

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

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

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

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

[Arlleex 153]

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

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

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

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

[Arlleex 153]

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

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

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

[Sergey_Aleksandrovi4 1]

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

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

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

[EdgeAligned 71]

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

[Arlleex 153]

В 22.04.2024 в 18:27, Sergey_Aleksandrovi4 сказал:

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

Был (есть) в отпуске, но, пожалуй, скажу пару слов.

Надежды, возлагаемые на C++ в части облегчения исходников, улучшения их сопровождения и в целом удобства разработки ПО - не оправдались. Этак, процентов на 90. Но это не значит, что я не буду писать на нем.

Когда переходил с Си, основная болезненная для меня тема, а именно - сокрытие данных и более строгая изолированность модулей за счет применения классов и пространств имен - покрыта возможностями C++ на 100%. Наверное, это единственное, чего мне так сильно не хватало в Си. Будь в Си хотя бы пространства имен, как в плюсах, я, наверное, вряд ли бы переходил.

Во всем остальном C++ весьма переусложнен и витиеват, особенно для ембеддед. Тучный и порою нечитаемый синтаксис, в котором приходится ковыряться, напрягая мозг и отвлекаясь от основной цели. Десять и больше способов сделать ровно одно и то же (например, инициализация объектов или переменных). Туманные перспективы писать действительно переносимый код - "фишки" последних редакций стандартов выглядят такими, что создается впечатление о их выпиливании уже в следующей редакции. Говнокод и нормальный код выглядят примерно одинаково - но это следствие первых двух факторов. Излишняя универсальность, при этом эта универсальность практически всегда смотрит "не туда" - C++ заставляет думать в неких заранее определенных категориях, поэтому шаг влево и идеальная структура твоего кода рушится. Стандартная библиотека, которая всегда хорошо выглядит лишь на учебных и удобных примерах, или в качестве вполне рабочих примеров-псевдокодов для объяснения на разных форумах - а в реальных проектах (и тем более для эмбеддед) многое из стандартной библиотеки реализуется по-своему. Очень странное желание комитета (вернее, той группы энтузиастов, что пилят очередную версию стандарта) объединить все области в одном месте - и принципы ООП, и какие-то уже вполне конкретные алгоритмы, и даже механизмы обеспечения многозадачности - стандартная библиотека уже давно обрастает трэд-сэфити конструкциями, которые упрощают (наверное) порог входа в многопоточное кодирование, но на мой взгляд такой подход потом заставит родить еще 100500 методов отлова ошибок юзеров, которые окончательно запутаются в назначении всех этих премудростей и начнут жоско говнокодить, лишь бы работало как-нибудь. Чего дальше ожидать? Собственные стеки протоколов? Судя по развитию языка - ожидать.

Пишу ли я на C++? Ну, как сказать. Весь нижний уровень драйверов я пишу в стиле Си - заимствую по ситуации из плюсов вкусовщину - крайне стабильные в поведении вещи - нэймспейсы, классы, несложные шаблоны и перегрузки. Саму логику работы могу описывать в ООП-стиле, а могу не описывать. Честно говоря, какими бы сложными не были мои девайсы, применение абстракций и ООП-парадигмы в финальном варианте выглядит как "применил ООП ради ООП", а не ради упрощения читаемости и понимаемости кода. Лучше делать упор на "базу" - писать потокобезопасно, без гонок, без сомнительной универсальности, которая с вероятностью 99% не выстрелит, с адекватным пользованием ресурсов, с предположением, что тебе же этот код и сопровождать потом и главное - с твердым пониманием происходящего. А то, что я не пользуюсь огромным количеством встроенных в C++ премудростей - да и фиг с ними. Этих премудростей привносят в очередной редакции стандарта как г*на на лопате - и вуаля - твой код теперь пахнет дурно, потому что, видите ли, новый стандрат добавил в стандартную библиотеку то-то сё-то, а в твоем коде это "то-то" было впилено собственноручно.

[tonyk_av 36]

3 hours ago, Arlleex said:

сокрытие данных и более строгая изолированность модулей за счет применения классов и пространств имен - покрыта возможностями C++ на 100%. Наверное, это единственное, чего мне так сильно не хватало в Си.

А как же наследование? Как без него?

3 hours ago, Arlleex said:

Во всем остальном C++ весьма переусложнен и витиеват, особенно для ембеддед.

А ты просто не используй эти переусложнённые шняги. Я при использовании С++ долго жил под угрозой переноса кода с ARM на МК с архитектурой х186, посему ориентировался на возможности Borland C++ 5.02. Это раз. А два проявилось при попытке использовать стандартную библиотеку. Кое-что можно использовать, но нужно хорошо понимать что и как в ней устроено, иначе добавление в программу двух строк приводит к увеличению потребляемого ОЗУ и ПЗУ на десятки килобайт.

3 hours ago, Arlleex said:

Излишняя универсальность

Вот-вот, только на неё не нужно ругаться. По-моему, она для того и сделана, чтобы каждый мог выбрать и использовать то, что нужно именно ему для его задач. И не нужно переживать, что остальное тебе не пригодилось.

Изменено 8 мая пользователем tonyk_av

[EdgeAligned 71]

Ну, что есть то есть 🙂  Беда в том, что язык существует уже очень давно, но его "детские болячки" не лечились, а просто обляпывались заплатками, которые тоже были сырыми, и поверх них приляпывалась еще одна заплатка. Вместо усовершенствования ядра языка вводили новые проставки-описалова в угоду обратной совместимости. И куча вариантов инициализации объектов возникли как раз поэтому. Причем, в одних случаях применяется один способ, в других случаях - другой способ, в третьих - третий. А еще особняком стоит инициализация статических полей класса, она вообще вне класса. И подобная фигня - на каждом шагу. Вариативные шаблоны - ваще ахтунг какой-то, сделали просто ради того, чтобы они были, но инструментарий реализован криво-косо и ваще через опу - им не жевозможно по-человечьи пользоваться! Частичные специализации шаблонов - тоже засада какая то.  

В остальном - ну, как бы вот база, придуманная еще в прошлом веке, она есть, хотя она и явилась просто развитием того, что было в Си. 
С другой стороны, вот эта база, она позволяет сделать некоторые интересные вещи, которые на Си занимали бы больше места. В частности, интерес представляют механизмы наследования, в том числе и виртуальные методы. Так же интересной плюшкой является перегрузка операторов. По сути, она аналогична функциям в языке Си, но вместо текстового имени используется значок операции. Например, сравнение двух объектов класса координат: когда в этом классе реализаована перегрузка операторов сравнения ==, != . То есть, вместо (p1.x == p2.x) && (p1.y == p2.y) пишется просто p1 == p2. 

Нижний уровень тоже можно записать в С++ стиле, главное, понять, как это делать. 
У меня как-то была задача - подключить аж три одинаковых дисплея по SPI. На Си пришлось бы делать разные функции управления разными дисплеями, либо передавать в функции указатели на конкретные ресурсы. А на ++ благодаря шабломан получилось реализовать обобщенный класс дисплея и передать в него через параметры шаблона классы разных SPI и пинов, на которых сидели дисплеи. 
template<typename SPI, typename DC, typename CS> class ST75256 ...., а внутри методов класса - DC::Low(), SPI::Write(xxx) и тд. При этом компилятор сгенерирует три отдельных набора функций, но обобщенное описание пишется один раз. Ну интересно же ведь, правда? 

А вот еще что. Еще одна проблема, оставшаяся еще со времён Си - динамическое распределение памяти. Правда, я еще не разбирался, какие заплатки нашлепали в последних редакциях ++, но существует проблема фрагментации памяти, когад при выделении нового блока рискуешь получить неожиданный отказ. Стандартный аллокатор после освобождения по delete не подчищает за собой мусор, память остается фрагментированной. Опасность фрагментации в том, что при наличии свободного места в памяти, новый блок с размером, не помещающимся в эти фрагменты, будет выделяться в новом месте, а оно, это место, может вообще закончиться, память ведь не резиновая. 
И вот не знаю, какие заплатки придумают (или уже придумали) на этот печальный факт. В более продвинутых языках есть "сборщики мусора". А в ++ похоже еще не дошли до этого.

Изменено 8 мая пользователем EdgeAligned