Как лучше копировать память, обмениваться указателями и т.д. при работе с кучей динамических библиотек (DLL) ?

Привет!
Вот есть много DLL-к, каждая работает со своей внутренней динамической памятью, а так же есть необходимость работать с объектами в одной библиотеке, созданными динамический в другой... Ну то есть из одной DLL передаю указатель на память другой DLL.
Сто раз уже натыкался на то, что типа для DLL-к использование new/ delete не подходит, т.к. если я в одной DLL создам объект посредствам new, в другой DLL я его ен смогу удалить delete-ом ...
Возьмём конкретный пример:
1. В одной DLL создаётся какой - то экземпляр класса посредствам new
2. Указатель на этот объект передаётся в другую DLL
3. В этой другой DLL из п.2 производятся какие - то действия с этим объектом
4. После всех действий из п.3 необходимо освободить память из под объекта из п.1, то есть удалить его.

Вот через что лучше обмениваться памятью ?

DLL - я взял для сокращения, так что не обязательно привязываться к Windows, ибо софт - кроссплатформенный.
Знаю, что именно для Windows есть решение - HeapAlloc / HeapFree. Но хотелось бы узнать о каком - то кроссовом решение для этих целей.

0

Освобождай память в той же DLL где и выделял. Не вижу проблем.

0

Сообщение от castaway Освобождай память в той же DLL где и выделял

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

Добавлено через 39 секунд
Что мешает такому процессу?

0

Сообщение от -THE_MASTER666- Что мешает такому процессу?

ос Тут нужен жесткий костыль.

0

-THE_MASTER666-, ты можешь воспроизвести эту проблему?
Не по вопросу: почему не годится? Это нормальная практика.
Допустим DLL экспортирует две функции:
obj * obj_create() и obj_release( obj * )
Первая выделяет память, вторая освобождает.

0

Сообщение от MickeyBlueEyes ос Тут нужен жесткий костыль.

На само деле меня это вопрос не особо колышит, т.к. я делаю всё на Qt, а там все через хитрый Piml и прайват классы, там таких проблем не возникает )))
Думал просто разузнать, как так сказать на чистом языке такое сделать

Добавлено через 5 минут

Сообщение от castaway почему не годится?

Я сказал

Сообщение от castaway Допустим DLL экспортирует две функции:

Не... Ну вот смотри, одна DLL-ка посылает сигнал другой DLL-ке, тело сигнала - допустим указатель на объект, то есть в каком - то месте, в функции, создался объект, послался и всё, функция в первой DLL-ке вышла за пределы видимости, ну просто закончился код функции. То есть в первой DLL--ке указатель на новый объект потерялся, теперь он есть только во второй. Во второй я его хочу удалить... И ты предлагаешь передавать другим сигналом этот указатель как бы в первую обратно для удаления что ли? Ну как - то это не по фен шую... А почему нельзя просто удалить во второй египетская туча ?

0

Можно использовать shared_ptr. Он в себе держит функцию-deleter, которая будет в адресном пространстве той либы, где он был создан. Т.е. вызывать явно не придется. Но тут нужно помнить, что такой указатель обязан быть удален до того, как dll будет выгружена из памяти, иначе - сегфолт.
Но я это говорю просто как вариант, ибо не знаю общепринятых паттернов управления памятью в таких случаях. Основное правило уже сказали - где выделяем, там и освобождаем.

1

Сообщение от -THE_MASTER666- Знаю, что именно для Windows есть решение - HeapAlloc / HeapFree.

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

1

Сообщение от -THE_MASTER666- И ты предлагаешь передавать другим сигналом этот указатель как бы в первую обратно для удаления что ли? Ну как - то это не по фен шую...

Вот дался тебе этот delete. Тебе предлагают на стороне другой dll вызывать вместо delete функцию из первой dll. Разницы в семантике - ноль. А работать будет корректно.

dll1:
dll2:
Все.

1

Сообщение от DrOffset destroy(obj); // destroy из первой dll

Ну это я понял, типа вместо привычного delete надо использовать функцию из первой dll, и не забыть об этом сказать всем 10-кам программистов, которые будут после моего ухода из фирмы пилить мой код

Сообщение от Убежденный Если память выделяется в одном модуле, а освобождается в другом, у них должен быть общий аллокатор

Но ведь если использовать new / delete, это же одинаковые алокаторы ... Почему именно они не подходят?

Сообщение от Убежденный а для этого (в Visual C++) достаточно использовать ключ /MD(d) для обоих модулей.

и можно свободно будет пользоваться new / delete? Просто я обычно MT использовал, чтоб вкомпилить редистрюбитивы VS в EXE

Добавлено через 36 секунд

Сообщение от 0x10 Можно использовать shared_ptr.

хмм...надо подумать будет на досуге

0

Сообщение от -THE_MASTER666- Но ведь если использовать new / delete, это же одинаковые алокаторы ... Почему именно они не подходят ?

Да все просто. Представь: ты скомпилировал exe, у него свой аллокатор.
Дальше скомпилировал dll, у нее тоже свой аллокатор. Теперь ты в dll
создаешь объект (аллокатор Б), передаешь его в exe (там аллокатор А)
и просишь удалить. Аллокатор А не знает, как удалить объект, созданный
аллокатором Б. В итоге - AV и все такое. Но если использовать ключик
(волшебный!) /MD(d), аллокатор будет один, в msvcr(p).dll, и таких проблем
не возникнет.

2

Сообщение от -THE_MASTER666- об этом сказать всем 10-кам программистов, которые будут после моего ухода из фирмы пилить мой код

Это стандартная практика. Посмотри API каких-нибудь открытых проектов, так делают практически везде.

1

Ok. Всем спасибо. Всё понял.

Добавлено через 5 минут
Точнее не всё понял

Сообщение от Убежденный Дальше скомпилировал dll, у нее тоже свой аллокатор.

Что детально значит, "у неё тоже свой аллокатор" ? Ведь память то new выделяет одним и тем же способом и через всякие malloc-и... Может имеется ввиду, что у DLL другое виртуальное адресное пространство, и указатель на память в DLL при попытке использования его в ЕХЕ (для удаления) будет как бы не валиден, ну то есть указатель из DLL - это указатель на блок памяти в виртуальном пространстве DLL, а ЕХЕ такого адреса вообще может и не быть ну и тд ?
Если так, то как же тогда работает HeapAlloc ?

0

0

0

Сообщение от -THE_MASTER666- Что детально значит, "у неё тоже свой аллокатор" ? Ведь память то new выделяет одним и тем же способом и через всякие malloc-и... Может имеется ввиду, что у DLL другое виртуальное адресное пространство, и указатель на память в DLL при попытке использования его в ЕХЕ (для удаления) будет как бы не валиден, ну то есть указатель из DLL - это указатель на блок памяти в виртуальном пространстве DLL, а ЕХЕ такого адреса вообще может и не быть ну и тд ? Если так, то как же тогда работает HeapAlloc ?

HeapAlloc - это более низкий уровень, уровень ОС. Внутри же С\С++ runtime есть свой аллокатор, который использует уже функции ОС (HeapAlloc или еще что) для работы с памятью. Именно через этот аллокатор и работают "всякие malloc-и". Физически - это некая структура данных, которая осуществляет менеджемент памяти полученной от ОС, структура эта глобальная, поэтому когда runtime не один и тот же на оба модуля, то происходит ситуация:

Сообщение от Убежденный Теперь ты в dll создаешь объект (аллокатор Б), передаешь его в exe (там аллокатор А) и просишь удалить. Аллокатор А не знает, как удалить объект, созданный аллокатором Б. В итоге - AV и все такое.

Т.е. таких структур данных получается несколько (по одной на версию runtime линкуемых dll\exe), естественно они друг про друга не знают и память выделенная и зафиксированная в одной, не может быть освобождена с использованием другой. Вот и все.

Добавлено через 6 минут

Сообщение от -THE_MASTER666- Ну это я понял, типа вместо привычного delete надо использовать функцию из первой dll

Более того, этот подход на самом деле хорош еще тем, что позволит использовать твою dll из других языков программирования. Если интерфейс оформлен в стиле С или как какой-нибудь COM, то это сильно облегчает задачу такого использования. Если же ты будешь требовать ключей /MD от клиентской части и от dll при сборке, и явного вызова delete на клиенте (exe), то намертво приколотишь свое решение не только к языку, но и к конкретной версии С++ runtime.

1

Сообщение от DrOffset не может быть освобождена с использованием другой.

Стоп, но использовать то я могу... верно?
1. Создал в DLL объект
2. Передал указатель на него в ЕХЕ
3. Там по этому указателю вызвал функцию этого объекта.

Я не могу удалять, т.к. объект был создан другой глобальной структурой , да ? Интересно, а как они в памяти называются, индекс же должен быть какой - то? Ну типа MY_EXE_GLOBAL_MEMORY_STRUCT_1 и MY_EXE_GLOBAL_MEMORY_STRUCT_2 ? )))))))

Добавлено через 58 секунд

Сообщение от DrOffset то намертво приколотишь свое решение не только к языку, но и к конкретной версии С++ runtime.

это понял - так делать не буду

0

Сообщение от -THE_MASTER666- Стоп, но использовать то я могу... верно?

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

1

Сообщение от DrOffset MS уже давно озаботились и придумали COM

Не..Я буду использовать Qt и

Сообщение от DrOffset Более того, этот подход на самом деле хорош еще тем, что позволит использовать твою dll из других языков программирования. Если интерфейс оформлен в стиле С или как какой-нибудь COM, то это сильно облегчает задачу такого использования. Если же ты будешь требовать ключей /MD от клиентской части и от dll при сборке, и явного вызова delete на клиенте (exe), то намертво приколотишь свое решение не только к языку, но и к конкретной версии С++ runtime.

Всем спасибо ещё раз !

0