jcxz 234 18 апреля Опубликовано 18 апреля · Жалоба 24 минуты назад, Arlleex сказал: и вот теперь: беда. Мы договорились, что в протоколе обмена все кадры имеют CRC последним членом. А почему не первым, раз так удобнее? Просто передоговориться по новой и всё. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Arlleex 178 18 апреля Опубликовано 18 апреля · Жалоба Только что, jcxz сказал: А почему не первым, раз так удобнее? Ды кто его теперь знает. Исторически в конец всегда запихивал. А сейчас понимаю, что с точки зрения языка программирования это очень выходит костыльно. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 234 18 апреля Опубликовано 18 апреля · Жалоба 14 минут назад, Arlleex сказал: Ды кто его теперь знает. Исторически в конец всегда запихивал. У меня в разных проектах - по-разному. Где как удобнее. Где-то и в середине есть. Кстати - почему Вы в своих исходниках применяете такие имена?: 6 часов назад, Arlleex сказал: #ifndef _UART_HPP_ #define _UART_HPP_ Разве имена, начинающиеся с _ или с __ не зарезервированы для компиляторов (или их встроенных библиотек)? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
x893 55 18 апреля Опубликовано 18 апреля · Жалоба 19 minutes ago, jcxz said: Мы договорились, что в протоколе обмена все кадры имеют CRC последним членом. Члены можно и переставить, если сразу не продумали. 18 minutes ago, jcxz said: Разве имена, начинающиеся с _ или с __ не зарезервированы для компиляторов (или их встроенных библиотек)? Ну таких _UART_HPP_ компилятор наверняка не использует. Хотя можно напороться на ошибку. Опять же будет возможность создать ноую тему на форуме. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 234 18 апреля Опубликовано 18 апреля · Жалоба 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 178 18 апреля Опубликовано 18 апреля · Жалоба 1 час назад, jcxz сказал: Разве имена, начинающиеся с _ или с __ не зарезервированы для компиляторов (или их встроенных библиотек)? Вы правы, косяк в этом есть. До какого-то момента писал так - вот и попал кусок сюда в том виде в каком есть. Но на самом деле сколько своего писал, сколько чужого лопатил - пока что ни разу не удалось нарваться на конфликт дефайнов)) Возможно, потому, что в моих исходниках мало подключений сторонних библиотек. А те, что подключаются, не пересекаются названиями. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Baser 5 18 апреля Опубликовано 18 апреля · Жалоба 4 часа назад, Arlleex сказал: Ды кто его теперь знает. Исторически в конец всегда запихивал. А сейчас понимаю, что с точки зрения языка программирования это очень выходит костыльно. Исторически CRC в конце всегда идет не просто так, а потому что при аппаратной реализации протокола, когда CRC считается на сдвиговых регистрах и XOR-ах (в каком-нибудь ASICе или FPGA), так само собой и получается. Представляю, как ругался бы разработчик ASICа, если ему нужно было бы реализовать такой протокол с CRC в начале пакета: буфер строить, ресурсы тратить. Так что с точки зрения вашего построения мироустройства это неудобно, а с другой точки - по другому и быть не может 1 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Сергей Борщ 134 18 апреля Опубликовано 18 апреля · Жалоба 5 часов назад, Arlleex сказал: и вот теперь: беда. Мы договорились, что в протоколе обмена все кадры имеют CRC последним членом. Тут (примера ради) его не было показано. Но этот CRC подразумевался. Обернуть в структуру-шаблон, в котором CRC есть. И уже этот шаблон инстанцировать в union со всеми возможными вариантами кадров. Или этот SendMessage засунуть в структуру, а после него разместить резервирование места под CRC. Все равно вы CRC считаете пробегаясь указателем по сырым байтам. В конце этот указатель указывает в нужное место, куда класть CRC. А в структуре он нужен только для наглядности и резервирования места, все равно вы явно с этим полем никогда не работаете - так и отразить это в комментарии к полю структуры. Ничего более другого в голову не приходит. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Arlleex 178 19 апреля Опубликовано 19 апреля · Жалоба 9 часов назад, Сергей Борщ сказал: Обернуть в структуру-шаблон, в котором CRC есть. И уже этот шаблон инстанцировать в union со всеми возможными вариантами кадров. Можете наглядно показать, что Вы имели в виду? Ибо я читаю это как попытаться запихнуть структуру с FAM в другую структуру, и дописать за ней CRC. Но любые попытки сделать так тщетны, т.к. нельзя использовать FAM-структуры как член другой структуры. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Arlleex 178 19 апреля Опубликовано 19 апреля · Жалоба 11 часов назад, Baser сказал: Исторически CRC в конце всегда идет не просто так, а потому что при аппаратной реализации протокола, когда CRC считается на сдвиговых регистрах и XOR-ах (в каком-нибудь ASICе или FPGA), так само собой и получается. Нет, с точки зрения аппаратной реализации мне как раз понятно все. Я говорил об историческом наследии именно в программном обеспечении, реализующим всякие ширпотребные протоколы. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Sergey_Aleksandrovi4 2 22 апреля Опубликовано 22 апреля · Жалоба On 5/12/2021 at 10:33 AM, Arlleex said: Моя цель - сохранить качество/производительность результирующего бинарного кода при синтаксическом упрощении исходников. @Arlleex По прошествии 3х лет с открытия этой темы, удалось достигнуть желаемого? Состоялся переход с Си на C++? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
EdgeAligned 83 23 апреля Опубликовано 23 апреля · Жалоба Ну переход то - "плавный" же! Не резко рвать с места на новом, а помаленьку потихоньку по буковке 😄 Тут ведь не только переписать всё на class и struct, тут же еще как-то с этим всем теперь управляться надо. Там ведь следующим этапом будут всякие там наследования, виртуальные классы-методы, вся вот эта тягомотина жеж. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Arlleex 178 8 мая Опубликовано 8 мая · Жалоба В 22.04.2024 в 18:27, Sergey_Aleksandrovi4 сказал: @Arlleex По прошествии 3х лет с открытия этой темы, удалось достигнуть желаемого? Состоялся переход с Си на C++? Был (есть) в отпуске, но, пожалуй, скажу пару слов. Надежды, возлагаемые на C++ в части облегчения исходников, улучшения их сопровождения и в целом удобства разработки ПО - не оправдались. Этак, процентов на 90. Но это не значит, что я не буду писать на нем. Когда переходил с Си, основная болезненная для меня тема, а именно - сокрытие данных и более строгая изолированность модулей за счет применения классов и пространств имен - покрыта возможностями C++ на 100%. Наверное, это единственное, чего мне так сильно не хватало в Си. Будь в Си хотя бы пространства имен, как в плюсах, я, наверное, вряд ли бы переходил. Во всем остальном C++ весьма переусложнен и витиеват, особенно для ембеддед. Тучный и порою нечитаемый синтаксис, в котором приходится ковыряться, напрягая мозг и отвлекаясь от основной цели. Десять и больше способов сделать ровно одно и то же (например, инициализация объектов или переменных). Туманные перспективы писать действительно переносимый код - "фишки" последних редакций стандартов выглядят такими, что создается впечатление о их выпиливании уже в следующей редакции. Говнокод и нормальный код выглядят примерно одинаково - но это следствие первых двух факторов. Излишняя универсальность, при этом эта универсальность практически всегда смотрит "не туда" - C++ заставляет думать в неких заранее определенных категориях, поэтому шаг влево и идеальная структура твоего кода рушится. Стандартная библиотека, которая всегда хорошо выглядит лишь на учебных и удобных примерах, или в качестве вполне рабочих примеров-псевдокодов для объяснения на разных форумах - а в реальных проектах (и тем более для эмбеддед) многое из стандартной библиотеки реализуется по-своему. Очень странное желание комитета (вернее, той группы энтузиастов, что пилят очередную версию стандарта) объединить все области в одном месте - и принципы ООП, и какие-то уже вполне конкретные алгоритмы, и даже механизмы обеспечения многозадачности - стандартная библиотека уже давно обрастает трэд-сэфити конструкциями, которые упрощают (наверное) порог входа в многопоточное кодирование, но на мой взгляд такой подход потом заставит родить еще 100500 методов отлова ошибок юзеров, которые окончательно запутаются в назначении всех этих премудростей и начнут жоско говнокодить, лишь бы работало как-нибудь. Чего дальше ожидать? Собственные стеки протоколов? Судя по развитию языка - ожидать. Пишу ли я на C++? Ну, как сказать. Весь нижний уровень драйверов я пишу в стиле Си - заимствую по ситуации из плюсов вкусовщину - крайне стабильные в поведении вещи - нэймспейсы, классы, несложные шаблоны и перегрузки. Саму логику работы могу описывать в ООП-стиле, а могу не описывать. Честно говоря, какими бы сложными не были мои девайсы, применение абстракций и ООП-парадигмы в финальном варианте выглядит как "применил ООП ради ООП", а не ради упрощения читаемости и понимаемости кода. Лучше делать упор на "базу" - писать потокобезопасно, без гонок, без сомнительной универсальности, которая с вероятностью 99% не выстрелит, с адекватным пользованием ресурсов, с предположением, что тебе же этот код и сопровождать потом и главное - с твердым пониманием происходящего. А то, что я не пользуюсь огромным количеством встроенных в C++ премудростей - да и фиг с ними. Этих премудростей привносят в очередной редакции стандарта как г*на на лопате - и вуаля - твой код теперь пахнет дурно, потому что, видите ли, новый стандрат добавил в стандартную библиотеку то-то сё-то, а в твоем коде это "то-то" было впилено собственноручно. 1 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
tonyk_av 44 8 мая Опубликовано 8 мая (изменено) · Жалоба 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 83 8 мая Опубликовано 8 мая (изменено) · Жалоба Ну, что есть то есть 🙂 Беда в том, что язык существует уже очень давно, но его "детские болячки" не лечились, а просто обляпывались заплатками, которые тоже были сырыми, и поверх них приляпывалась еще одна заплатка. Вместо усовершенствования ядра языка вводили новые проставки-описалова в угоду обратной совместимости. И куча вариантов инициализации объектов возникли как раз поэтому. Причем, в одних случаях применяется один способ, в других случаях - другой способ, в третьих - третий. А еще особняком стоит инициализация статических полей класса, она вообще вне класса. И подобная фигня - на каждом шагу. Вариативные шаблоны - ваще ахтунг какой-то, сделали просто ради того, чтобы они были, но инструментарий реализован криво-косо и ваще через опу - им не жевозможно по-человечьи пользоваться! Частичные специализации шаблонов - тоже засада какая то. В остальном - ну, как бы вот база, придуманная еще в прошлом веке, она есть, хотя она и явилась просто развитием того, что было в Си. С другой стороны, вот эта база, она позволяет сделать некоторые интересные вещи, которые на Си занимали бы больше места. В частности, интерес представляют механизмы наследования, в том числе и виртуальные методы. Так же интересной плюшкой является перегрузка операторов. По сути, она аналогична функциям в языке Си, но вместо текстового имени используется значок операции. Например, сравнение двух объектов класса координат: когда в этом классе реализаована перегрузка операторов сравнения ==, != . То есть, вместо (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 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться