Общие вопросы портирования C ++ с Linux на Windows

Question

Справочная информация: Сетевая служба (tcp+udp, а не http) существует с готовым к публикации общедоступным клиентским API C++ linux. Этот клиентский API использует обычные сокеты tcp, сокеты udp, пространства имен C ++ и части stl, такие как std::map и std::vector, и будет опубликован в виде набора заголовочных файлов и файлов .a и .lib для ссылок.

Вопросы: Просто начинаю изучать, что потребуется для переноса этого клиентского API C ++ в Windows. Имеет ли смысл использовать gcc / g ++ под Windows? Я склоняюсь к тому, что это не сработает, поскольку разработчики под Windows обычно используют пакет Microsoft Visual Studio, и они не смогут связываться с библиотекой, созданной gcc. Это правильное предположение, или gcc предоставляет некоторые изящные переключатели, которые создают выходные файлы, совместимые с Microsoft-компилятором и Microsoft-linker?

Answer 1

Я бы порекомендовал сделать общедоступный стандарт API C, так как библиотеки C ++ даже не переносимы между различными компиляторами в Windows.Если требуется C ++, создайте небольшую оболочку C ++ поверх C API и распространите исходный код оболочки вместе с вашей библиотекой.

Если вам нужен чистый API C ++, вы можете распространять исходный код, если не хотитесоздать версию для каждого компилятора (или распространять только библиотеку Visual C ++).Зависит от того, является ли приемлемым распределение источника ...

Answer 2

Почему бы вам просто не создать dll и создать файл заголовка с помощью GetProcAddress и указателей функций?

Затем вы можете скомпилировать свой API с MinGW (g ++ / gcc) в Windows, используя msys.Единственное, что вам нужно сделать, это добавить некоторый код Windows, например, сетевые заголовки и wsastartup, ссылку на libwsock32.

И кроме того, перенос вашего кода на VC ++ не должен быть проблемой, ему просто нужен проекти некоторые ifdefs для специфичного для Windows кода.

Answer 3

Пока используемый вами компилятор создает подлинные файлы .dll или .lib, у вас не должно возникнуть проблем со связыванием их со стандартным компоновщиком в Windows. Однако только неуправляемая разработка (имеется в виду классическая разработка Win32 API) или C ++ / CLI смогут связываться с этими DLL-библиотеками. Если вы компилируете в .dll (не в .lib), вы можете нацелить эту сборку из управляемого контекста (C #, VB.NET и т. Д.), Используя синтаксис P / Invoke, но если все вы выполняете стандартные операции чтения / записи через сокет, вам, вероятно, лучше написать полностью управляемую реализацию в .NET.

В конце концов, все зависит от целевой аудитории: для классического Win32 у вас все в порядке. Для управляемых целей (чего угодно .NET, кроме C ++ / CLI) лучше написать управляемую реализацию на C # или VB.NET.

Answer 4

Проблема в том, что в C ++ не существует стандарта для преобразования имен, и даже если бы он существовал, связывание кода C ++ из разных компиляторов было бы проблематичным. На самом деле это проблема и для Linux, за исключением того, что большинство людей используют один и тот же компилятор.

Библиотеки, созданные с помощью MinGW g ++ (получите на http://tdragon.net/recentgcc,, а не на странице MinGW SF), совместимы с кодом Microsoft, но вам нужно будет предоставить интерфейс на языке C.

Answer 5

Это правильное предположение, или gcc предоставляет некоторые изящные переключатели, которые создают совместимые с компилятором Microsoft и компоновщиком Microsoft выходные файлы?

Это правильное предположение для скомпилированного C ++файлы.Я видел некоторые разговоры о том, что нужно сделать, чтобы добавить это в GCC, и был сделан вывод, что это было бы возможно, но довольно много работы.

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