Вопрос API статической библиотеки (std::string vs. char*)

Я раньше не работал со статическими библиотеками, а теперь надо.

Сценарий:

Я пишу консольное приложение в Unix. Я свободно использую std::string везде, потому что это легко сделать. Однако недавно я узнал, что должен поддерживать его в Windows, и стороннему приложению потребуется API для моего кода (я не буду делиться исходным кодом, только DLL).

Имея это в виду, могу ли я по-прежнему использовать std::string везде в своем коде, но затем предоставлять им char * при кодировании API? Будет ли это работать?


c++ string portability
person djones2010    schedule 02.02.2010    source источник
comment
скорее используйте const char* для API...   -  person smerlin    schedule 02.02.2010
comment
это уже спрашивали...   -  person dirkgently    schedule 02.02.2010

Ответы (6)


arrow_upward
4
arrow_downward

Ага. Используйте std::string внутри, а затем просто используйте const char * в функциях интерфейса (которые будут преобразованы в std::strings на входе.

person Peter Alexander    schedule 02.02.2010
comment
Чтобы сделать еще один шаг, я предлагаю избегать любых типов C++ в ваших общедоступных подписях API-функций (например, без векторов). - person Brian; 02.02.2010

arrow_upward
1
arrow_downward

Почему бы просто не предоставить им std::string?
Это стандартный C++, и я был бы очень удивлен, если бы они его не поддерживали.

person Joseph Salisbury    schedule 02.02.2010
comment
Что ж, если кому-то нужно взаимодействовать с этой статической библиотекой на языке, отличном от C++, ему придется нелегко. - person Peter Alexander; 02.02.2010
comment
Конечно, поддерживают. Даже на C++ реализации, возможно, отличаются, заставляя клиента везде использовать ваш std::string. А теперь представьте, если бы это сделали две библиотеки. - person peterchen; 02.02.2010

arrow_upward
0
arrow_downward

Вопрос в том, что ваши клиенты будут делать с этим указателем. Конечно, это должно быть const char*, но если клиенты будут хранить его и ссылаться на него позже, вероятно, рискованно использовать std::string внутри, потому что, как только вы работаете со строками, нет никакого способа сохранить std::string от перемещаемая память, так как ее механизм подсчета ссылок не может работать с экспортированными указателями char*. Пока вы не трогаете объекты std::string, их память не перемещается, а указатель в безопасности.

person RED SOFT ADAIR    schedule 02.02.2010

arrow_upward
0
arrow_downward

Стандартизированного бинарного интерфейса C++ не существует (по крайней мере, я о нем не слышал), поэтому проекты с разными настройками могут оказаться несовместимыми друг с другом. Например, Visual C++ предоставляет способ включения/отключения поддержки отладки итератора. Это контролируется макросом, и от него зависит размер некоторых структур данных.

Если два кода, скомпилированные с разными настройками, начинают взаимодействовать с использованием этих структур данных, лучшее, что может случиться, — это ошибка компоновщика. Другие альтернативы хуже - стабильная ошибка времени выполнения, ошибка только конфигурации выпуска и т. д.

Поэтому, если вы не хотите ограничивать своих пользователей одним правильным набором настроек проекта и версией компилятора, используйте только примитивные данные для интерфейса. Для внутренней реализации выбираем что удобнее.

person maxim1000    schedule 02.02.2010

arrow_upward
0
arrow_downward

Добавление к ответу Poita_:

  • подумайте о поддержке юникода. Если вам когда-нибудь понадобится поддерживать локализацию, вы будете счастливы, что сделали это в первую очередь

  • при возврате char/wchar_t const * определите время жизни данных. Лучше всего иметь общепроектный стандарт "если не указано иное..."
    В качестве альтернативы вы можете вернуть копию, которая должна быть освобождена с помощью метода, экспортированного вашей библиотекой. (Клиенты C++ могут переместить его в интеллектуальный указатель, чтобы восстановить автоматическое управление памятью.)

person peterchen    schedule 02.02.2010

arrow_upward
-1
arrow_downward

std::string будет работать, по крайней мере, в Visual Studio C++ (и других), так почему бы просто не использовать это?

person Ruddy    schedule 02.02.2010
comment
Однако это не обязательно будет работать через границу DLL. Статические библиотеки тоже проблематичны — даже если вы скомпилируете с правильной версией компилятора, люди, использующие нестандартную реализацию STL, пострадают. - person peterchen; 02.02.2010