Простой вопрос — допустима ли такая конструкция ?

void Obj::release()
{
   delete this;
}

Здравствуйте, BoberPlus, Вы писали:

BP>Простой вопрос — допустима ли такая конструкция ?

BP>

BP>void Obj::release()
BP>{
BP>   delete this;
BP>}
BP>

Допустима. Только если ты после этого использовать объект больше не будешь

Здравствуйте, BoberPlus, Вы писали:

BP>Простой вопрос — допустима ли такая конструкция ?

BP>

BP>void Obj::release()
BP>{
BP>   delete this;
BP>}
BP>

Одно условие уже назвали выше.
Добавлю, что объект должен быть создан динамически, т.е. с помощью new

Здравствуйте, Sm0ke, Вы писали:

S>Здравствуйте, BoberPlus, Вы писали:

BP>>Простой вопрос — допустима ли такая конструкция ?

BP>>

BP>>void Obj::release()
BP>>{
BP>>   delete this;
BP>>}
BP>>

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

Автор(ы): Роман Хациев
Дата: 27.02.2002
Если вы пытались работать с экземплярами классов STL, передавая их в DLL, или получая оттуда, а потом бросили это занятие из-за непонятных ошибок, возникающих в вашей программе, то эта заметка для вас. Даже если видимых проблем в вашей программе нет, то все равно прочитайте эту заметку, чтобы знать что делать, когда они появятся :)

Здравствуйте, LuciferMoscow, Вы писали:

LM>Здравствуйте, minorlogic, Вы писали:

M>>>>Используя виртуальный декструктор все проблемы уходят. Рекомендую попробовать.
LM>>>Даже статическая линковка рантайма?
M>>Не очень понял о чем это. Можно на примере ?
LM>Примерно об этом http://rsdn.ru/article/cpp/stlproblem.xml

Автор(ы): Роман Хациев
Дата: 27.02.2002
Если вы пытались работать с экземплярами классов STL, передавая их в DLL, или получая оттуда, а потом бросили это занятие из-за непонятных ошибок, возникающих в вашей программе, то эта заметка для вас. Даже если видимых проблем в вашей программе нет, то все равно прочитайте эту заметку, чтобы знать что делать, когда они появятся :)

А при чем тут это ? Если деструктор виртуальный , он пользуется РОДНЫМ менеджером памяти , в этом то и смысл.

Здравствуйте, minorlogic, Вы писали:

M>>>>>Используя виртуальный декструктор все проблемы уходят. Рекомендую попробовать.
LM>>>>Даже статическая линковка рантайма?
M>>>Не очень понял о чем это. Можно на примере ?
LM>>Примерно об этом http://rsdn.ru/article/cpp/stlproblem.xml

Автор(ы): Роман Хациев
Дата: 27.02.2002
Если вы пытались работать с экземплярами классов STL, передавая их в DLL, или получая оттуда, а потом бросили это занятие из-за непонятных ошибок, возникающих в вашей программе, то эта заметка для вас. Даже если видимых проблем в вашей программе нет, то все равно прочитайте эту заметку, чтобы знать что делать, когда они появятся :)

M>А при чем тут это ? Если деструктор виртуальный , он пользуется РОДНЫМ менеджером памяти , в этом то и смысл.
Кто-то это может подтвердить?

Здравствуйте, LuciferMoscow, Вы писали:

LM>Здравствуйте, minorlogic, Вы писали:

M>>>>>>Используя виртуальный декструктор все проблемы уходят. Рекомендую попробовать.
LM>>>>>Даже статическая линковка рантайма?
M>>>>Не очень понял о чем это. Можно на примере ?
LM>>>Примерно об этом http://rsdn.ru/article/cpp/stlproblem.xml

Автор(ы): Роман Хациев
Дата: 27.02.2002
Если вы пытались работать с экземплярами классов STL, передавая их в DLL, или получая оттуда, а потом бросили это занятие из-за непонятных ошибок, возникающих в вашей программе, то эта заметка для вас. Даже если видимых проблем в вашей программе нет, то все равно прочитайте эту заметку, чтобы знать что делать, когда они появятся :)

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 объем выделенной памяти

Здравствуйте, LuciferMoscow, Вы писали:

Мы можем спорить довольно долго , но нас отличает небольшой момент . Я на это тесты делал и вопрос уточнял, вы нет.

Здравствуйте, 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 был создан в другом модуле.