Как инкапсулировать C API в классы RAII C++?

Добавив еще один слой (и сделав свой RAII немного более явным), вы можете получить что-то довольно аккуратное. Конструкторы копирования по умолчанию и назначение для сеансов и элементов делают правильную вещь. HANDLE для сеанса будет закрыт после закрытия HANDLE для всех элементов. Нет необходимости хранить векторы детей, общие указатели отслеживают все это за вас ... Так что я думаю, что он должен делать все, что вам нужно.

class SessionHandle
{
   explicit SessionHandle( HANDLE in_h ) : h(in_h) {}
   HANDLE h;
   ~SessionHandle() { if(h) CloseSession(h); }
};

class ItemHandle
{
   explicit ItemHandle( HANDLE in_h ) : h(in_h) {}
   HANDLE h;
   ~ItemHandle() { if(h) CloseItem(h); }
};

class Session
{
   explicit Session( STRING sessionID ) : session_handle( OpenSession(sessionID) )
   {
   }
   shared_ptr<SessionHandle> session_handle;
};

class Item
{
   Item( Session & s, STRING itemID ) : 
     item_handle( OpenItem(s.session_handle.get(), itemID ) ), 
     session_handle( s.session_handle )
   {
   }
   shared_ptr<ItemHandle> item_handle;
   shared_ptr<SessionHandle> session_handle;
};

Это интересная проблема, я думаю.

Прежде всего, для RAII вы обычно хотите реализовать конструктор копирования и оператор присваивания в целом, здесь HANDLE const помешал бы им, но вам действительно нужны объекты, которые нельзя копировать? И лучше сделать их безопасными для исключений.

Кроме того, есть проблема id: вы должны обеспечить уникальность или фреймворк сделает это за вас?

ИЗМЕНИТЬ:

Требования были уточнены с момента моего первого ответа, а именно:

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

В этом случае у вас есть два варианта дизайна:

• Используйте шаблон Observer: Item связывается обратно с Session, с которым он был создан, Session уведомляет его, когда он умирает (при использовании диспетчера сеансов это автоматизируется тем, что диспетчер сеансов владеет сеансом, а Item запрашивает менеджера о его сеанс)
• Используйте схему @Michael, в которой Item совместно владеют объектом Session, чтобы Session нельзя было уничтожить, пока существует хотя бы один Item.

Мне не очень нравится второе решение, потому что время жизни Session гораздо сложнее отследить: вы не можете надежно убить его.

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

Старое решение:

Что касается фактического дизайна, я бы предложил:

class Item
{
public:
  Item(): mHandle() {}

  Item(Session& session, std::string id): mHandle(session.CreateItem(id))
  {
  }

  void swap(Item& rhs)
  {
    using std::swap;
    swap(mHandle, rhs.mHandle);
  }

  void reset()
  {
    mHandle.reset();
  }

  /// Defensive Programming
  void do()
  {
    assert(mHandle.exists() && "do - no item");
    // do
  }

private:
  boost::weak_ptr<HANDLE const> mHandle;
};

И класс сеанса

class Session
{
public:

private:
  typedef boost::weak_ptr<HANDLE const> weak_ptr;
  typedef boost::shared_ptr<HANDLE const> shared_ptr;
  typedef boost::unordered_map<std::string, shared_ptr> map_type;

  friend class Item;
  struct ItemDeleter
  {
    void operator()(HANDLE const* p) { CloseItem(*p); }
  };

  weak_ptr CreateItem(std::string const& id)
  {
    map_type::iterator it = mItems.find(id);
    if (it != mItems.end()) return it->second;

    shared_ptr p = shared_ptr(new OpenItem(mHandle, id), ItemDeleter());
    std::pair<map_type::iterator, bool> result =
      mItems(std::make_pair(id, p));

    return result.first->second;
  }

  map_type mItems;
  HANDLE const mHandle;
};

Это передает значение, которое вы просили:

• Объект Session отвечает за управление временем жизни Items, фактический объект Item является не более чем прокси для дескриптора.
• У вас есть детерминированное время жизни ваших объектов: всякий раз, когда Session умирает, все элементы HANDLE to закрываются.

Тонкие проблемы: этот код небезопасен в многопоточном приложении, но тогда я понятия не имею, нужно ли нам полностью сериализовать доступ к OpenItem и CloseItem, поскольку я не знаю, является ли базовая библиотека потокобезопасной.

Обратите внимание, что в этом дизайне объект Session нельзя скопировать. Очевидно, мы могли бы создать объект SessionManager (обычно одноэлементный, но это не обязательно) и заставить его управлять Session точно так же :)

Чтобы расширить комментарий STLSoft, используйте 1scoped__handle.html" rel="nofollow">scoped_handle умный указатель, например:

HANDLE hSession = OpenSession("session-X");
if(!hSession) {
 // Handle failure to open session
}
else {
  stlsoft::scoped_handle<HANDLE> session_release(hSession, CloseSession);

  HANDLE hItem = OpenItem(hSession, "item-Y");
  if(!hItem) {
     // Handle failure to open item
  }
  else {
      stlsoft::scoped_handle<HANDLE> item_release(hItem, CloseItem);

    // Use item
  }
}

Если значение дескриптора «null» не равно 0, сделайте что-то вроде:

if(hSession != -1) {
 // Handle failure to open session
}
else {
  stlsoft::scoped_handle<HANDLE> session_release(hSession, CloseSession, -1);

ХТН

Используйте shared_ptr: http://www.boost.org/doc/libs/1_44_0/libs/smart_ptr/sp_techniques.html#handle