Переделка проекта, Скорее риторический Опции

[SasaVitebsk]

Раньше на ASM работал. Два года назад перешёл на Си. Жутко жалею потерянного времени.
Анализируя причины почему раньше не переходил, пришёл к выводу что их две. Первая - костность. (Банальная лень осваивать новый пакет). Вторая - уверенность в том, что компилятор генерит код значительно хуже чем пишет человек. Причём эта уверенность у меня была непоколебимая. Я даже исследования не проводил и никого не расспрашивал. Я просто был уверен, что хороший компилятор создать нельзя. Эта уверенность у меня сохранилась даже на момент перехода на Си. Причина перехода на Си банальна. Я задолбался переносить те несколько проектов которые сопровождал и развивал на другие камни. Поэтому выбирал мультипроцессорный Си. Выбрал IAR. Был просто шокирован качеством герерируемого им кода. Если бы мне про это рассказали - не поверил бы. Теперь привык. Прошло два года. Сделал 4 маленьких проекта и один крупный (для меня). Крупный начинал с самого начала освоения Си. То есть прямо на нём учился писать. Теперь немного переосмысливаю свои подходы и свои заблуждения.

Очень заставила задуматься недавняя ветка со спором С vs C++. И особенно сильное впечатление произвела история zltigo об опыте написания оконного интерфейса на С++. В смысле уменьшения объёма результирующего кода. То есть до этого я рассматривал только аспект удобства/ прозрачностности/ целостности. То есть рассматривал только проектирование. Задумался над этим. Особенно в свете того, что я несколько ранее считал неоспоримым кодогенерацию в Си. Вижу действительно при использовании общих свойств и методов и при широком использовании наследования, действительно можно получить выигрыш. С учётом того, конечно, что в ручную, без серьёзного продумывания будет сложно так написать. А в С++ это получается как бы само собой. Точнее тебя заставляют таким образом строить программу.

Перечитал ещё раз, примеряя всё это на себя. в принципе всё это уже знаю, но как то не было желания на себя примерять. Можно и в С++ писать простым и понятным, а главное привычным процедурным языком.


Дело в том, что этот мой большой проект, похоже прекрасно ложился на C++.
Кратко - так. Само устр-во исполняет команды (структуры). Команды поступают извне. Сам транспортный уровень развязан. То есть самому устр-ву до лампочки каким образом они поступают. RS485/I2C-EEPROM/MMC. Возможно будут и другие виды интерфейсов. Во всяком случае планирую какой-нибудь радио-интерфейс, возможно ethernet. Поступают они как из файла - последовательность байтов с байтстафингом. По метке начала команды - определяется команда. Команды имеют разные поля(параметры) и разную длину. В начале команды идут поля идентичные во всех командах. Для этого я имею мифическую несуществующую структуру и сначала прикладываю её. По ней узнаю имя команды её длину (соответственно) и некоторые другие общие поля. После этого, я уже накладываю реальную структуру и работаю с реальными полями структуры. Разные команды имеют общие поля. Но разный их набор. Ну и так далее. Короче сейчас мне очевидно, что вся эта прога неплохо бы легла на объекты и С++ соответственно.

Честно говоря - всё вылизано и прекрасно работает. Возвращаться к этому не очень хочется. Но проект развивается и будет развиваться впредь. Будет переносится на другие камни и будет другие возможности иметь.


И вот теперь вопрос. Понимаю конечно, что за меня никто это решение не примет. Поэтому вопрос скорее риторический, но всё же. Стоит ли перетаскивать/перелопачивать проект? Кто как делал?

Может кто какую историю раскажет или своё мнение выскажет. Или поделится соображениями на этот счёт.

Скажу так. Вылизывал я детали и тонкости месяца четыре не меньше. Команды, да ещё параметры. То границы кое-где, то ещё что. То быстродействие отрабатывал. Но есть мне момент, который не очень нравится. А именно процесс выделения/освобождения памяти. Работа с кучей короче. Я её в камне упростил, а контроль делаю в компе. И то такой - совещательный.

[dxp]

Кратко - так. Само устр-во исполняет команды (структуры). Команды поступают извне. Сам транспортный уровень развязан. То есть самому устр-ву до лампочки каким образом они поступают. RS485/I2C-EEPROM/MMC. Возможно будут и другие виды интерфейсов. Во всяком случае планирую какой-нибудь радио-интерфейс, возможно ethernet. Поступают они как из файла - последовательность байтов с байтстафингом. По метке начала команды - определяется команда. Команды имеют разные поля(параметры) и разную длину. В начале команды идут поля идентичные во всех командах. Для этого я имею мифическую несуществующую структуру и сначала прикладываю её. По ней узнаю имя команды её длину (соответственно) и некоторые другие общие поля. После этого, я уже накладываю реальную структуру и работаю с реальными полями структуры. Разные команды имеют общие поля. Но разный их набор. Ну и так далее. Короче сейчас мне очевидно, что вся эта прога неплохо бы легла на объекты и С++ соответственно.

Похоже, что тут сильно пахнет уже именно ООП. Т.е. иерархией классов с виртуальными функциями и полиморфизмом. Вот эта мифическая несуществующая структура - это абстрактный базовый класс, в котором объявлены чистые виртуальные функции (pure virtual), от него уже строится иерархия классов-потомков, в которых реализуется вся функциональность.

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

Ну, стоит или нет, это уже вам решать. В принципе, переписать описываемую часть под ООП не слишком сложно и трудоемко, имхо. Главное, прикладная часть уже вылизана, ее не трогать. Т.е. просто останется "оболочку" перенести. Если идеология близка, то вообще должно легко пойти.

Может кто какую историю раскажет или своё мнение выскажет. Или поделится соображениями на этот счёт.

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

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

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