Помимо приведенных здесь причин, есть еще одна - двоичная совместимость . Авторы библиотек не контролируют, какую std::string
реализацию вы используете и имеет ли она ту же структуру памяти, что и их.
std::string
является шаблоном, поэтому его реализация взята из ваших локальных заголовков STL. Теперь представьте, что вы используете локальную версию STL с оптимизированной производительностью, полностью совместимую со стандартом. Например, вы, возможно, решили использовать статический буфер в каждом, std::string
чтобы уменьшить количество динамических выделений и пропусков кэша. В результате компоновка памяти и / или размер вашей реализации отличается от библиотеки.
Если отличается только компоновка, некоторые std::string
вызовы функций-членов в экземплярах, переданных из библиотеки в клиент, или наоборот, могут завершиться ошибкой в зависимости от того, какие элементы были смещены.
Если размер также отличается, все типы библиотек, имеющие std::string
член, будут иметь разный размер при проверке в библиотеке и в клиентском коде. Для элементов данных, следующих за std::string
элементом, также будут смещены смещения, и любой метод прямого доступа / встроенного доступа, вызванный из клиента, будет возвращать мусор, несмотря на то, что при отладке библиотеки он выглядит «нормально».
Итог - если библиотека и клиентский код скомпилированы против разных std::string
версий, они будут просто отлично связываться, но это может привести к некоторым неприятным, трудным для понимания ошибкам. Если вы измените свою std::string
реализацию, все библиотеки, выставляющие элементы из STL, должны быть перекомпилированы, чтобы соответствовать std::string
макету клиента . И поскольку программисты хотят, чтобы их библиотеки были надежными, вы редко будете видеть их std::string
где-либо открытыми.
Чтобы быть справедливым, это относится ко всем типам STL. IIRC у них нет стандартизированного расположения памяти.