std::wstring в параметре функции DLL

[Алексей++]

имею ли я право делать следующее:  есть динамически подключаемая DLL , в ней экспортированная функция , например такая

Код: (C++)

extern "C" void WINAPI GetString(std::wstring& str)
{
     str.resize(100,0); //изменение кучи основного модуля из DLL
}

Если же память необходимо выделить до вызова - как это лучше организовать?

[RXL]

Леш, разве сишная функция совместима с ссылкой на объект?

[Алексей++]

считай её указателем )

Код: (C++)

extern "C" void WINAPI GetString(std::wstring* str)
{
     str->resize(100,0); //изменение кучи основного модуля из DLL
}

[RXL]

Нет, Леш, так делать нельзя. Во-первых, DLL ничего не знает о методах объекта, тем более интерфейс сишный. Во-вторых, выделять и освобождать память надо в одном месте, т.к. менеджеры кучи и сами кучи могут быть разные.
Чтобы управлять кучей основного модуля, DLL должен импортировать себе ее malloc/free и вызывать именно их. Сомневаюсь еще на счет совместимости различных версий runtime-библиотек. По этому правильно будет: выделять и освобождать память в одном месте.

Вот чувак тоже задумался и почитал классиков: http://www.cyberforum.ru/cpp-beginners/thread370440.html
Правда, у него движение в обратную сторону.

[Алексей++]

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

Добавлено через 1 минуту и 31 секунду:
я сделал так - вызываю функцию DLL , где выделяю память на объект std::wstring (и ещё парочку нужных типов) , потом указатель на этот объект уже передаю в DLL, чтобы она с ним работала. Ну и "удалятор" тоже как функция в DLL - примерно такая штука получается:

Код: (C++)

CDLL*pDLL=...; //обёртка для DLL

std::wstring* str=0;
pDLL->New(&str); //*str - объект строки
   pDLL->GetString(str);
   //...
pDLL->Del(&str);

но если параметров больше, чем 1, то такой огород получается )

[Dimka]

void * лучше.

[Вад]

Импорт stl-классов в DLL на практике как-то делают (можно погуглить), но это не так чтобы тривиально (разбирается, например, тут, во втором ответе: http://stackoverflow.com/questions/1881494/how-to-expose-stl-list-over-dll-boundary) - такого рода правки без серьёзных оснований лучше, как по мне, не вносить, потому что хрупкость конструкции резко возрастает, требуются экспертные знания, чтобы это при поддержке не сломать.

upd. Вот статья от MS в тему: http://support.microsoft.com/kb/168958/ru

[Алексей++]

Вад, что-то мне мой вариант больше понравился ))

[Вад]

Алексей1153++, ну, я сам тоже похожую схему предпочитаю, но отдаю так только "простую" память, а stl-контейнеры из dll возвращать не рискую: всё-таки, версии stl могут быть разные при сборке dll и клиентского кода - соответственно, и реализации класса wstring могут быть разными.

[RXL]

Леш, посмотри такую схему: указатели в DLL передаются только для копирования информации. Туже строку принял, создал свой объект, скопировал и вернул указатель. Основной модуль, соотв., должен этот указатель удалить функцией DLL.

[Алексей++]

Вад, RXL, да я вообще склоняюсь к радикальной мере - обмен через XML  Так как эта обвеска вся такая громоздкая (и, как выясняется, тоже небезопасная).

По схеме , предложенной Ромой, кстати.

[RXL]

Еще безопаснее обмен через временный файл. Передать в DLL можно открытый handle или константную строку пути. Но по моему это изврат.

[zubr]

Обмен памятью внутри процесса с использованием внешнего файла - имхо, кривовато. Уж тогда кошернее будет использовать файлмаппинг...

[Алексей++]

нет, файл точно отпадает. Максимум XML )  Достаточно гибко

Завтра опробую

[Алексей++]

кстати, а как думаете, может быть лучше передавать в функцию DLL указатель на функцию, которая будет выделять память в основном модуле ?

таким образом вызывающий никогда не "забудет" , что нужно удалять память (поскольку намёки на это всегда перед глазами при вызове) . В случае же, когда результат нужно очищать вызовом функции в DLL, это можно и забыть, тогда будет утечка

а ?

[zubr]

Имхо, проще, передавать в функцию указатель на указатель выделенной памяти средствами Windows, к примеру VirtualAlloc. Этот указатель будет сто пудов ликвидным в любом модуле процесса. Внутри длл-функции можно копировать в std::wstring и работать с этой структурой. По завершению функции можно создать новый блок памяти нужного размера (удалив старый) куда скопировать результат работы с std::wstring и передать его в двойной указатель.

[Вад]

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

[Джон]

кстати, а как думаете, может быть лучше передавать в функцию DLL указатель на функцию, которая будет выделять память в основном модуле ?

"Всё уже украдено до нас" (с)

Проблема стара как мир, и решение примерно такого же возраста. Лёш, ф-я получает в качестве параметров а) указатель на буфер, и б) - ссылку на размер. Вызывается 2 раза: 1 - указатель нуль, по возвращению в ссылке необходимый размер, после этого вызывающий создаёт У СЕБЯ буфер нужного размера, и вызывает ф-ю второй раз, с уже ненулевым указателем. Таким образом, вызывающий отвечает полностью за выделение памяти, да и размер буфера в ф-ю передавать невредно.

[Алексей++]

Джон, это совсем неудобно, так как DLL должна хранить у себя результат. А когда многопоточность ? А когда несколько вызывающих ? У меня будет так

[Dimka]

Я не понимаю, почему за память не может отвечать DLL? Чего тут сложного?

Код: (C++)

extern "C" void _declspec(dllexport) createA(void *a, unsigned long *size = NULL);
extern "C" void _declspec(dllexport) createB(void *b, unsigned long *size = NULL);
// ...
extern "C" void _declspec(dllexport) createZ(void *z, unsigned long *size = NULL);

extern "C" void _declspec(dllexport) destroy(void *any);

Куча функций создаёт что-то в блоках памяти, клиент получает указатели и (по желанию) размеры блоков. После окончания использования поручает DLL очистить память. Можно договориться, что: функции с префиксом create выделяют память, и нужно вызывать destroy; функции с префиксом get память не выделяют, destroy вызывать не нужно.

[RXL]

Дим, так надо же помнить, кто выделял память...

А нельзя ли импортировать в DLL функции malloc/free из уже подлинкованной к основному модулю runtime-библиотеки?

[Алексей++]

Dimka, сложного ничего

[Джон]

Джон, это совсем неудобно, так как DLL должна хранить у себя результат. А когда многопоточность ? А когда несколько вызывающих ? У меня будет так

Лёш, ну винда функционирует по такому принципу уже лет двадцать, и ничего, не жужжит. И с многопоточностью, и с несколькими вызывающими.

[Dimka]

Дим, так надо же помнить, кто выделял память...

А нельзя ли импортировать в DLL функции malloc/free из уже подлинкованной к основному модулю runtime-библиотеки?

А потом вспоминать, чей malloc вызывать и в каких случаях

Чего страшного запоминании? Нужен объект, который помнит, какому create какой destroy соответствует. Те же COM обращаются к счётчику ссылок - не забывают

[Алексей++]

Джон, ну это же не значит, что это нужно повторять У меня будет по 2 раза одних и тех же вычислений/операций, не хочу так )))

[Джон]

Ну, во-первых, чтобы ты ни сделал, ты будешь повторять. А во-вторых, почему одних и тех же? В первом случае тебе буфер заполнять не надо.