Умные указатели

_Proxy_

New Member
Кто прошареный в них, boots::scoped_ptr скажите пожалуйста это получается как примерно сборщик мусора в Java?
 

TraNceR

Member
Нет со всем по другому. По простому в с++ если обьект выходит из поля видимости, то вызывается его деструктор, в деструкторе умного указателя происходит какраз и delete указателя которым он владеет.
можно сделать например так:
void main(){
A *a = new A();// A - какойто класс
//.... тут чтото делаем

delete a;// а вдруг у нас несколько точек выхода из функции, или там где мы чтото делали мы бросили исключение, все , утечка, попадос :)
}

2ой вариант:
void main(){
scoped_ptr<A> a(new A());
//.... тут чтото делаем
// и опа нигде не нада руками удалять обьект - ПРОФИТ!
}

Это на случай если у нас локальный временный указатель который мы некуда не отдаем и его нельзя копировать, в других случаях чаще всего используется укзаатели со счетчиком ссылок, например shared_ptr, в нем еще хранится количество ссылок на данный обьект, и когда оноравно 0, только тогда delete делаем.
Это в двух словах без кучи ньюансов, вот шаред_птр можно с натяжкой чтото типа сборщика мусора как в джава назвать.
 

_Proxy_

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

Hamster

Well-Known Member
В Java нет указателей. Если на объект нет ни одной ссылки, то когда-нибудь он будет удален.
 

TraNceR

Member
_Proxy_, ну ты отличия scoped_ptr от shared_ptr понял?
Да вообще первые реализации а может и сейчас сборщиков мусора основывались какраз на подсчете ссылок (шаред_птре). Естественно есть ньюансы с нахождением зацикливаний, когда обьекты друг на друга имеют умный указатель и поулчаются некогда не умирают. В С++ это разруливается руками используя еще weak_ptr.
ЧТо бы реализовать примитивный сборщик мусора на с++ тебе необходимо както разруливтаь эти обьекты с циклическими ссылками друг на друга.
 

_Proxy_

New Member
на сколько я понял разница состоит лишь в том что shared_ptr хранит еще количество ссылающихся на обьект который он хранит, тоесть у нас есть обьект а на него ссылаються два указателя что бы удалить обьект нужно так сказать удалить эти 2 указателя, тоесть что бы они указывали на нул, чтото в этом роде, я верно понял?
 

_Proxy_

New Member
Hamster, помоему вы немного не правы, в яве есть они только в неявном виде, короче говоря программисту к ним доступ не дан
 

_Proxy_

New Member
обьясните пожалуйста правильно ли я понимаю... вот есть некий класс А в конструкторе которого выделяеться память

void f() {
A a();
....
} тут после окончания блока вызывается деструктор объекта а( потому что сам объект а был занесен в стек а потом изъятый по окончанию блока) и в деструкторе освобождается память занятая внутри объекта а. то есть для локальных объектов явно вызывать деструктор?

void f() {
A *a = new A();
...
} тут же получается объект а розмещается в кучу, а если мы его разместили в куче то должны самостоятельно от туда удалить, верно? то есть через делет, если не юзали делет получаеться после окончания блока, ссылка на объект теряться и внутри объекта память не освобождается?

ну а если мы использует scoped_ptr
void f() {
scoped_ptr<A> p(new A());
...
} То этот обьект(указатель) scoped_ptr шарит что после окончания блока нужно вызвать конструктор обьекта на который он указывает, или свой деструктор в которому вызывается деструктор объекта а тут я не пойму(обьясните) ну суть такова что обьект класса А тоже удаляеться, хотя явным образом мы его не удаляли?
и еще одно
А* f() {
scoped_ptr<A> p(new A());
.......
return p.get();
}то все будет нормально? мне кажется что он вернет фигню, ибо удалил обьект
 

TraNceR

Member
_Proxy_, Именно все верно.
Вообще очень плохая идея мешать туда сюда умные и обычные указатели таким способом, тут и shared_ptr не поможет. И будет плохо.

Так что лучшая идея с указателями которые никуда не вылазят внутри функций- scoped_ptr, в глобальных указателях которыедолго живут и много где нужны - shared_ptr, если выходит что оба класса используют другдруга то определяешься кто изних главный,и 2ой на него с weak_ptr указывает.

Т.е. внутри области видимости делай p.get(), если там есть функция которая его использует, указатель только использует.
 

_Proxy_

New Member
что то последнее предложение не понял. И на счет удаление умного указателя объясните, то есть сначала деструктор умного указателя а потом деструктор обьекта которого он хранит? вот я ради интереса для себя решил реализовать простенький умный указатель но так и не понял как вызвать деструктор обьекта на которого он хранит адрес, он же только адрес хранит он же не шарит про то что там внутри обьекта ... начал реализовывать через шаблоны
 
Зверху