Интересует такой вопрос:
Допустим хочу использовать механизм подсчета ссылок для недопущения утечек памяти.
Есть Add() и Relese() соответсвенно в базовом классе отслеживаемых объектов.Но Relese() как я понимаю
содержит в себе выражение delete this при обнулившемся кол-ве ссылок. Вот,допустим я где-то
передаю свой объект на хранение в другой объект. Для передаваемого объекта ссылка увеличилась. Но при этом
передаваемый объект был создан не в хипе(те не через new). Далее я выплевываю из хранилища объект и уменьшаю
кол-во ссылок в нем(это в relese дклается) — была 1 стало ноль,ага,ссылок ноль — delete this..пипец,объек-то не в хипе создан...Тк заранее я не могу знать как буду передавать объекты то возникает непонятная ситуация.
Конечно,все объекты можно через new создавать и не парится,но вдруг "кто-то" не через нью создаст,а механизм подсчета уже присутствует.

Здравствуйте, Аноним, Вы писали:

А>Конечно,все объекты можно через new создавать и не парится,но вдруг "кто-то" не через нью создаст,а механизм подсчета уже присутствует.

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

Здравствуйте, Аноним, Вы писали:

А>Интересует такой вопрос:
А>Допустим хочу использовать механизм подсчета ссылок для недопущения утечек памяти.
А>Есть Add() и Relese() соответсвенно в базовом классе отслеживаемых объектов.Но Relese() как я понимаю
А>содержит в себе выражение delete this при обнулившемся кол-ве ссылок. Вот,допустим я где-то
А>передаю свой объект на хранение в другой объект. Для передаваемого объекта ссылка увеличилась. Но при этом
А>передаваемый объект был создан не в хипе(те не через new). Далее я выплевываю из хранилища объект и уменьшаю
А>кол-во ссылок в нем(это в relese дклается) — была 1 стало ноль,ага,ссылок ноль — delete this..пипец,объек-то не в хипе создан...Тк заранее я не могу знать как буду передавать объекты то возникает непонятная ситуация.
А>Конечно,все объекты можно через new создавать и не парится,но вдруг "кто-то" не через нью создаст,а механизм подсчета уже присутствует.

надо передавать функтор, который будет производить удаление. В случае созлания объекта на стеке, надо передавать функтор ничего не делающий.
Реализацию можно посмотреть в boost::shared_ptr

Здравствуйте, Аноним, Вы писали:

А>Конечно,все объекты можно через new создавать и не парится,но вдруг "кто-то" не через нью создаст,а механизм подсчета уже присутствует.

Начать можно с запрещения создания объекта не в куче — делаем конструкторы и деструктор protected, а дальше —

class derived : public base
{
protected:
  //
  // Чтобы можно было наследоваться
  derived(void);
  ~derived(void);
public:
  //
  // Вот с помошью этой функции клиенты и будут создавать объекты класса
  static smart_ptr<derived> create_instance(void)
  { return smart_ptr<derived>(new derived()); }
};

Дальше спрашиваем: зачем нам это надо?

Допустим хочу использовать механизм подсчета ссылок для недопущения утечек памяти. Есть Add() и Relese() соответсвенно в базовом классе отслеживаемых объектов.

В программизме на C++ и без того мелочей всяких хватает, а если вы еще и будете сами за ссылками следить, так ваапсче свихнетесь. Оно вам надобно? Могу поспорить, что нет. А посему используйте проверенный (не)интрузивный умный указатель и занимайтесь более важными делами.

Но если же вы все же хотите сами управлять всеми ссылками, то лучше воспользуйтесь каким-нибудь гибко настраиваемым умным указателем (типа boost::shared_ptr с его deleter'ом, но только тсссс!) или же (если Бюст не нужен) посмотреть в Loki и там почерпнуть вдохновения (либо сразу код) для создания самопального велосипеда под девизом "Policy-Based Smart Pointer в массы!" (без иронии). Настоятельно рекомендуется прочесть соответствующую главу Александреску.