S>Одно условие уже назвали выше. S>Добавлю, что объект должен быть создан динамически, т.е. с помощью new
Ясно.
Объекты создаются динамически (new) фабрикой, фабрика в одной dll, созданные объекты используются в другой. "delete obj" вызывать из другой dll я по понятным причинам не могу, поэтому решил так делать.
BP>Объекты создаются динамически (new) фабрикой, фабрика в одной dll, созданные объекты используются в другой. "delete obj" вызывать из другой dll я по понятным причинам не могу, поэтому решил так делать.
В этом случае лучше чтоб фабрика возвращала умный указатель, который бы сам всё подчищал
Здравствуйте, gid_vvp, Вы писали:
BP>>Объекты создаются динамически (new) фабрикой, фабрика в одной dll, созданные объекты используются в другой. "delete obj" вызывать из другой dll я по понятным причинам не могу, поэтому решил так делать.
_>В этом случае лучше чтоб фабрика возвращала умный указатель, который бы сам всё подчищал
К сожалению, "умных" указателей нужно более одной разновидности, и дублировать их для каждого объекта не всегда удобно. Альтернативой, не закрывающей возможность использования разнообразных способов удаления объектов класса, "торчащего" из DLL, может быть снабжение его собственными operator new/delete, реализованными в этой же DLL.
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, BoberPlus, Вы писали:
BP>Ясно.
BP>Объекты создаются динамически (new) фабрикой, фабрика в одной dll, созданные объекты используются в другой. "delete obj" вызывать из другой dll я по понятным причинам не могу, поэтому решил так делать.
Используя виртуальный декструктор все проблемы уходят. Рекомендую попробовать.
Здравствуйте, minorlogic, Вы писали:
M>Используя виртуальный декструктор все проблемы уходят. Рекомендую попробовать.
Даже статическая линковка рантайма?
Здравствуйте, LuciferMoscow, Вы писали:
LM>Здравствуйте, minorlogic, Вы писали:
M>>Используя виртуальный декструктор все проблемы уходят. Рекомендую попробовать. LM>Даже статическая линковка рантайма?
Здравствуйте, minorlogic, Вы писали:
M>>>Используя виртуальный декструктор все проблемы уходят. Рекомендую попробовать. LM>>Даже статическая линковка рантайма? M>Не очень понял о чем это. Можно на примере ?
Примерно об этом http://rsdn.ru/article/cpp/stlproblem.xml
Здравствуйте, LuciferMoscow, Вы писали:
LM>Здравствуйте, minorlogic, Вы писали:
M>>>>Используя виртуальный декструктор все проблемы уходят. Рекомендую попробовать. LM>>>Даже статическая линковка рантайма? M>>Не очень понял о чем это. Можно на примере ? LM>Примерно об этом http://rsdn.ru/article/cpp/stlproblem.xml
Здравствуйте, minorlogic, Вы писали:
M>>>>>Используя виртуальный декструктор все проблемы уходят. Рекомендую попробовать. LM>>>>Даже статическая линковка рантайма? M>>>Не очень понял о чем это. Можно на примере ? LM>>Примерно об этом http://rsdn.ru/article/cpp/stlproblem.xml
Здравствуйте, LuciferMoscow, Вы писали:
LM>Здравствуйте, minorlogic, Вы писали:
M>>>>>>Используя виртуальный декструктор все проблемы уходят. Рекомендую попробовать. LM>>>>>Даже статическая линковка рантайма? M>>>>Не очень понял о чем это. Можно на примере ? LM>>>Примерно об этом http://rsdn.ru/article/cpp/stlproblem.xml
M>>А при чем тут это ? Если деструктор виртуальный , он пользуется РОДНЫМ менеджером памяти , в этом то и смысл. LM>Кто-то это может подтвердить?
Например тест.
Стандарт.
Здравый смысл.
Деструкто то вызывается виртуальный через виртуальный вызов, и данной точке компилятор просто банально не знает размера удаляемого объекта. А знает его только в том модуле где перегружен деструктор для реального объекта.
Здравствуйте, minorlogic, Вы писали:
M>Например тест. M>Стандарт. M>Здравый смысл. M>Деструкто то вызывается виртуальный через виртуальный вызов, и данной точке компилятор просто банально не знает размера удаляемого объекта. А знает его только в том модуле где перегружен деструктор для реального объекта.
там(статическая линковка) проблема совсем не в размере объекта и освобождение памяти вызывается ПОСЛЕ отработки ВСЕХ деструкторов
Здравствуйте, LuciferMoscow, Вы писали:
LM>Здравствуйте, minorlogic, Вы писали:
M>>Например тест. M>>Стандарт. M>>Здравый смысл. M>>Деструкто то вызывается виртуальный через виртуальный вызов, и данной точке компилятор просто банально не знает размера удаляемого объекта. А знает его только в том модуле где перегружен деструктор для реального объекта. LM>там(статическая линковка) проблема совсем не в размере объекта и освобождение памяти вызывается ПОСЛЕ отработки ВСЕХ деструкторов
Поробую на пальцах , к нам в модуль, независимо с какой линковкой пришел указатель на Base (Base*). Как компилятор этого модуля узнает скольно нужно удалить памяти , если деструктор виртуальный ? а если мы удаляем объект наследника с большим размером ?
Здравствуйте, minorlogic, Вы писали:
LM>>там(статическая линковка) проблема совсем не в размере объекта и освобождение памяти вызывается ПОСЛЕ отработки ВСЕХ деструкторов M>Поробую на пальцах , к нам в модуль, независимо с какой линковкой пришел указатель на Base (Base*). Как компилятор этого модуля узнает скольно нужно удалить памяти , если деструктор виртуальный ? а если мы удаляем объект наследника с большим размером ?
Сколько памяти нужно освободить может знать runtime-library, например, она может писать по адресу this-X объем выделенной памяти
Здравствуйте, minorlogic, Вы писали:
M>Здравствуйте, LuciferMoscow, Вы писали:
LM>>Здравствуйте, minorlogic, Вы писали:
M>>>Например тест. M>>>Стандарт. M>>>Здравый смысл. M>>>Деструкто то вызывается виртуальный через виртуальный вызов, и данной точке компилятор просто банально не знает размера удаляемого объекта. А знает его только в том модуле где перегружен деструктор для реального объекта. LM>>там(статическая линковка) проблема совсем не в размере объекта и освобождение памяти вызывается ПОСЛЕ отработки ВСЕХ деструкторов
M>Поробую на пальцах , к нам в модуль, независимо с какой линковкой пришел указатель на Base (Base*). Как компилятор этого модуля узнает скольно нужно удалить памяти , если деструктор виртуальный ? а если мы удаляем объект наследника с большим размером ?
ok, я тоже на пальцах
Память осбобождает не деструктор, а менеджер памяти. Ему (менеджеру) на$рать что в этой памяти хранится — объект или набор байт, например.
Здравствуйте, BoberPlus, Вы писали:
BP>Память осбобождает не деструктор, а менеджер памяти. Ему (менеджеру) на$рать что в этой памяти хранится — объект или набор байт, например.
Имеет значение КАКОЙ из мнеджеров памяти удаляет объект. Я предпочитаю , чтобы тот же который и выделил эту память. Но если тебе все равно ....
Здравствуйте, minorlogic, Вы писали:
M>Здравствуйте, BoberPlus, Вы писали:
BP>>Память осбобождает не деструктор, а менеджер памяти. Ему (менеджеру) на$рать что в этой памяти хранится — объект или набор байт, например.
M>Имеет значение КАКОЙ из мнеджеров памяти удаляет объект. Я предпочитаю , чтобы тот же который и выделил эту память. Но если тебе все равно ....
Исчо раз
Менеджер памяти не может освобождать память, которую он не выделял.
Если линковка с рантаймом статическая (по умолчанию это так), то каждый dll будет иметь свой менеджер памяти, поэтому нельзя делать "delete obj", если obj был создан в другом модуле.