Конструкция компилятора. Есть ли риск изменить диалект C ++ на C ++ 11, но сохранить стандартную библиотеку не C ++ 11 на XCode4?
Допустим, у меня есть кроссплатформенность (Win & Mac) производственная кодовая база, которая не использует C ++ 11.
Допустим, что параметры компилятора на Mac были изменены для использования диалекта языка C ++ 11, но без стандартной библиотеки C ++ 11.
Я пытался погуглить, чтобы понять возможные последствия, но уже пустую.
Мои вопросы:
- Что означает изменение языкового диалекта в clang?
- Какой риск делать что-то подобное?
Решение
Я не использую XCode, но я представляю, если они поставляют (предположительно неполный, но получающий) режим C ++ 11 для clang, то они также поставляют (предположительно неполный, но получающий) стандарт C ++ 11 библиотека. И тестируем их вместе. Итак, ваша ситуация не должен возникают, но при условии, что в любом случае:
-
Формально это ничего не значит, потому что стандарт не признает никакого способа смешивания и сопоставления «языка» и «библиотек». Все зависит от вашего компилятора. Возможно, это означает, что стали доступны новые «языковые функции», такие как ссылки на значения, лямбда-выражения и т. Д., Но появились новые классы и функции в пространстве имен.
stdнет. -
Основной риск, вероятно, заключается в том, что вы больше не программируете по общепризнанному стандарту, а программируете, возможно, с недостаточно документированной вещью, изобретенной вашим компилятором. Если компилятор говорит, что в режиме C ++ 11 ему нужна стандартная библиотека C ++ 11, и вы предоставляете ей стандартную библиотеку C ++ 03, то вам даже не нужно обвинять документы компилятора — все может случилось, ты сломал это, твоя вина.
Помимо риска, связанного с этой забавной комбинацией, существуют небольшие риски, связанные с использованием кодовой базы C ++ 03 и ее компиляцией с использованием любой Компилятор C ++ 11. В C ++ 03 есть несколько конструкций кода, которые компилируются как C ++ 11, но имеют слегка (или сильно) другое значение.
Например, почти возможно написать класс в C ++ 03, который будет разрываться при использовании в C ++ 11, потому что C ++ 11 будет генерировать конструктор перемещения, который не делает правильную вещь. Иногда вам нужно заменить сгенерированный компилятором конструктор копирования, который не делает правильных действий (Правило Три), и хотя C ++ 11 гарантирует, что в этих «нормальных» ситуациях конструктор перемещения подавлен, есть некоторое странное преимущество случаев. К сожалению, я не могу вспомнить их в данный момент.
Стандарт C ++ 11 перечисляет некоторые несовместимости между C ++ 11 и C ++ 03. Вы бы на все надеялись, но знаете как. Список находится в приложении C. Он начинается с:
Действительный код C ++ 2003 может не скомпилироваться или привести к другим результатам
в этом международном стандарте. В частности, макросы с именемR,u8,u8R,
u,uR,U,UR, или жеLRне будет расширяться при соседстве со строкой
литерал, но будет интерпретироваться как часть строкового литерала.
и это не получит намного более захватывающего чтения оттуда. Но это в основном список вещей, которые, если они появляются в вашей кодовой базе C ++ 03, нуждаются в изменении, чтобы получить эквивалент C ++ 11.
Другие решения
На самом деле нет никакого «риска», но большая часть ценности C ++ 11 исходит из библиотеки.
Изменение языка на C ++ 11 означает, что поддерживаются функции языка C ++ 11. Если вы посмотрите на стандарт, то увидите, что он разделен на функции языка (пункты 1-16) и библиотеки (пункты 17-30). Функции языка охватывают такие вещи, как грамматика, значения выражений и операторов, разрешение перегрузки и т. Д. Функции библиотеки охватывают содержимое стандартных заголовков. Так что если вам нужен определенный заголовок, чтобы что-то делать в C ++ 11, то вам, вероятно, нужна стандартная библиотека C ++ 11.
Xcode поддерживает версию libstdc ++, которая поставляется с gcc 4.2 и была создана для C ++ 03. Это прекрасно работает, когда clang установлен в режим C ++ 11. Он также поддерживает libc ++, который предназначен для предоставления многих функций C ++ 11 даже с помощью компилятора C ++ 03. Таким образом, смешивание и сопоставление должны работать нормально по большей части. Однако вы получите гораздо больше пользы от использования языка и библиотеки, которые были разработаны друг для друга вместе.
Не забывайте, что многие языковые функции C ++ 11 поддерживаются библиотечными функциями — например, вы не будете иметь большого использования для ссылок на rvalue без std::move а также std::forwardи списки инициализатора тоже будут ненужными.
GCC и clang компилируют с ++ немного по-разному. это может не иметь значения в вашем случае, но в другом случае это может, так что вы можете вернуться к компиляции в стиле GNU. Отсюда и «языковой диалект».
Пока вы сохраняете язык и stdlib на версиях GNU, это не должно иметь никакого значения. Но компиляция с помощью компилятора Apple LLVM (clang) в диалектах GNU может не дать таких же результатов, как в Windows (при условии, что вы используете GCC на обоих). Я бы сказал, что вы всегда подвергаетесь некоторому риску, если вы не используете совпадающие библиотеки, компиляторы и настройки на обеих платформах, особенно когда в игру вступают сторонние библиотеки и вы меняете libstdc ++ с поддержкой libc ++ для C ++ 11.
в случае, если вы используете VC ++ в Windows, его поддержка C ++ 11 достаточно отсутствует, поэтому не удивляйтесь, когда ваш код XCode отказывается встроить VC ++.