Передача std :: string в API библиотеки

Question

В настоящее время мы создаем API для определенной библиотеки. Часть интерфейса требует, чтобы библиотека получала и возвращала пользовательские классы, такие как vector и string.

При попытке смоделировать использование библиотеки в простом сценарии в режиме отладки происходит сбой системы при доставке строки в качестве ввода.

Я считаю, что в режиме отладки или выпуска существует другое представление класса строки. Тогда наша библиотека предполагает получить определенное представление, неправильно прочитать элемент данных и по пути раздавить. Итак, каков наилучший способ передачи объектов STL в API. Целевой ОС является Windows XP, скомпилированная с MSVC 8, хотя пользователь библиотеки будет использовать Windows, его компилятор может (и, вероятно, будет) отличаться Идеи, которые у нас были до сих пор:

1. Измените строку на char * - Но тогда разработчики могут быть сбиты с толку обязанностью освободить память.
2. Используйте нашу собственную версию String - я не хочу разрабатывать другую частную реализацию строки.
3. Выпуск для пользователя отладочной версии и выпуска версии.
4. Спросите людей в переполнении стека, какой вариант мы упускаем или не понимаем, или просто слышим по их опыту - готово.

Answer 1

Неразумно заставлять людей связываться с отладкой в ​​режиме отладки и выпускать в режиме выпуска. Вот как это делает практически каждая библиотека. Даже огромные проекты, такие как DirectX, выпускают отладочные компиляции своих двоичных файлов. № 3 - вполне разумный вариант / решение.

Answer 2

Вы должны избегать передачи объектов STL между различными двоичными модулями.

Для строки необходимо полагаться на const char* для параметра только для чтения и char*, <buffer size> для входных параметров ...

Для векторов это может быть немного сложнее, особенно если вам нужно изменить содержимое вектора ...

О ваших идеях:

1. Вы правы, но обычно принято, что вы не можете сохранить переданный указатель (вы должны сделать свою локальную копию).
2. В конце концов у вас возникнет та же проблема, если у вас не будет одинакового двоичного представления в отладочной и выпускной версии вашей реализации.
3. Это может быть вредно, если вы используете разные версии / реализацию STL в двух двоичных модулях (если вы не уверены, что пользователь библиотеки будет использовать один и тот же STL).