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

[SasaVitebsk]

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

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

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


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

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


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

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

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