Нужен совет по преобразованию одного из устаревших компонентов C ++ в C #

Question

В настоящее время мы работаем на базе унаследованного кода C ++, которая состоит из нескольких программных компонентов.

Один из компонентов написан так, что его крайне сложно поддерживать. (Например, выделение памяти выполняется в X месте, но удаление памяти выполняется в Y. Это делает управление памятью болезненной работой). До сих пор мы смогли решить (или обойти) все проблемы утечки памяти.

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

Я знаю, что было бы плохо переписать исходный код: http://www.joelonsoftware.com/articles/fog0000000069.html

Однако вместо перефакторинга текущего кода, мы ожидаем, что будет лучше переписать с нуля из-за

• До сих пор никто в команде не мог полностью понять этот программный компонент.
• Устаревший программный компонент представляет собой небольшую часть программного обеспечения. 20 тысяч строк, наверное
• Наши команды достаточно четко понимают требования и то, что мы пытаемся достичь

Следовательно, мы планируем использовать управляемый код, по крайней мере сделать управление памятью безболезненным занятием . Мы планируем выбрать C #, как

• Весь наш код C ++ скомпилирован с использованием Microsoft VC ++
• Мы используем MFC в других программных компонентах. (в форме DLL) Каждая DLL имеет свой собственный ресурс.

Я из C ++ и Java, и ничего не знаю о C #.

1. Насколько хорошо C # для взаимодействия с MFC DLL, с некоторыми функциями DLL будет вызывать MFC GUI?
2. Что-нибудь, на что мне нужно обратить внимание?
3. Будет ли легче взаимодействовать с устаревшими DLL-библиотеками C ++, если мы используем Managed C ++?

Спасибо.

Answer 1

Я нахожусь в подобной ситуации, и я также провел несколько экспериментов, смешивая C ++ и C #. Проблемы в моем приложении, однако, были следующими:

• приложение не четко разделено на разные модули, что затрудняет перемещение отдельных модулей из C ++ в C #
• приложение довольно интенсивно использует процессор, и эксперименты выявили большие издержки при вызовах из C ++ в C # или из C # в C ++

Кроме того, вы не можете вызывать C # напрямую из нативного / неуправляемого C ++, что означало, что мне пришлось ввести дополнительный промежуточный уровень C ++ / CLI (или это называется C ++. Net?).

Поэтому я решил не переходить на C #, а остаться с C ++.

Итак, если вы хотите перейти с C ++ на C #, убедитесь:

• что у вас четко разделенные модули
• что переход (вызовы) из C ++ в C # или наоборот происходит в месте, которое не используется так часто (например, не во время интенсивных задач)

Кроме того, помните, что если вы не являетесь единственным разработчиком проекта, то все (или большинство) ваших разработчиков должны также изучать C #. Вы не хотите делегировать весь код C # вашему последнему младшему разработчику, потому что, если он уйдет, у вас будут (или могут быть) проблемы.

Answer 2

Насколько хорошо C # для взаимодействия с MFC DLL, с некоторыми функциями DLL будет вызывать MFC GUI?

Не совсем хорошо.Вы не можете использовать P / Invoke для библиотеки C ++ - она ​​работает только с экспортом на C.Вам нужно написать оболочку, предоставляющую вам интерфейс библиотеки C для P / Invoke из C #, или вам нужно будет перекомпилировать MFC с использованием C ++ / CLI.Хотя для этого нет особых причин, поскольку Winforms - это библиотека, сравнимая с MFC для кода .NET.

Что-нибудь, на что мне нужно обратить внимание?

Не знаюЯ не понимаю этого вопроса.

Будет ли легче взаимодействовать с устаревшими библиотеками C ++, если мы используем Managed C ++?

Учитывая, что вы не можете сделать это с помощью C #,да.Вам нужно будет перекомпилировать эти библиотеки DLL C ++, чтобы они открыли интерфейс C, или вам придется перекомпилировать их из исходного кода с помощью C ++ / CLI.

---

Примечание: независимо от того, что вы здесь делаете,вам все равно придется беспокоиться об управлении памятью и продолжительности жизни объектов, происходящих внутри нативного кода.CLI не может автоматически управлять вашими собственными ресурсами.