Дизайн интерфейса C ++ вокруг границ разделяемых библиотек

Предположим, у меня есть два проекта. Одно - приложение, а другое - разделяемая библиотека, содержащая общий, многократно используемый код, который может использоваться не только этим приложением.

Мое приложение использует STL, и моя разделяемая библиотека также использует STL. Первая проблема здесь в том, что моя общая библиотека использует STL. Если я когда-нибудь встраиваю новую версию STL в свое приложение, но не перестраиваю свою общую библиотеку, потому что в этом нет необходимости, у нас сразу же возникнут проблемы совместимости.

Моя первая мысль решить эту проблему - не использовать STL вовсе не в интерфейсе к классам разделяемой библиотеки. Предположим, у нас есть функция в моей библиотеке, которая принимает строку и что-то с ней делает. Я бы сделал так, чтобы прототип функции выглядел так:

void DoStuffWithStrings( char const* str );

вместо:

void DoStuffWithStrings( std::string const& str );

Для строк это, вероятно, будет нормально для разных версий STL, но обратная сторона заключается в том, что мы переходим из std :: string , в char * и обратно в std :: string , что, похоже, вызывает проблемы с производительностью.

Рекомендуется ли упаковка / распаковка необработанных типов в их аналоги в STL? Это становится еще хуже, когда мы пытаемся сделать это с std :: list , поскольку на самом деле не существует «сырого типа», о котором я знаю, что мы могли бы легко передать его, не выполняя каких-либо O ( n) или аналогичная операция.

Какие конструкции работают лучше всего в этом сценарии? Каковы плюсы и минусы каждого из них?

8
задан void.pointer 3 August 2011 в 14:56
поделиться