Cygwin лучше для кроссплатформенного приложения на C ++?

Question

Я думаю о кроссплатформенном серверном приложении C ++, которое может включать в себя интенсивные rnet трафик c и многопоточные вычисления. Я прочитал несколько сравнений Cygwin и MinGW для кроссплатформенного приложения C ++. Основываясь на новой информации о 5-м ответе на этот вопрос StackOverflow от Kaz, могу ли я сказать, что Cygwin имеет лучшее будущее?

19 июля 2019 года Kaz добавил следующую новую информацию ( скопировано оттуда):

Plug: Вскоре после объявления LGPL я запустил проект Cygnal (Cygwin Native Application Library), чтобы предоставить вилку Cygwin DLL, которая направлена ​​на исправление этих проблем. Программы можно разрабатывать под Cygwin, а затем развертывать с Cygnal-версией cygwin1.dll без перекомпиляции. По мере совершенствования этой библиотеки она постепенно устраняет необходимость в MinGW.

Когда Cygnal решит проблему обработки пути, можно будет разработать единственный исполняемый файл, который работает с Windows путями при поставке в виде приложения Windows с Cygnal и без проблем работает с путями Cygwin при установке в ваш / usr / bin под Cygwin. Под Cygwin исполняемый файл будет прозрачно работать с таким путем, как / cygdrive / c / Users / bob. В собственном развертывании, где он связывается с Cygnal-версией cygwin1.dll, этот путь не будет иметь смысла, тогда как он будет понимать c: foo.txt.

Он сказал: По мере того, как эта библиотека улучшается, она постепенно устраняет необходимость в MinGW . Что это на самом деле означает?

Answer 1

Я так не думаю.

Во-первых, я больше не рассматриваю MinGW, поскольку MinGW-w64 - намного лучшая и более современная альтернатива.

Во-вторых, Cygwin и MinGW-w64 преследуют разные цели. Cygwin хочет обеспечить достаточное количество эмуляции Unix / POSIX для компиляции кода, который иначе трудно перенести на собственный Windows. Таким образом, двоичные файлы Cygwin зависят от этого уровня эмуляции, что означает их не совсем собственный Windows, так как уровень эмуляции всегда присутствует, что также имеет накладные расходы на производительность. Но MinGW-w64 нацелен на возможность компиляции в собственные Windows двоичные файлы. Недостатком является то, что не все исходные коды Unix / Linux / POSIX будут компилироваться с ним (например, fork() не существует), но многие вещи компилируются, и в результате создаются производительные собственные Windows двоичные файлы.

Лично у меня вообще не было необходимости использовать Cygwin в последнее десятилетие. Я сейчас все собираю с помощью MinGW-w64. На самом деле у меня даже нет MSV C или каких-либо других компиляторов (например, Borland или Intel) на моем p c.

Мой совет всегда: используйте Cygwin только в том случае, если вам действительно нужно. В противном случае MinGW-w64, особенно в сочетании с MSYS2, всегда ваш лучший выбор. Это особенно верно, если вы планируете разрабатывать программное обеспечение для коммерческого распространения. Если бы я использовал программное обеспечение и заметил бы, что библиотеки Cygwin являются частью, это заставило бы меня нахмуриться и задуматься, действительно ли программное обеспечение предназначено для Windows.

В то время как MSYS2 предлагает достойный компилятор MinGW-w64 G CC , Я решил запустить проект http://winlibs.com/, чтобы предоставить свою личную сборку MinGW-w64 G CC и даже LLVM / Clang, а в будущем, надеюсь, многие библиотеки как для родного win32, так и для win64 .

В заключение по вашему вопросу: если вы планируете создать что-то, что должно быть ресурсоэффективным, я действительно рекомендую вам не брать на себя накладные расходы производительности Cygwin, а стремиться к максимальной собственной производительности с помощью MinGW-w64 вместо этого.