c ++ 11 — переносимость стандартной библиотеки C ++
Я работаю в крупных мультиплатформенных сетевых приложениях в реальном времени. В проектах, над которыми я работаю, отсутствует какое-либо реальное использование контейнеров или стандартной библиотеки в целом, никаких умных указателей или каких-либо «современных» функций языка C ++. Многие необработанные динамически размещенные массивы являются обычным явлением.
Я бы очень хотел начать использовать Стандартную библиотеку и некоторые спецификации C ++ 11, однако, многие люди также работают над моими проектами, которые против, потому что «STL / C ++ 11 не так переносим, мы рискнуть, используя это «. Мы запускаем программное обеспечение на самых разных встраиваемых системах, а также на полноценных системах Ubuntu / Windows / Mac OS.
Итак, на мой вопрос; Каковы актуальные проблемы переносимости, касающиеся Стандартной библиотеки и C ++ 11? Это просто случай, когда g ++ прошёл определенную версию? Есть ли платформы, которые не поддерживают? Требуются ли скомпилированные библиотеки и, если да, их сложно получить / скомпилировать? У кого-нибудь были серьезные проблемы, связанные с непереносимым чистым C ++?
Решение
Поддержка библиотек для нового стандарта C ++ 11 довольно полная для Visual C ++ 2012, gcc> = 4.7 и Clang> = 3.1, за исключением некоторых вещей, связанных с параллелизмом. Поддержка компилятора для всех отдельных языковых функций — это другое дело. Видеть это ссылка на сайт для актуального обзора поддерживаемых функций C ++ 11.
Для глубокого анализа C ++ во встроенной среде / среде реального времени, Scott Meyers’s презентационные материалы действительно здорово. Здесь обсуждаются затраты на виртуальные функции, обработку исключений, шаблоны и многое другое. В частности, вы можете захотеть взглянуть на его анализ функций C ++, таких как распределение кучи, информация о типах времени выполнения и исключения, которые имеют неопределенные гарантии времени худшего случая, которые имеют значение для систем реального времени.
Именно такие проблемы, а не мобильность, должны быть вашей главной заботой (если вы заботитесь о кардиостимуляторе вашей бабушки …)
Другие решения
Любой компилятор для C ++ должен поддерживать некоторую версию стандартной библиотеки. Стандартная библиотека является частью C ++. Не поддержка означает, что компилятор не является компилятором C ++. Я был бы очень удивлен, если какой-либо из компиляторов, которые вы используете в данный момент, не поддерживает переносимую стандартную библиотеку C ++ 03, поэтому здесь нет оправданий. Конечно, компилятор должен быть обновлен с 2003 года, но если вы не компилируете для какой-то архаичной системы, которая поддерживается только архаичным компилятором, у вас не возникнет проблем.
Что касается C ++ 11, поддержка в настоящее время довольно хорошая. И GCC, и MSVC уже поддерживают большую часть стандартной библиотеки C ++ 11. Опять же, если вы используете последние версии этих компиляторов и они поддерживают системы, для которых вы хотите скомпилировать, то нет никаких причин, по которым вы не можете использовать подмножество стандартной библиотеки C ++ 11, которую они поддерживают — что почти все это.
C ++ без стандартной библиотеки просто не является C ++. Языковые и библиотечные функции идут рука об руку.
Есть списки поддерживаемых функций библиотеки C ++ 11 для GCC libstdc ++ а также MSVC 2012. Я не могу найти ничего похожего на libc ++ от LLVM, но у них есть страница поддержки clang c ++ 11.
Люди, с которыми вы говорите, путают несколько разных
проблемы. C ++ 11 сегодня не очень переносим. Я не думаю, что любой
компилятор поддерживает его на 100% (хотя я могу ошибаться); вы можете
избегать использования больших его частей, если (и только если) вы ограничиваете
себя до самых последних компиляторов на двух или трех платформах
(Windows и Linux, и, вероятно, Apple). Хотя это
наиболее видимые платформы, они представляют собой лишь небольшую часть всех
машины. (Если вы работаете в крупных сетях
приложения, Solaris, вероятно, будут важны и Sun CC.
Если Солнце сильно не изменилось с тех пор, как я в последний раз работал над этим, то
означает, что есть даже части C ++ 03, которые вы не можете сосчитать
на.)
STL — это совершенно другая проблема. Зависит частично
о том, что вы подразумеваете под STL, но, конечно, нет
проблема переносимости сегодня в использовании std::vector, locale
может быть проблематичным на очень немногих компиляторах (это было с Sun
CC — с библиотеками Rogue Wave и Stlport),
и некоторые алгоритмы, но по большей части, вы можете
в значительной степени рассчитывать на все C ++ 03.
И в конце концов, каковы альтернативы? Если у вас нет
std::vectorв конечном итоге вы реализуете что-то в значительной степени
нравится. Если вы действительно беспокоитесь о наличии
std::vectorоберните это в своем собственном классе — если когда-либо это не
доступно (крайне маловероятно, если вы не вернетесь со временем
машина), просто переопределить его, так же, как мы делали в
предстандартные дни.
использование STLPort с вашим существующим компилятором, если он поддерживает это. Это не более чем библиотека кода, и вы без проблем используете другие библиотеки, верно?
Каждое разрешенное для реализации поведение указано в общедоступном стандартная тяга. В C + 11 нет ничего менее портативного, чем в C ++ 98.