Есть класс, который генерит древовидную структуру используя обычные указателями. Структура довольно сложная и громоздкая, я боюсь где-то могу забыть прописать удаление указателя в деструкторе класса. Посему назрела мысль использовать "умников-стрелочников". Но насколько я понял пободные смартпоинтеры действуют по принципу - вышли из области видимости - сработал деструктор и сами удалились. Но у меня ситуация такая, в конструкторе создаются указатели, но при выходе из конструктора они должны остаться валидными и удалиться только в деструкторе моего класса. Как в таком случае применить смарт-поинтеры если их участь - подохнуть точно также как локальный объект созданный во временном стеке, теряется смысл ?

Всё зависит от типа умного указателя. Далеко не все общедоступные реализации "умирают" при выходе из области видимости. Например boost::shared_ptr

Уж очень не хочется использовать boost в своей программе. К тому же я так понимаю если указатель даже и shared, то компилятор сам ну ни как не определит в какой момент мне нужно удалять его, пока я вручную не задам аналог delete в нужном месте. А это опять же сводит на нет мою идею.

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

Это сообщение отредактировал(а) Dreamer_0x01 - 14.4.2008, 18:16

религия не позволяет? 

не правильно понимаешь, когда кол-во ссылок на объект станет равным 0, тогда память будет освобождена.

Нельзя, они динамические. Зависит от количества записей в базе данных. И содержит все эти указатели вектор, который является членом класса.


Скорее не религия, а поговорка о пушках и воробьях.



А пример можно ?  

Это сообщение отредактировал(а) SABROG - 14.4.2008, 18:22

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

А как это сработает в таком виде:

//псевдо-код


Когда поинтеры убьются, когда убьется otherClass или вызовется delete для A ?

Boost  Smart Pointer является совершенно самостоятельной библиотекой и даже не требует связывания на этапе линковки (вся функциональность содержится в заголовочных файлах)
Это к вопросу о пушках.

Можно использовать ּSTL-овские контейнеры. Только в них не заносить сами указатели, а записи. Что то типа такого


Тогда уже сам контейнер будет заботится об удалении записей.

Если ты создашь вектор auto_ptr'ов, то последующий занесенный auto_ptr будет копироатся из конструктора в список. А при копировании auto_ptr класс источник теряет ссылку. Так что выйдя з апределы конструктора ты ничего не потеряешь ибо вызовется деструктор у класса указатель из которого уже извлечен.
Т.е. при копировании из одного auto_ptr в другой ты не получишь 2 ссылки на auto_ptr. В таком случае только последний классс будет иметть реально ссылку которую прибьет в деструкторе. Короче кто последний влез, того и тапки.

Добавлено через 59 секунд
Fin, ага. И туда можно вогнать auto_ptr

что то я не совсем понял твой псевдокод 

не, shared_ptr - это уже указатель (по крайней мере, по смыслу), так что достаточно list<shared_ptr>

Это сообщение отредактировал(а) maxim1000 - 14.4.2008, 20:20

... в программе очень скоро начнутся проблемы 
Подробности почему - читать в книгах зубров (Мейерс/Саттер)

Добавлено через 58 секунд
PS. собственно, ты дальше сам рассказал почему.

Т.е. если вместо указателей запхнуть в контейнер auto_ptr'ы, то при удалении контейнера для каждого из объекта auto_ptr'a вызовется деструктор и освобождение памяти ?

кстати вполне возможно, что этот не скомпилируется.

Кстати да, возможно. 

Так оно и есть:





А с shared_ptr тоже самое будет ?

Это сообщение отредактировал(а) SABROG - 14.4.2008, 21:16

SABROG, auto_ptr нельзя использовать в контейнерах. Просто работа с контейнерами подразумевает нормальную логику работы оператора присваивания и конструктора копирования. А у auto_ptr эти функции являются перемещающими. Другими словами, auto_ptr надо использовать при возврате функцией ссылки на объект, чтобы он сам удалился когда будет не нужен, а также для хранения указателей на динамически конструируемые поля классов.
У boost::shared_ptr логика копирования классическая. Поэтому его можно хранить в контейнерах.

Что-то мне подсказывает, что выцепить shared_ptr отдельно от буста будет сложно...

//shared_ptr.hpp

Вот мой пример. Как то я для себя писал "умный указатель" который подсчитывает сам количество ссылок и если надо удаляет.

получаем 


Это сообщение отредактировал(а) Fin - 14.4.2008, 21:45

Это будет сложно только до того момента, пока ты не познакомишься с Boost BCP Utility

SABROG, а почему ты так боишься самого буста? Установи его и используй. Какие проблемы? Тем более, что вроде как этот shared_ptr в стандарт С++ должен войти, как и некоторые другие вещи из буста.

Уже познакомился, спс. Просто я скачал исходники через SVN, а этот BCP надо собирать...



А потому, что программа кроссплатформенная и возможно я буду выкладывать ее исходники и мне бы не хотелось заставлять других программистов устанавливать boost только ради того, что я использую shared_ptr...

Это сообщение отредактировал(а) SABROG - 14.4.2008, 21:51

Зачем, если не секрет? Чем тебя стабильная версия не устроила?

bsa, 
Иногда в в trunk'е появляются различные полезные классы/библиотеки которых долго ждать в релизе (как например это было с circular_buffer etc), а учитывая, насколько может затянуться релиз...

Тут речь идет о shared_ptr, которому уже 100 лет в обед.   

Я руководствовался такой логикой, раз SVN значит исходники, а раз исходники, значит можно выдрать shared_ptr и желательно последней версии, если он вообще менялся 

bsa, ну если про shared_ptr, тогда, наверное, преимуществ нет. А вообще, вотЪ 

Это сообщение отредактировал(а) Rififi - 14.4.2008, 22:04

SABROG, буст в исходниках и поставляется. Поэтому, когда хочется по быстрее установить гимор возникает - компилится сволочь долго (не всем только shared_ptr нужен)!

Похоже будет проще взять версию Fin'a (за что ему спасибо) чем лезть через терни к звездам.

Поправте меня если я не прав. Но насколько я знаю буст как раз и анонсирует то что все их классы поддерживают только стандарт С++.

буст все же стороння либа, то что содержится там не обязательно войдет в стандарт, но по крайней мере в boost tr1 содержится то что, должно быть в std::tr1

Сам то понял, что сказал?
Я тут недавно прочитал про то, зачем собственно этот буст был создан. Смысл такой, это что-то вроде бета-версии новых компонентов стандартной библиотеки С++. Далеко не все войдет в стандатр, но наиболее часто используемые вещи войдут.

Как я и думал "через терни к звездам", не собирается буст 1.35.0:



Использую mingw 3.4.5. Хотелось бы мне знать, что скрывается за этими значками вопросов....

Это сообщение отредактировал(а) SABROG - 15.4.2008, 08:39

SABROG, для shared_ptr ничего собирать не надо...
boost я использую на работе а у нас здесь к надежности софта очень высокие требования =)

Добавлено через 2 минуты и 20 секунд




питон не установлен, boost::python поэтому не собирается, все остальное собралось =)

Дело в том, что boost не имеет собранной утилиты BCP в исходниках, а она мне нужна, чтобы выцепить shared_ptr. Конечно, как вариант, можно поискать уже собранную, но я думал будет легче собрать буст "на будущее".

Вечером буду смотреть копать дальше как питон подключать, странно, что в мануале не дали ключи к bjam'у.

Замечательный пример того, что велосипедам лучше предпочесть нормальные широкоизвестные либы. Твой код просто ужасен: пользователь никак не может проверить указатель на равенство нулю, не может разыменовать и скопировать оператором присваивания константный указатель, и есть случай, когда программа из-за твоего указателя может попросту упасть. Ну и инкапсуляция тут тоже хромает (см. метод get). В топку такой класс.

Это сообщение отредактировал(а) UnrealMan - 15.4.2008, 13:13

UnrealMan, Может и в топку. Он в свое время отработал нормально и без притензий. Я никого не заставляю использовать этот класс, просто показал, что можно работать. Так что, как говорится в одной очень известной лицензии  AS IS.

Сам питон у меня стоит, вчера проверил. Может ему исходники нужны ?

Ему нужно переменную окружения создать PYTHON_PATH вроде-бы...
Если тебе не нужен boost::python, то можно и не собирать, все остальное и так уже собрано