Перезапись кодовой базы C ++ из MFC в * nix

Question

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

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

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

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

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

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

Answer 1

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

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

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

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

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

Answer 2

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

Answer 3

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

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

Answer 4

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

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