Можно ли использовать класс string в dll С++?

Question

[kot220487]

В рамках задачи написания dll-библиотеки, в которую собираюсь передавать строки, их изменять, и возвращать одну модифицированную, решаю вопрос с использованием типов данных. Пытаюсь в dll запихнуть подобное:
string MyFunc(string s1, string s2)
{
string s3 = s1 + s2;
return s3;
}
- не получается. Хочу уточнить, могу ли я как-то использовать string, или придется пользоваться либо массивом символов, либо указателем на символ?

Answer 1

[jcmvbkbc]

Можно ли использовать класс string в dll С++

Можно.

Пытаюсь в dll запихнуть подобное:
...
- не получается.

Что не получается-то? Не компилируется? Не линкуется? Падает при выполнении? Что пишет?

Comments

[kot220487]

не компилируется. string is undefiend. Возможно необходимо использование пространства имен...

[jcmvbkbc]

#include <string>

и дальше в тексте либо std::string, либо using std.

[kot220487]

Получилось!!! Спасибо. Проблема была в этом.

[becks]

Эмн... странно, а я всегда думал, что это небезопасно, и передавать\возвращать можно только pod-типы.

[jcmvbkbc]

@becks расскажите, почему? Чем по-вашему отличается вызов функции в dll от вызова функции в основной программе?

[becks]

stackoverflow.com/questions/22797418/how-do-i-safe...

[jcmvbkbc]

@becks вон вы о чём. Ключевая фраза по вашей ссылке -- "I can't control what compiler these plugins are built with". Сравните с вопросом автора: "В рамках задачи написания dll-библиотеки, в которую собираюсь передавать строки...".

[becks]

@jcmvbkbc, подскажите, пожалуйста, как вы собираетесь использовать подобную библиотечную функцию, допустим, в Delphi? Откуда компилятор узнает, что такое std::string, как у него организована память? Или, если ваша библиотека собрана, допустим, MINGW, а основное приложение на MSVC\Builder. Есть основные вещи из стандарта, которым должен следовать каждый компилятор, остальное на откуп производителя.

[jcmvbkbc]

@becks чувак, завязывай, "класс string в dll С++", какие дельфи?

[becks]

@jcmvbkbc Вы уж простите, но я Вам не чувак.
>класс string в dll С++
Из этой строчки вы поняли, что и dll и основное приложение написано на C++? Я понял, что dll написана на С++, а про основное приложение ничего не сказано. Это первое.

Второе. Тем не менее, даже, если речь шла только про С++, тут ничего не сказано про компиляторы. Это не будет работать (или скорее всего не будет работать) с разными компиляторами\версиями компилятора! Так что в любом случае Вы даете плохой совет.

Третье. Это уже мой совет автору. Используйте в dll только pod-типы. Внутри можно использовать все, что захотите, но снаружи должны быть видны только pod'ы. Это безопасно и универсально, избавит вас от головной боли в использовании библиотечки.

[jcmvbkbc]

> я Вам не чувак
а было очень похоже, когда речь пошла про дельфи.

>> класс string в dll С++
> Из этой строчки вы поняли, что и dll и основное приложение написано на C++?
из этой строчки я понял, что dll пишется автором на C++. Основное приложение должно бы быть написано на С++ чтобы с лёгкостью передавать std::string куда-нибудь, иначе мы бы сначала увидели какой-нибудь другой вопрос, например, "как из дельфи передать в dll на С++ std::string".

> в любом случае Вы даете плохой совет
во-первых в моих ответах нет советов.
Во-вторых, не в любом же. В типичном случае использования одного компилятора всё будет работать нормально.

> Используйте в dll только pod-типы. Внутри можно использовать все, что захотите, но снаружи должны быть видны только pod'ы
вы бы тогда уж добавили, что функции видные снаружи должны быть хотя бы extern "C", а то ведь и mangling может быть разный, и конвенция вызова.

[becks]

@jcmvbkbc

я Вам не чувак
а было очень похоже, когда речь пошла про дельфи.

Я, признаться, не улавливаю здесь совершенно никакой корреляции.

И Вы цепляетесь исключительно к моему упоминанию delphi, отводя на второй план мною указанное возможное различие компиляторов. Если уж Вы сочли мою догадку в использовании автором dll не из С++ глупой, почему свою догадку про

типичный случай использования одного компилятора

вы не находите таковой? В постановке вопроса про один компилятор не слова. Ну и ваш типичный случай - это парниковый вариант.

Основное приложение должно бы быть написано на С++ чтобы с лёгкостью передавать std::string куда-нибудь, иначе мы бы сначала увидели какой-нибудь другой вопрос

"Основное приложение должно бы быть написано на С++"
WTF? С чего бы это оно должно и как это вы поняли?

написано на С++ чтобы с лёгкостью передавать std::string куда-нибудь

Дружок, вы опять забыли про различия в компиляторах и их версиях. Программист Вася использует MINGW, Сережа Bulder 6, а Юра MSVC 11, Петя из другого отдела должен сделать для них dll. Уже сейчас он должен собирать в вашем варианте 3 версии. Если кто-то из разработчиков перейдет на другую версию компилятора, он должен дернуть Петю, и Петя должен пересобирать dll под него. Да они затрахают друг друга безо всяких delphi и прочих. Видимо любитель ответов не работал в компании > 3 человек.

вы бы тогда уж добавили, что функции видные снаружи должны быть хотя бы extern "C", а то ведь и mangling может быть разный, и конвенция вызова.

К счастью, все это было в моей ссылке выше, которую, конечно же, Вы прочитали? )

Я подытожу, спорить дальше смысла не вижу.
Если Вы(автор) только набиваете шишки, Вы можете пойти по такому пути. Когда кому-то еще потребуется использовать вашу библиотеку вы обязательно рано или поздно наткнетесь на проблемы.

[jcmvbkbc]

@becks вы такой опытный, предусмотрительный и проницательный, а так же начитанный, корректный и уравновешенный. Спасибо вам большое.

Answer 2

[Flaker]

Всегда можно создать строку из массива символов:

std::string str(buf, sizeof(buf));

Answer 3

[tsarevfs]

А что именно не работает? Runtime library и конфигурация(debug/release) совпадают?

Answer 4

[AxisPod]

А почему нет? Конечно не желательно использовать dll с одним рантайм, в приложении/dll с другим рантайм. Если проект свой и всё спокойно пересобирается, то проблем вообще нет.