MFC — Windows GUI и собственный переполнение стека
Я делаю студенческий проект под названием «Разработка игр C ++». Это карточная игра с клиентом и сервером. Клиентское приложение содержит несколько окон, которые я уже сделал с Windows Forms в Visual Studio 2013. Для связи клиент / сервер я решил использовать Механизм интернет-коммуникаций (ICE). Во время сборки в проекте клиента у меня были ошибки в автоматически сгенерированном коде ICE. Я обнаружил, что ICE не поддерживает C ++ / CLI, только родной C ++ или C # (что я не могу использовать).
Так что теперь я нахожусь на распутье, будь то создание всего клиентского приложения на нативном C ++ (это означает, например, использование MFC, с которым я не знаком) или использование как нативного C ++, так и C ++ / CLI (поставь работу, которую я сделал с Windows Forms в библиотеку классов CLR и ссылку на нее из собственного проекта C ++ с точкой входа), что тоже не тривиально.
Я пытаюсь выбрать менее трудоемкий вариант. Я прошу помочь мне оценить сложность этих подходов. Мне нравится второе намного больше, но я не уверен, что это самое простое.
Решение
C ++ / CLI может нормально использовать собственный код C ++.
Вставьте сгенерированный код в «проект статической библиотеки», который создается без /clr, Затем перечислите эту статическую библиотеку как зависимость вашей C ++ / CLI DLL.
Компоновщик выяснит все остальное. Результат называется «сборка в смешанном режиме».
Обратите внимание, что ваша библиотека может не принимать управляемые типы. Это нормально, C ++ / CLI может прекрасно сочетать классы неуправляемой модели данных и классов управляемого представления (UI).
Другие решения
Это зависит от того, сколько сложности уже есть в вашем графическом интерфейсе. Если у вас есть сто диалогов и элементов управления, то переписать их на родном C ++ может быть неправильный ответ. В этом случае превращение вашего GUI в библиотеку имеет больше смысла.
Тем не менее, это, вероятно, лучший вариант сохранить ваш GUI как процесс и создать прокси-библиотеку на нативном C ++, которая передает вызовы ICE на ваш сервер. (поэтому C ++ / CLI exe вызывает функцию в новой библиотеке C ++, которая делает ICE-вызов серверу и наоборот).
Если ваш GUI небольшой, то лучше всего переписать его в современной (и лучше поддерживаемой, чем C ++ / CLI) системе. Qt, вероятно, в настоящее время является наилучшим в нативных графических интерфейсах (но есть альтернативы, такие как MFC или wxWidgets). Даже в этих случаях все равно, вероятно, все равно лучше кодировать вашу сетевую подсистему как собственную библиотеку. Затем вы можете изменить свой графический интерфейс и испытать загрузку стеков графического интерфейса по своему усмотрению, портировав свою игру на Android или iOS всего за 1 смену уровня представления.
Третий вариант — выбрать другую систему связи. Несмотря на то, что RPC, такие как ICE, хороши, сегодня «где это находится» — это веб-связь через сервисы REST (попробуйте встроенный веб-сервер c ++, такой как Mongoose или NxWeb), если вам нужно отправить данные обратно клиенту, они поддерживают WebSockets, поэтому обеспечит всю необходимую вам функциональность. И тогда вы можете переписать свой графический интерфейс на HTML!
Итак: поместите ваши связи в нативную библиотеку C ++.