Блог

Я летом стажируюсь в компании, и мне приходится рассматривать различные способы просмотра текущей кодовой базы (C , MFC, около 100 тыс. строк) и использования конечных автоматов для моделирования текущей программы.

Я прочитал пару статей, и CPP2XMi выглядит так, как будто для начала может быть полезно попытаться построить диаграммы последовательностей.

Конечная цель — оценить возможность отказа от Microsoft как операционной системы и посмотреть на разработку (возможно, на другом языке) на * nix.

Я также начал изучать зависимости MFC, чтобы понять, можем ли мы просто перенести текущий код C .

У меня была программа, запущенная через WINE, и с точки зрения производительности это кажется приемлемым, но мне все еще нужно изучить другие решения, поскольку это будет работать только на X86, в то время как у нас есть другие решения, работающие на MIPS и ARM.

Какие-либо другие идеи или предостережения, на которые я мог бы обратить внимание?

Первое, на что я хотел бы обратить внимание, это где я могу использовать mfc и другие непереносимые материалы. Если единственное место, где есть mfc, находится, например, на уровне интерфейса, вы можете изолировать работу.

Если такого разделения нет, я бы посмотрел на возможность создания некоторых разделов кода, которые являются изолированными и переносимыми. Как только у вас будет база переносимости, вы можете начать абстрагировать все сервисы, предоставляемые непереносимым кодом. Любой способ, которым вы ее нарезаете, хотя MFC на Nix — это большое изменение и потребует значительного объема работы. Еще одна возможность — посмотреть, можете ли вы запустить ее под эмулятором Windows.

При чтении книги wxWidgets это кажется очень похожим на MFC. Вы могли бы взглянуть на это.

Сначала я бы посмотрел, отделен ли графический интерфейс от остальной части приложения. С MFC это включает в себя ограничение использования служебных классов, таких как CString , кодом, использующим только графический интерфейс.

Если код хорошо продуман таким образом, то, вероятно, проще всего оставить код графического интерфейса MFC в покое и просто создать новый графический интерфейс для других ваших платформ, используя собственную библиотеку графического интерфейса по выбору для каждой новой платформы. Это придаст приложению надлежащий внешний вид и поведение, которых действительно трудно достичь любым другим способом.

Если логика приложения перемешана с кодом GUI, самое время спросить, не могли бы вы выделить ресурсы для создания надлежащего разделения с целью выполнения вышеуказанного после достижения разделения. Это рискованно с точки зрения бизнеса, потому что может показаться, что вы приложили много усилий и просто вернулись к тому, с чего начали. Ваши спонсоры не увидят реального прогресса, пока вы не начнете работу над новым графическим интерфейсом поверх переработанного приложения.

Вы также можете посмотреть на переносимые библиотеки GUI, такие как wxWidgets и Qt.

Я программировал как для MFC, так и для wxWidgets, и концептуально они очень похожи. Мне никогда не приходилось переносить код с одного на другой, но я однажды перенес код из Borland’s OWL в MFC, что было похоже на опыт. Такого рода вещи не особенно сложны; это просто измельчение. Я могу рекомендовать делать это только тогда, когда у вас есть несколько причин для удаления старой библиотеки GUI. Например, возможно, вы также подумывали о том, чтобы полностью отказаться от Visual C или переключиться с Professional на Express, потеряв доступ к MFC. Если вы планировали использовать VC Professional (или выше), становится трудно оправдать отказ от вашего графического интерфейса MFC.

Однажды я портировал большую COM-библиотеку из MFC в portable code. Я использовал STL и boost для замены всех битов MFC. Например, CString => std::string и VARIANT => boost::any.

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