Ответ 1
Прежде всего, см. Статус экспериментальной поддержки С++ 11 в GCC 4.8. Пока еще официально не реализовано только одно предложение. Затем посмотрите Статус реализации С++ 11 в libstdc++
. Как видите, некоторые функции еще не реализованы. Тем не менее, мы можем заявить, что поддержка С++ 11 в GCC более или менее полная и удобная.
Теперь о Windows: возможно определенно лучший родной (не Cygwin!) порт GCC, который я лично считаю производственным качеством, MinGW-w64. Вы можете скачать его здесь. Текущая (на момент написания) последняя версия основана на GCC 4.8.2. Он уже поддерживает std::thread
. Что еще, он предлагает все возможные варианты:
- 64-битные цели;
- 32-битные цели;
- потоки Win32;
- потоки POSIX;
- исключения SEH;
- Исключения DWARF;
- Исключения SJLJ.
Примечание:
Будьте осторожны при выборе дистрибутива для загрузки: для доступности std::thread
вам нужен тот, у которого есть потоки POSIX.
Кроме того, я подтверждаю, что сам создавал Qt 4.8.4 и 4.8.5 несколько раз и даже нацеливал на 64-битную эту инструментальную цепочку. Но это не все, вот список некоторых основных моментов, которые я лично создал с помощью MinGW-w64:
- Boost С++ Libraries;
- Qt;
- LLVM/Clang;
- Google V8 JavaScript Engine;
- ODB: С++ Object-Relational Mapping (ORM);
- SQLite;
- GLEW;
- Vim;
- ncurses;
- и т.д...
Я думаю, что могу создавать такие огромные и разнообразные кодовые базы, как 64-битные цели с хорошим старым GCC для Windows, - это чудесное достижение команды разработчиков MinGW-w64. Это еще раз доказывает качество инструментальной цепочки.
Qt 5
Недавно я построил Qt 5.1.1, используя таргетинг MinGW-w64 4.8.2 x64. В целом, он прошел довольно гладко, но есть несколько второстепенных проблем, которые необходимо заплатить перед сборкой. Я аккуратно собрал все необходимые исправления и автоматизировал весь процесс исправления, сборки и установки простым пакетом script. Если вам интересно, посмотрите Qt для Windows. Использование настолько простое, что я пропущу комментирование и просто дам вам, ребята, прочитать пакет script. Имейте в виду, что вам нужно Unix patch.exe
применить патчи, которые вы могли бы получить, например, от MSYS или MSYS2 (см. Ниже). Вы можете получить исходный код Qt 5.1.1 here.
Примечание:
Не представляется разумным повторно изобретать колесо (поддерживая личные скрипты сборки и исправления для Qt). MSYS2 (см. Ниже) теперь заботится о всем. То есть, если вам нужно перестроить Qt с различными параметрами и/или флагами, просто отредактируйте соответствующий PKGBUILD
файл локально и соответствующим образом используйте утилиту makepkg-mingw
.
Примечание:
На самом деле проект Qt официально рекомендует использовать MinGW-w64 и MSYS2.
О MSYS2
Это не было задано напрямую, но мне хочется добавить его здесь, поскольку это сестра проекта MinGW-w64, и это очень полезно для всех, кто должен разработать собственное программное обеспечение для Windows с использованием среды, подобной Unix.
Те из вас, кто когда-либо использовал оригинальный MSYS, вероятно, знают, сколько ему лет. Он не был улучшен на века, и все утилиты Unix там уже ужасно устарели.
Ребята, которые предоставляют сборки MinGW-w64 (перечисленные выше), теперь также предоставляют сборки MSYS2 который вы можете скачать здесь. В последнее время он вышел из бета-версии, поэтому обязательно ознакомьтесь с последней версией. Он построен как для архитектуры x86, так и для x64 (с самой инструментальной сеткой MinGW-w64). Все утилиты обновляются до последних версий. Например, вы уже можете наслаждаться такими вещами, как: Bash 4.2, Make 3.99, Git 1.8.4 и многие другие; которые запускаются изначально из Windows!
Примечание:
Обязательно проверьте их Wiki.
Краткая история за MinGW-w64
Исходный MinGW был очень медленным в улучшениях, и его разработчики даже не подумали добавить 64 -битной поддержки генерации целевых объектов. Один амбициозный парень, Кай Тиц, взял на себя и разветкил его, так как его компании нужно было построить 64-битные цели в Windows. Вот как родился проект MinGW-w64. Хотя основной целью было добавить 64-битную поддержку, разработчики во многих аспектах улучшили инструментальную цепочку и рассмотрели множество других проблем. С тех пор проект MinGW-w64 вырос и теперь намного превосходит MinGW по качеству. Когда MinGW-w64 предложила MinGW присоединиться к домам и работать вместе, разработчики MinGW продемонстрировали неадекватную реакцию и отказались сотрудничать. В результате сегодня существует 2 проекта с похожим названием, что иногда вызывает путаницу, но различия в качестве и поддержке говорят сами за себя.