безопасность программ с++

[Пепел Феникса]

ну тогда да, все верно.

[Granus]

delete сам вызывает деструктор удаляемого объекта, так что будет бесконечная рекурсия.

[SAMOUCHKA]

Может я не правильно понимаю синтаксис с++? Но как я понимаю this, это указатель на объект. Так вот нам и надо освободить память по этому адресу.

существования this не значит что память освобождаемая.

Но как вы говорите выходит все не так просто.

Я это к тому-что, если в программе объекты будут создаватся только динамически. Можно-ли написать такой класс, чтобы сам освобождал память от своих объектов?

[Пепел Феникса]

smart ptr всякие например.
да и метод посерил-подтер вполне достаточен.

[waleri]

Сообщение от SAMOUCHKA

Можно-ли написать такой класс, чтобы сам освобождал память от своих объектов?

Можно. Вопрос в одном - в какой момент времени это делать?

[_Bers]

Сообщение от SAMOUCHKA

Может я не правильно понимаю синтаксис с++? Но как я понимаю this, это указатель на объект. Так вот нам и надо освободить память по этому адресу.

Пример:

int main()
{
    Some obj; //создан на стеке. Его this нельзя прибивать
}

Сообщение от SAMOUCHKA

Я это к тому-что, если в программе объекты будут создаватся только динамически. Можно-ли написать такой класс, чтобы сам освобождал память от своих объектов?

Пример:

int main()
{
    Some* ptr = new Some(); //создан в динамической памяти
}

Здесь у тебя были созданы сразу две сущности:
1. Собственно объект в динамической памяти.
2. Указатель на этот объект на стеке (локальный).

Ну так вот, когда закончится область видимости указателя, то он сдохнет.
У этого указателя нет диструктора, который запустит delete объекту, на который он смотрит. Поэтому, когда указатель помрет, объект так и останется в куче.

Если ты сделаешь вот так:

int main()
{
    Some* ptr = new Some(); //создан в динамической памяти
    ptr-> ~Some(); //запуск дисктрутора объекта
}

То у объекта запустится его диструктор. Теоретически, диструктор вполне реально написать так, что бы объект пригрохал самого себя.

Однако: это будет то, что ещё называют: "на первый этаж через чердак".
Кроме того, подобные выкрутасы не имеют никаких приимуществ по сравнению со стандартным:

int main()
{
    Some* ptr = new Some(); //создан в динамической памяти

    delete ptr;  //вот такую запись сможет понять любой программист
}

В обоих случаях, тебе придется ручками запускать функцию. В первом случае - диструктор объекта. А во втором - оператор delete.

Только во втором случае запись проще, понятнее, привычнее.

А первый случай - это тернистая дорожка, которая в итоге опять таки вызовет delete
Ну и смысл тогда?

[Abstraction]

Может я не правильно понимаю синтаксис с++? Но как я понимаю this, это указатель на объект. Так вот нам и надо освободить память по этому адресу.

Надо. Только это обычно не компетенция объекта - решать, пора ему умирать или нет.

Можно-ли написать такой класс, чтобы сам освобождал память от своих объектов?

Теоретически можно. Практически - почти наверняка бессмысленно. Класс - это такой чёрный ящик, который "дёргают" снаружи, вызывая его методы - и только в эти моменты код класса получает управление. Внимание, вопрос: как мы, в классе, должны понять, что вот по завершении этого метода нам пора дохнуть? Или этот метод вызывается тогда и только тогда, когда нам пора дохнуть (и тогда его код можно перенести в деструктор, а вызывающему коду вместо вызова этого метода посоветовать делать delete), или у нас в классе есть методы, по завершении вызова которых объект то ли будет существовать, то ли нет, что лично я никак не могу назвать безопасной практикой.

[Perchik71]

он наоборот крякнуть хочет.
но только он не так это мыслит... мало инфы по этому вопросу.
а тут ему не дадут знаний.
А объект сам должен заниматься своими делами... и лишь мы как начальник, решаем уволить или он ещё нужен, а может вместо него нам ещё кого то.. объект сам не может это решать. ну если только сообщит о своём намериньи и только. а в его случаи это не логично и нет даже в жизни. поэтому это приведёт только к аварийному завершению проги.

[Abstraction]

он наоборот крякнуть хочет.

Ну, по заглавному посту совет простой: Солдатова в руки и написать что-нибудь из серии "никогда так не делайте", типа обращения к страничной памяти на IRQL>1 - будет ему синий экран.

[SAMOUCHKA]

Сообщение от Abstraction

Ну, по заглавному посту совет простой: Солдатова в руки и написать что-нибудь из серии "никогда так не делайте", типа обращения к страничной памяти на IRQL>1 - будет ему синий экран.

Я уже писал, выше, "я не хочу писать кривые программы".

Цитата:
Сообщение от SAMOUCHKA
Можно-ли написать такой класс, чтобы сам освобождал память от своих объектов?
Можно. Вопрос в одном - в какой момент времени это делать?

void func()
{
myClass *o1 = new myClass() // создаем объект
//..
} // все, тут объект больше не нужен

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