[one_eight_seven 3]

12 minutes ago, Arlleex said:

и не представляю, какие будут при всех этих наследованиях от всяких абстракций и т.д.

На начальном этапе работа сильно отличается. Нужно строить архитектуру и абстрагировать объекты. Вы, кстати, уже сами к этому пришли, выделили объект который будет меняться от реализации к реализации. Теперь надо продумать Ъ интерфейс, чтобы можно было бесстыдно полиморфировать. И так - для каждого объекта.

Ну а аппаратные и программные накладные расходы - тема интересная, но у неë есть свойство - о ней говорят абстрактно, в то время как надо просто сделать и посмотреть - приемлемые ли накладные или нет, и чаще окажется, что более чем приемлемые. А если нет, - тогда уже профилировать.

Изменено 12 октября, 2021 пользователем one_eight_seven

[Arlleex 134]

52 минуты назад, one_eight_seven сказал:

На начальном этапе работа сильно отличается. Нужно строить архитектуру и абстрагировать объекты...

Я не совсем понимаю, как это делается правильно, но для себя свое "правильно" сформировал примерно следующим образом. Открываю блокнот и пишу код "сверху-вниз", как будто у меня уже все эти классы реализованы. Т.е. смотрю, какие методы я буду вызывать, как будут создаваться объекты, над какими задачами будет работать тот или иной объект. Шаг за шагом формируется нужный класс.

[one_eight_seven 3]

4 minutes ago, Arlleex said:

Я не совсем понимаю, как это делается правильно

Советую учебник Виноградова "Логика" для средней школы. Это не издëвка, а правда совет. Отношения вида и рода, абстрагирование, определение понятия - как раз описывают как это делается правильно.

Изменено 12 октября, 2021 пользователем one_eight_seven

[Forger 18]

3 minutes ago, Arlleex said:

Но тогда, если так рассуждать, то как "ножовочнику" научиться играть на бензопиле?

Прежде всего изучать инструкцию к ней )))

Если серьезно, то придется поменять мышление. Самое сложное - отучится от сугубо процедурного подхода. Да, на это нужно время и изучение разных готовых решений (чужих). Изучать все за и против.

Попутно взять переписывать по "это дело" небольшой проект, который не особо горит по срокам. Старые дремучие проекты лучше не трогать и тянуть как есть, даже если есть соблазн переписать на ооп )

 

6 minutes ago, Arlleex said:

не модифицируя в них ничего.

Можно, но это не обязательное требование.

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

Самое сложное - их спроектировать, т.е. заложить скелет. А потом "навешивать на скелет мясо" - дорабатывать уже не так болезнненно, ничего в этом страшного нет )) 

 

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

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

таскать .cpp/.hpp-пару из проекта в проект

Я делал так когда-то давно. Но когда в очередной раз найдя очередную ошибку в пректе поймал себя на мысли - "блин, я же ее уже исправлял в том проекте, откуда этот файл был когда-то скопирован", стал весь код, не относящийся к конкретному проекту, структурированно складывать в отдельный репозиторий-библиотеку и уже этот репозиторий подключать ко всем проектам. Да, по мере появления/развития новых проектов иногда приходится дописывать или даже радикально менять уже написанные классы в этом репозитории (с таким расчетом, чтобы не поломать совместимость со старыми проектами или хотя бы чтобы вызвать ошибку компиляции в старых проектах), но зато в любом проекте я могу сделать svn up и получить в нем все исправления и наработки, которые были сделаны в процессе работы над другими проектами. А вот "чтобы не поломать совместимость со старыми проектами" часто и заставляет изучать новые приемы.

[Forger 18]

7 minutes ago, Сергей Борщ said:

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

Прям мои мысли прочитали, коллега! Прям слово-в-слово ))

[haker_fox 60]

1 hour ago, Forger said:

Мало статей читали )  Есть еще готовые решения на гитхабе (по поиску).

Да, мало. Потому что их много, и они на английском. Если не сложно, приведите, пожалуйста, пару-тройку ссылок на хорошие делегаты на гитхабе)

 

[Forger 18]

3 minutes ago, haker_fox said:

Потому что их много, и они на английском.

Не сказал бы ))

В гугле вбивайте "быстрый делегат C++" или "самый быстрый делегат C++".

Ну и английский придется изучать, это как бы без вариантов )

[haker_fox 60]

13 minutes ago, Сергей Борщ said:

структурированно складывать в отдельный репозиторий-библиотеку и уже этот репозиторий подключать ко всем проектам.

У меня точно такой же подход. В виде сабмодуля в системе гит, даже нескольких. Причём подключаю к проектам для встраиваемых систем и к проектам для ПК. Сильно упрощает жизнь в плане правки ошибок, иногда чуть-чуть усложняя её, когда обновляешь в конкретном проекте самодуль, т.к. приходится править нестыковки.

2 minutes ago, Forger said:

В гугле вбивайте "быстрый делегат C++" или "самый быстрый делегат C++".

Я уже искал по этим словам, т.к. Вы не в первый раз говорите про делегаты на форуме. И я находил топики, где Вы рекомендовали это словосочетание)

Я же попросил пару ссылок на гитхаб с хорошими на Ваш взгляд делегатыми, пригодными во страиваемых системах)

[Forger 18]

11 minutes ago, haker_fox said:

Я же попросил пару ссылок на гитхаб с хорошими на Ваш взгляд делегатыми, пригодными во страиваемых системах)

Мне только один зашел, на базе него сделал свое решение, упростив или вырезав "лишнее" на мой взгляд. Исправил под себя naming.

Статья по нему

 

Ссылка на архив с исходниками в статье.

[rkit 3]

33 minutes ago, Forger said:

Минус std один - по делу и без дела увлекается дин. памятью ((

Всё, что касается памяти в std - четко документировано и часто управляется.

[jcxz 194]

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

И все это в одном флаконе, да чтоб еще без накладных расходов (либо чтобы их наличие вызывало лишь смех).

Это невозможно. Вы сами доказали это своим примером установки скорости CAN через callback.

[Forger 18]

9 minutes ago, rkit said:

четко документировано и часто управляется.

Ага, управляется, только если переназначить штатный malloc/free на другой, более "управляемый", вплоть до самописного ))

Ничего против std не имею, но в embedded применяю с особой осторожностью, да и не так часто оно требуется.

 

[jcxz 194]

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

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

Так и будет. Если этого ещё нет, то простой вывод - видимо это невозможно.

И далее - каждый выбирает для себя что ему важнее: "шашечки или ехать".

[Arlleex 134]

И тем не менее, абстрагируйся сколько хочешь, хоть штаны через голову надевай, хоть делегаты на делегаты используй, а в конечном счете где-то должна будет вызвана простая пользовательская функция, в моем случае которая устанавливает скорость периферийного узла CAN в МК. Мне было интересно узнать, как это сделать в плюсах, чтобы не поломать ни идеологию ООП, ни пуре-Си-шное преимущество генерировать оптимальный быстрый код.