Применение Windows API

 protected: SIfacePtr () : _p (0) {}

 void Free () {

  if (_p != 0) _p->Release();

 _p = 0;

 }

 T * _p;

private:

 SIfacePtr(SIfacePtr const& p) {}

 void operator=(SIfacePtr const& p) {}

};

Не волнуйте, что этот класс выглядит непригодным (потому что имеет защищенный конструктор). Мы никогда не будем использовать его непосредственно. Мы наследуем от него. Между прочим, это удобный прием: создайте класс с защищенным пустым конструктором, и осуществите наследование от него. Все наследующие классы должны обеспечивать их внутреннюю реализацию своими открытыми конструкторами. Поскольку Вы можете иметь различные классы, наследующие от SIfacePtr, они будут отличаться по способу получения, по их конструкторам, рассматриваемым интерфейсам.

Закрытые фиктивный копирующий конструктор и оператор "=" не всегда необходимы, но они сохранят Вам время, потраченное на отладку, если по ошибке вы передадите интеллектуальный интерфейс по значению вместо передачи по ссылке. Это больше невозможно. Вы можете освободить один и тот же интерфейс, дважды и это будет круто отражаться на подсчете ссылок COM. Верьте мне, у меня это случалось. Как это часто бывает, компилятор откажется передавать по значению объект, который имеет закрытую копию конструктора. Он также выдаст ошибку, когда Вы пробуете присвоить объект, который имеет закрытый оператор присваивания.

Для завершения этого короткого введения, позвольте мне представить еще одну вариацию на тему интеллектуальных указателей. Оболочки API часто распределяет память, используя свои собственные специальные программы распределения. Это не было бы настолько плохо, если бы не предположение, что они ожидают от вас освобождения памяти с использованием той же самой программы распределения. Так, всякий раз, когда оболочка вручает нам такой сомнительный пакет, мы обворачиваем его в специальный интеллектуальный указатель.

template class

SShellPtr {

public:

 ~SShellPtr() {

  Free();

  _malloc->Release();

 }

 T* weak operator->() { return _p; }

 T const* operator->() const { return _p; }

 operator T const* () const { return _p; }

 T const& GetAccess () const { return *_p; }

protected:

 SShellPtr() : _p(0) {

  // Obtain malloc here, rather than

  // in the destructor.

  // Destructor must be fail-proof.

  // Revisit: Would static IMalloc * _shellMalloc work?

  if (SHGetMalloc(&_malloc) == E_FAIL) throw Exception "Couldn't obtain Shell Malloc";

 }

 void Free() {

  if (_p != 0) _malloc->Free(_p);

 _p = 0;

 }

 T * _p;

 IMalloc* _malloc;

private:

 SShellPtr(SShellPtr const& p) {}

 void operator=(SShellPtr const & p) {}

};

Обратите внимание на использование ранее показанного приема: класс SShellPtr непосредственно не пригоден для использования. Вы должны наследовать от него подкласс и реализовать в нем соответствующий конструктор.

Обратите также внимание, что я не уверен, может ли _shellMalloc быть статическим элементом SShellPtr. Проблема состоит в том, что статические элементы инициализируются перед WinMain. Из-за этого вся COM система может оказаться неустойчивой. С другой стороны, документация говорит, что Вы можете безопасно вызывать из другой API функции CoGetMalloc перед обращением к CoInitialize. Это не говорит о том, может ли SHGetMalloc, который делает почти то же самое, также вызываться в любое время в вашей программе. Подобно многим других случаям, когда система ужасно разработана или задокументирована, только эксперимент может ответить на такие вопросы. Добро пожаловать к нам с такими ответами.

Между прочим, если Вы нуждаетесь в интеллектуальном указателе, который использует специфическое распределение памяти для COM, то получите его, вызывая CoGetMalloc. Вы можете без опаски сделать этот _malloc статическим элементом и инициализировать его только один раз в вашей программе (ниже SComMalloc::GetMalloc тоже статический):

IMalloc* SComMalloc::_malloc = SComMalloc::GetMalloc();

IMalloc* SComMalloc::GetMalloc() {

 IMalloc* malloc = 0;

 if (CoGetMalloc(1, &malloc) == S_OK) return malloc;

 else return 0;

}