DelegatesDemo_vc7.zip
DelegatesDemo_vc6.zip

Введение

Делегаты – это объектно-ориентированные указатели на функции, используемые для callback-вызовов в среде CLR фирмы Microsoft. Делегат можно связать со статической функцией или с нестатическим методом любого класса (единственное условие – совпадение сигнатуры метода с сигнатурой, указанной в описании делегата). Затем связанную с делегатом функцию или метод можно вызывать, используя стандартный синтаксис вызова функции в C++. Несколько делегатов можно связать в цепочку. Благодаря этому можно "одним махом" вызвать все связанные с ними callback-функции. Следующий пример демонстрирует применение делегатов в языке C#.

using System;
using System.IO;

namespace CSharpDelegates
{
  class App
  {
    // Определяем делегат Callback,
    // который принимает 1 параметр и ничего не возвращает.
    public delegate void Callback(string str);

    // Это метод класса App.
    public void OutputToConsole(string str)
    {
      Console.WriteLine(str);
    }

    // А это статический метод класса App.
    public static void OutputToFile(string str)
    {
      StreamWriter sw = new StreamWriter("output.txt", true);
      sw.WriteLine(str);
      sw.Close();
    }

    public static void Main(string[] args)
    {
      App app = new App();

      // Создаём делегат.
      App.Callback callback = null;
      if(callback != null) callback("1");

      // Добавляем ссылку на OutputToFile.
      // Вызываем её через делегата.
      callback += new App.Callback(App.OutputToFile);
      if(callback != null) callback("2");

      // Добавляем ссылку на OutputToConsole.
      // Вызывается вся цепочка:
      // сначала OutputToFile, потом OutputToConsole.
      callback += new App.Callback(app.OutputToConsole);
      if(callback != null) callback("3");

      // Убираем ссылку на OutputToFile.
      // Вызывается только OutputToConsole.
      callback -= new App.Callback(App.OutputToFile);
      if(callback != null) callback("4");

      // Убираем оставшуюся ссылку на OutputToConsole.
      callback -= new App.Callback(app.OutputToConsole);
      if(callback != null) callback("5");
    }
  }
}

Делегаты в CLR удобны, типобезопасны и эффективны. Последнее время на форумах RSDN часто поднимается вопрос о том, можно ли реализовать делегаты с аналогичными свойствами, оставаясь в рамках "чистого" C++. Оказывается, это вполне возможно. В этой статье я покажу, как это сделать.

Частное решение

Для начала создадим делегат для callback-вызова функций и методов с простейшей сигнатурой void(void). Интерфейс этого делегата будет выглядеть так.

class IDelegateVoid
{
public:
  virtual ~IDelegateVoid() {}
  virtual void Invoke() = 0;
  virtual bool Compare(IDelegateVoid* pDelegate) = 0;
};

Invoke используется для вызова функции или метода, связанного с делегатом, а Compare сравнивает 2 делегата и возвращает true, если они связаны с одной и той же функцией (методом). Очевидно, что реализация интерфейса IDelegateVoid будет отличаться для статических функций и нестатических методов класса, поэтому мы разнесём эти реализации по различным классам. Класс CStaticDelegateVoid будет "отвечать" за статические функции, а класс CMethodDelegateVoid – за нестатические методы.

Класс CStaticDelegateVoid просто инкапсулирует указатель типа void (*)():

class CStaticDelegateVoid : public IDelegateVoid
{
public:
  typedef void (*PFunc)();
  CStaticDelegateVoid(PFunc pFunc) { m_pFunc = pFunc; }
  virtual void Invoke() { m_pFunc(); }
  virtual bool Compare(IDelegateVoid* pDelegate);

private:
  PFunc m_pFunc;
};

Метод Compare должен проверить, что переданный ему указатель IDelegateVoid* в действительности ссылается на объект CStaticDelegateVoid. Если это не так, делегаты различны (ссылаются на разные функции) и Compare просто возвращает false. Иначе результат определяется сравнением переменных-членов m_pFunc у двух объектов. Реализация этой идеи выглядит так.

bool CStaticDelegateVoid::Compare(IDelegateVoid *pDelegate)
{
  CStaticDelegateVoid* pStaticDel =
    dynamic_cast<CStaticDelegateVoid*>(pDelegate);

  if(pStaticDel == NULL || pStaticDel->m_pFunc != m_pFunc)
    return false;

  return true;
}

Класс CMethodDelegateVoid чуть-чуть сложнее. Он должен инкапсулировать указатель на объект и указатель на метод этого объекта. Поскольку в C++ указатели на методы двух разных классов принципиально отличаются (и могут даже иметь разный размер), нам нужна отдельная реализация CMethodDelegateVoid для каждого нового класса, на методы которого мы хотим ссылаться. Поэтому класс CMethodDelegateVoid должен быть шаблоном. В остальном его реализация аналогична CStaticDelegateVoid.

template<class TObj>
class CMethodDelegateVoid : public IDelegateVoid
{
public:
  typedef void (TObj::*PMethod)();
  CMethodDelegateVoid(TObj* pObj, PMethod pMethod)
  {
    m_pObj = pObj;
    m_pMethod = pMethod;
  }
  virtual void Invoke() { (m_pObj->*m_pMethod)(); }
  virtual bool Compare(IDelegateVoid* pDelegate);

private:
  TObj *m_pObj;
  PMethod m_pMethod;
};

template<class TObj>
bool CMethodDelegateVoid<TObj>::Compare(IDelegateVoid* pDelegate)
{
  CMethodDelegateVoid<TObj>* pMethodDel =
    dynamic_cast<CMethodDelegateVoid<TObj>* >(pDelegate);

  if
  (
    pMethodDel == NULL ||
    pMethodDel->m_pObj != m_pObj ||
    pMethodDel->m_pMethod != m_pMethod
  )
    return false;

  return true;
}

Классы CStaticDelegateVoid и CMethodDelegateVoid можно использовать непосредственно. Но для пользователя удобнее работать исключительно с интерфейсом IDelegateVoid, не задумываясь о существовании двух различных классов реализации. Поэтому напишем перегруженную функцию NewDelegate, которая будет создавать нужный объект и возвращать пользователю IDelegateVoid*. Её реализация будет выглядеть так:

IDelegateVoid* NewDelegate(void (*pFunc)())
{
  return new CStaticDelegateVoid(pFunc);
}

template <class TObj>
IDelegateVoid* NewDelegate(TObj* pObj, void (TObj::*pMethod)())
{
  return new CMethodDelegateVoid<TObj> (pObj, pMethod);
}

Мы уже почти закончили. Осталось написать объектную обёртку над интерфейсом IDelegateVoid, которая будет поддерживать список указателей и определять набор операторов, аналогичных используемым в C# - operator=, operator(), operator+= и operator-=. Для простоты будем использовать стандартный класс std::list для хранения списка указателей.

#include <list>

class CDelegateVoid
{
public:
  CDelegateVoid(IDelegateVoid* pDelegate = NULL) { Add(pDelegate); }
  ~CDelegateVoid() { RemoveAll(); }
  bool IsNull() { return (m_DelegateList.size() == 0); }

  CDelegateVoid& operator=(IDelegateVoid* pDelegate)
  {
    RemoveAll();
    Add(pDelegate);
    return *this;
  }

  CDelegateVoid& operator+=(IDelegateVoid* pDelegate)
  {
    Add(pDelegate);
    return *this;
  }

  CDelegateVoid& operator-=(IDelegateVoid* pDelegate)
  {
    Remove(pDelegate);
    return *this;
  }

  void operator()()
  {
    Invoke();
  }

private:
  void Add(IDelegateVoid* pDelegate);
  void Remove(IDelegateVoid* pDelegate);
  void RemoveAll();
  void Invoke();

private:
  std::list<IDelegateVoid*> m_DelegateList;
};

Для реализации необходимого набора операторов используются вспомогательные методы Add, Remove, RemoveAll и Invoke. Метод Add добавляет новый указатель IDelegateVoid* в список:

void CDelegateVoid::Add(IDelegateVoid* pDelegate)
{
  if(pDelegate != NULL)
    m_DelegateList.push_back(pDelegate);
}

Метод Remove ищет в списке делегат, ссылающийся на заданную функцию, и в случае обнаружения удаляет его:

void CDelegateVoid::Remove(IDelegateVoid* pDelegate)
{
  std::list<IDelegateVoid*>::iterator it;
  for(it = m_DelegateList.begin(); it != m_DelegateList.end(); ++it)
  {
    if((*it)->Compare(pDelegate))
    {
      delete (*it);
      m_DelegateList.erase(it);
      break;
    }
  }

  delete pDelegate;
}

Метод RemoveAll просто очищает список, удаляя из него все делегаты:

void CDelegateVoid::RemoveAll()
{
  std::list<IDelegateVoid*>::iterator it;
  for(it = m_DelegateList.begin(); it != m_DelegateList.end(); ++it)
    delete (*it);

  m_DelegateList.clear();
}

Наконец, метод Invoke вызывает все функции и методы, на которые ссылаются делегаты из списка:

void CDelegateVoid::Invoke()
{
  std::list<IDelegateVoid*>::const_iterator it;
  for(it = m_DelegateList.begin(); it != m_DelegateList.end(); ++it)
    (*it)->Invoke();
}

Использовать полученный класс делегата можно примерно так.

void Global()
{
  std::cout << "Global" << std::endl;
}

class C
{
public:
  void Method() { std::cout << "Method" << std::endl; }
  static void StaticMethod() { std::cout << "StaticMethod" << std::endl; }
};

int main()
{
  C c;
  CDelegateVoid delegate = NewDelegate(Global);
  delegate += NewDelegate(&c, &C::Method);
  delegate += NewDelegate(C::StaticMethod);
  delegate(); // вызывается Global, Method и StaticMethod.

  delegate -= NewDelegate(C::StaticMethod);
  delegate -= NewDelegate(Global);
  delegate(); // вызывается только Method.

  return 0;
}

Как видим, класс CDelegateVoid очень похож на делегаты из C#. Он полностью типобезопасен, так как попытка передать функции NewDelegate ссылку на функцию или метод, сигнатура которых отличается от void(void), немедленно приведёт к ошибке. Реализация класса CDelegateVoid не использует никаких предположений о размере и устройстве указателя на метод класса, поэтому он может использоваться как при обычном, так и при множественном и виртуальном наследовании. Его можно без изменений переносить на новые платформы и компиляторы.

Общая реализация

Теперь посмотрим, как можно обобщить класс CDelegateVoid для применения с различными сигнатурами. Используя шаблоны, мы можем параметризовать как тип возвращаемого значения, так и типы параметров функций, на которые ссылаются делегаты. В то же время, мы не можем определить единый шаблон, поддерживающий разное количество параметров, поэтому для каждого количества параметров необходимо реализовать свой класс. Поскольку наборы от 0 до 10 параметров покрывают 99% практических нужд при работе с делегатами, нам нужно написать 11 шаблонов делегатов CDelegate0, CDelegate1, ..., CDelegate10. Вот как будет начинаться описание делегата, который возвращает произвольное значение и принимает произвольный (но ровно 1) параметр.

template<class TRet, class TP1>
class IDelegate1
{
public:
  virtual ~IDelegate1() {}
  virtual TRet Invoke(TP1) = 0;
  virtual bool Compare(IDelegate1<TRet, TP1>* pDelegate) = 0;
};

template<class TRet, class TP1>
class CStaticDelegate1 : public IDelegate1<TRet, TP1>
{
public:
  typedef TRet (*PFunc)(TP1);
  CStaticDelegate1(PFunc pFunc) { m_pFunc = pFunc; }
  virtual TRet Invoke(TP1 p1) { return m_pFunc(p1); }
  virtual bool Compare(IDelegate1<TRet, TP1>* pDelegate)
  {
    CStaticDelegate1<TRet, TP1>* pStaticDel =
      dynamic_cast<CStaticDelegate1<TRet, TP1>*>(pDelegate);
    if(pStaticDel == NULL || pStaticDel->m_pFunc != m_pFunc)
      return false;

    return true;
  }

private:
  PFunc m_pFunc;
};

Как видим, мы вынуждены постоянно "таскать" за собой список параметров шаблона <TRet, TP1>. Для делегата с 10-ю параметрами эти списки полностью загромоздят код. Кроме того, вручную дублировать практически идентичные классы 11 раз — не самая удачная идея. Чтобы избежать лишнего дублирования кода, прибегнем к самому сильнодействующему (и самому опасному) средству языка C++ — препроцессору. Идея состоит в том, чтобы обозначить различающиеся участки кода в реализации классов CDelegateX макросами. Эти различающиеся участки можно разделить на 4 типа:

• Параметры шаблонов (например, <…, class TP1, class TP2, class TP3>). Список параметров шаблона обозначим макросом TEMPLATE_PARAMS.
• Аргументы шаблонов (например, <…, TP1, TP2, TP3>). Список аргументов шаблона обозначим макросом TEMPLATE_ARGS.
• Параметры функции Invoke (например, (TP1 p1, TP2 p2, TP3 p3)). Список этих параметров обозначим макросом PARAMS.
• Аргументы функции Invoke (например, (p1, p2, p3)). Список этих аргументов обозначим макросом ARGS.

Кроме этих макросов, нам потребуется макрос SUFFIX, который принимает значения от 0 до 10 и дописывается к именам классов следующим образом:

#define COMBINE(a,b)       COMBINE1(a,b)
#define COMBINE1(a,b)      a##b

#define I_DELEGATE         COMBINE(IDelegate, SUFFIX)
#define C_STATIC_DELEGATE  COMBINE(CStaticDelegate, SUFFIX)
#define C_METHOD_DELEGATE  COMBINE(CMethodDelegate, SUFFIX)
#define C_DELEGATE         COMBINE(CDelegate, SUFFIX)

ПРИМЕЧАНИЕ Обратите внимание на использование вспомогательного макроса COMBINE1. Если напрямую реализовать макрос COMBINE как #define COMBINE(a,b) a##b, то результатом подстановки COMBINE(IDelegate, SUFFIX) будет "IDelegateSUFFIX". А это совсем не то, что мы хотим получить. Поэтому использование COMBINE1 в данном случае необходимо.

Окончательная версия делегата, обобщённая с помощью всех этих макросов, будет выглядеть так:

template<class TRet TEMPLATE_PARAMS>
class I_DELEGATE
{
public:
  virtual ~I_DELEGATE() {}
  virtual TRet Invoke(PARAMS) = 0;
  virtual bool Compare(I_DELEGATE<TRet TEMPLATE_ARGS>* pDelegate) = 0;
};


template<class TRet TEMPLATE_PARAMS>
class C_STATIC_DELEGATE : public I_DELEGATE<TRet TEMPLATE_ARGS>
{
public:
  typedef TRet (*PFunc)(PARAMS);
  C_STATIC_DELEGATE(PFunc pFunc) { m_pFunc = pFunc; }
  virtual TRet Invoke(PARAMS) { return m_pFunc(ARGS); }
  virtual bool Compare(I_DELEGATE<TRet TEMPLATE_ARGS>* pDelegate)
  {
    C_STATIC_DELEGATE<TRet TEMPLATE_ARGS>* pStaticDel =
      dynamic_cast<C_STATIC_DELEGATE<TRet TEMPLATE_ARGS>*>(pDelegate);
    if(pStaticDel == NULL || pStaticDel->m_pFunc != m_pFunc)
      return false;

    return true;
  }

private:
  PFunc m_pFunc;
};


template<class TObj, class TRet TEMPLATE_PARAMS>
class C_METHOD_DELEGATE : public I_DELEGATE<TRet TEMPLATE_ARGS>
{
public:
  typedef TRet (TObj::*PMethod)(PARAMS);
  C_METHOD_DELEGATE(TObj* pObj, PMethod pMethod)
  {
    m_pObj = pObj;
    m_pMethod = pMethod;
  }
  virtual TRet Invoke(PARAMS) { return (m_pObj->*m_pMethod)(ARGS); }
  virtual bool Compare(I_DELEGATE<TRet TEMPLATE_ARGS>* pDelegate)
  {
    C_METHOD_DELEGATE<TObj, TRet TEMPLATE_ARGS>* pMethodDel =
      dynamic_cast<C_METHOD_DELEGATE<TObj, TRet TEMPLATE_ARGS>*>(pDelegate);
    if
    (
      pMethodDel == NULL ||
      pMethodDel->m_pObj != m_pObj ||
      pMethodDel->m_pMethod != m_pMethod
    )
    {
      return false;
    }

    return true;
  }

private:
  TObj *m_pObj;
  PMethod m_pMethod;
};


template<class TRet TEMPLATE_PARAMS>
I_DELEGATE<TRet TEMPLATE_ARGS>* NewDelegate(TRet (*pFunc)(PARAMS))
{
  return new C_STATIC_DELEGATE<TRet TEMPLATE_ARGS>(pFunc);
}

template <class TObj, class TRet TEMPLATE_PARAMS>
I_DELEGATE<TRet TEMPLATE_ARGS>* NewDelegate(TObj* pObj, 

    TRet (TObj::*pMethod)(PARAMS))
{
  return new C_METHOD_DELEGATE<TObj, TRet TEMPLATE_ARGS> (pObj, pMethod);
}


template<class TRet TEMPLATE_PARAMS>
class C_DELEGATE
{
public:
  typedef I_DELEGATE<TRet TEMPLATE_ARGS> IDelegate;
  typedef std::list<IDelegate*> DelegateList;

  C_DELEGATE(IDelegate* pDelegate = NULL) { Add(pDelegate); }
  ~C_DELEGATE() { RemoveAll(); }
  bool IsNull() { return (m_DelegateList.empty()); }

  C_DELEGATE<TRet TEMPLATE_ARGS>& operator=(IDelegate* pDelegate)
  {
    RemoveAll();
    Add(pDelegate);
    return *this;
  }

  C_DELEGATE<TRet TEMPLATE_ARGS>& operator+=(IDelegate* pDelegate)
  {
    Add(pDelegate);
    return *this;
  }

  C_DELEGATE<TRet TEMPLATE_ARGS>& operator-=(IDelegate* pDelegate)
  {
    Remove(pDelegate);
    return *this;
  }

  TRet operator()(PARAMS)
  {
    return Invoke(ARGS);
  }

private:
  void Add(IDelegate* pDelegate)
  {
    if(pDelegate != NULL)
      m_DelegateList.push_back(pDelegate);
  }

  void Remove(IDelegate* pDelegate)
  {
    DelegateList::iterator it;
    for(it = m_DelegateList.begin(); it != m_DelegateList.end(); ++it)
    {
      if((*it)->Compare(pDelegate))
      {
        delete (*it);
        m_DelegateList.erase(it);
        break;
      }
    }
  }

  void RemoveAll()
  {
    DelegateList::iterator it;
    for(it = m_DelegateList.begin(); it != m_DelegateList.end(); ++it)
      delete (*it);

    m_DelegateList.clear();
  }

  TRet Invoke(PARAMS)
  {
    DelegateList::const_iterator it;
    for(it = m_DelegateList.begin(); it != --m_DelegateList.end(); ++it)
      (*it)->Invoke(ARGS);

    return m_DelegateList.back()->Invoke(ARGS);
  }

private:
  DelegateList m_DelegateList;
};

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

// 5 parameters...
#define SUFFIX       5
#define TEMPLATE_PARAMS  \
  , class TP1, class TP2, class TP3, class TP4, class TP5
#define TEMPLATE_ARGS    , TP1, TP2, TP3, TP4, TP5
#define PARAMS       TP1 p1, TP2 p2, TP3 p3, TP4 p4, TP5 p5
#define ARGS         p1, p2, p3, p4, p5

#include "delegate_impl.h"

#undef SUFFIX
#undef TEMPLATE_PARAMS
#undef TEMPLATE_ARGS
#undef PARAMS
#undef ARGS

Подобные фрагменты для наборов от 0 до 10 параметров можно включить в отдельный файл delegate.h, который и будут подключать пользователи делегатов.

Вот пример использования библиотеки делегатов, которую мы только что получили. Обратите внимание, что он практически полностью соответствует примеру на языке C#, с которого началась эта статья.

#include <iostream>
#include <fstream>
#include <string>
using namespace std;

#include "delegate.h"


class App
{
public:
  // Определяем делегат Callback,
  // который принимает 1 параметр и ничего не возвращает.
  typedef CDelegate1<void, string> Callback;

  // Это метод класса App.
  void OutputToConsole(string str)
  {
    cout << str << endl;
  }

  // А это статический метод класса App.
  static void OutputToFile(string str)
  {
    ofstream fout("output.txt", ios::out | ios::app);
    fout << str << endl;
    fout.close();
  }
};


int main()
{
  App app;

  // Создаём делегат.
  App::Callback callback = NULL;
  if(!callback.IsNull()) callback("1");

  // Добавляем ссылку на OutputToFile.
  // Вызываем её через делегата.
  callback += NewDelegate(App::OutputToFile);
  if(!callback.IsNull()) callback("2");

  // Добавляем ссылку на OutputToConsole.
  // Вызывается вся цепочка:
  // сначала OutputToFile, потом OutputToConsole.
  callback += NewDelegate(&app, &App::OutputToConsole);
  if(!callback.IsNull()) callback("3");

  // Убираем ссылку на OutputToFile.
  // Вызывается только OutputToConsole.
  callback -= NewDelegate(App::OutputToFile);
  if(!callback.IsNull()) callback("4");

  // Убираем оставшуюся ссылку на OutputToConsole.
  callback -= NewDelegate(&app, &App::OutputToConsole);
  if(!callback.IsNull()) callback("5");
}

Законченный проект Visual Studio 7.0, содержащий этот пример, можно найти на сопровождающем компакт-диске.

Те же и Visual C++ 6.0

На этом можно было бы поставить точку, но остаётся ещё одна нерешённая проблема. Если вы попытаетесь скомпилировать приведённый пример в Visual C++ 6.0, у этого компилятора возникнут проблемы при задании параметра шаблона делегата TRet=void. Дело в том, что в этом случае VC6 не может корректно обработать конструкцию вида:

  virtual TRet Invoke(TP1 p1)
  {
    // VC6 полагает, что нельзя возвращать выражение типа void.
    return (m_pObj->*m_pMethod)(p1);
  }

Данная конструкция совершенно законна в соответствии с пунктом 6.6.3/3 Стандарта языка C++. Но VC6 об этом не знает. Поэтому нам придётся искать обходные пути. Чтобы обойти эту недоработку компилятора, необходимо отдельно реализовать все классы CDelegateX для случая TRet=void. Идеальным инструментом для этой цели служит частичная специализация шаблонов, но VC6 не поддерживает и эту возможность языка C++. В результате решение задачи на VC6 превращается в занимательную головоломку.

Первой моей мыслью было воспользоваться техникой, описанной Павлом Кузнецовым в этом же номере журнала в статье "Симуляция частичной специализации". К сожалению, выяснилось, что эта методика неприменима для реализации делегатов на VC6 сразу по двум причинам. Первая причина состоит в том, что использование полиморфизма совместно с навороченными шаблонными конструкциями оказывается "не по зубам" VC6, и он отказывается компилировать классы CStaticDelegateX и CMethodDelegateX, переписанные с использованием частичной специализации. На самом деле, это ещё полбеды, так как эти классы являются внутренней деталью реализации, и применять к ним частичную специализацию не обязательно. Вторая причина носит более фундаментальный характер. Дело в том, что симуляция частичной специализации для класса CDelegate подразумевает создание двух базовых классов (например, CDelegate_void_ для случая TRet=void и CDelegate_ для всех остальных случаев). Затем, в зависимости от значения параметра TRet, класс CDelegate наследовался бы либо от общей, либо от частной реализации. И тут возникает проблема. Дело в том, что в языке C++ операторы не наследуются. Это означает, что operator() нам всё равно придётся реализовывать в классе CDelegate. А мы не сможем реализовать его из-за той самой ошибки VC6, с которой и начался этот раздел. Таким образом, мы заходим в тупик.

Остаётся два пути. Первый путь – написать отдельную реализацию CDelegateVoidX, которая будет использоваться вместо CDelegateX в случае TRet=void. Этот путь плох, так как приводит к изменению внешнего интерфейса библиотеки делегатов. А это значит, что пользователям библиотеки придётся писать по две разных версии своих программ – для VC6 и для всех остальных компиляторов.

Второй путь – изменить функции Invoke так, чтобы в случае TRet=void они возвращали не void, а какое-нибудь нейтральное значение (например, ноль). Конечно, это не совсем честное решение, но оно вполне работоспособно. Посмотрим, как его можно реализовать.

В первую очередь нам нужен инструмент для преобразования типов, который на этапе компиляции превращал бы void в int, а остальные типы оставлял бы без изменений. В C++ такие преобразования типов осуществляются с использованием полной специализации шаблонов (к счастью, её VC6 поддерживает). В нашем случае реализация будет выглядеть так.

template<class T>
struct DelegateRetVal
{
  typedef T Type;
};

template<>
struct DelegateRetVal<void>
{
  typedef int Type;
};

Как видим, внутри класса DelegateRetVal определяется тип Type, который в общем случае совпадает с параметром шаблона T. Для случая T=void это поведение переопределяется с использованием специализации: в этом случае тип Type определяется как int. В результате, выражение DelegateRetVal<TRet>::Type будет на этапе компиляции принимать нужный нам тип при любых значениях TRet.Следующий шаг – модификация классов CStaticDelegateX и CMethodDelegateX. Во-первых, нужно заменить значение, возвращаемое методом Invoke, на DelegateRetVal<TRet>::Type. Во-вторых, нужно реализовать два дополнительных класса, CStaticDelegateVoidX и CMethodDelegateVoidX, для обработки случая TRet=void. Единственным их отличием от одноимённых классов без суффикса "Void" будет другая реализация метода Invoke:

#define C_STATIC_DELEGATE_VOID   COMBINE(CStaticDelegateVoid, SUFFIX)
#define C_METHOD_DELEGATE_VOID   COMBINE(CMethodDelegateVoid, SUFFIX)

 ...

template<class TRet TEMPLATE_PARAMS>
class C_STATIC_DELEGATE_VOID : public I_DELEGATE<TRet TEMPLATE_ARGS>
{
  ...

  virtual DelegateRetVal<TRet>::Type Invoke(PARAMS)
  {
    m_pFunc(ARGS);
    return 0;
  }

  ...
};

template<class TObj, class TRet TEMPLATE_PARAMS>
class C_METHOD_DELEGATE_VOID : public I_DELEGATE<TRet TEMPLATE_ARGS>
{
  ...

  virtual DelegateRetVal<TRet>::Type Invoke(PARAMS)
  {
    (m_pObj->*m_pMethod)(ARGS);
    return 0;
  }

  ...
};

ПРИМЕЧАНИЕ В этом месте может возникнуть соблазн избежать дублирования кода, породив класс CStaticDelegateVoidX от CStaticDelegateX и CMethodDelegateVoidX от CMethodDelegateX соответственно. К сожалению, это не будет работать. Хотя мы и переопределяем виртуальный метод Invoke в производных классах, теоретическая возможность обратиться к Invoke базовых классов сохраняется. Поэтому компилятор честно попытается сгенерировать их реализацию. А это в случае TRet=void в очередной раз приведёт к ошибке, которую мы пытаемся обойти. Поэтому дублирование кода в данном случае неизбежно.

Осталось сделать последний шаг – перегрузить функцию NewDelegate ещё двумя реализациями:

template<class TRet TEMPLATE_PARAMS>
I_DELEGATE<TRet TEMPLATE_ARGS>* NewDelegate(TRet (*pFunc)(PARAMS))
{
  return new C_STATIC_DELEGATE<TRet TEMPLATE_ARGS>(pFunc);
}

template<class TRet TEMPLATE_PARAMS>
I_DELEGATE<TRet TEMPLATE_ARGS>* NewDelegate(void (*pFunc)(PARAMS))
{
  return new C_STATIC_DELEGATE_VOID<void TEMPLATE_ARGS>(pFunc);
}

// Аналогично для CMethodDelegate*

В этом месте нас поджидает ещё один сюрприз. В большинстве случаев этот код будет работать, как по маслу. Но при задании TRet=void возникнет неоднозначность при обращении к функции NewDelegate. Правила разрешения перегрузки шаблонов функций описаны в разделе 14.5.5.2 Стандарта языка C++. В соответствии с этими правилами вторая версия NewDelegate не считается более специализированной, чем первая, так как для вызова обоих вариантов функции не требуется неявных преобразований типа.

Чтобы разрешить эту неоднозначность, придётся ввести дополнительный параметр функции NewDelegate, по которому и будет выбираться нужная версия функции:

// Параметр этого типа будет индикатором
template<int use>
class UseVoid {};

 ...

template<class TRet TEMPLATE_PARAMS>
I_DELEGATE<TRet TEMPLATE_ARGS>* NewDelegate(TRet (*pFunc)(PARAMS), 

    UseVoid<0>)
{
  return new C_STATIC_DELEGATE<TRet TEMPLATE_ARGS>(pFunc);
}

template<class TRet TEMPLATE_PARAMS>
I_DELEGATE<TRet TEMPLATE_ARGS>* NewDelegate(TRet (*pFunc)(PARAMS), 

    UseVoid<1>)
{
  return new C_STATIC_DELEGATE_VOID<TRet TEMPLATE_ARGS>(pFunc);
}

Тем самым мы избавляемся от неоднозначности. Но возникает другая проблема. Теперь при вызове NewDelegate необходимо явно указывать, какая версия функции нам нужна:

void f();
int g();
 ...
NewDelegate(f, UseVoid<1>());
NewDelegate(g, UseVoid<0>());

Чтобы избавиться от необходимости явно указывать параметр UseVoid, напишем третий вариант функции NewDelegate, который будет автоматически (причём на этапе компиляции) определять и вызывать нужную версию этой функции. Для реализации этой идеи нам потребуется механизм преобразования типа TRet в константу 1 (в случае TRet=void) или 0 (для всех остальных типов). Мы уже решали аналогичную задачу в классе DelegateRetVal, поэтому теперь решение записывается без труда:

template<class T>
struct IsVoid
{
  enum { Result = 0 };
};

template<>
struct IsVoid<void>
{
  enum { Result = 1 };
};

Теперь воспользуемся классом IsVoid для выбора нужного варианта функции NewDelegate.

template<class TRet TEMPLATE_PARAMS>
I_DELEGATE<TRet TEMPLATE_ARGS>* NewDelegate(TRet (*pFunc)(PARAMS))
{
  return NewDelegate(pFunc, UseVoid<IsVoid<TRet>::Result>());
}

Аналогичным образом NewDelegate перегружается для случая создания объектов CMethodDelegate*:

I_DELEGATE<TRet TEMPLATE_ARGS>* NewDelegate(TObj* pObj, 

    TRet (TObj::*pMethod)(PARAMS), UseVoid<0>)
{
  return new C_METHOD_DELEGATE<TObj, TRet TEMPLATE_ARGS> (pObj, pMethod);
}

template <class TObj, class TRet TEMPLATE_PARAMS>
I_DELEGATE<TRet TEMPLATE_ARGS>*
NewDelegate(TObj* pObj, TRet (TObj::*pMethod)(PARAMS), UseVoid<1>)
{
  return new C_METHOD_DELEGATE_VOID<TObj, TRet TEMPLATE_ARGS> (pObj, pMethod);
}

template <class TObj, class TRet TEMPLATE_PARAMS>
I_DELEGATE<TRet TEMPLATE_ARGS>* NewDelegate(TObj* pObj, 

    TRet (TObj::*pMethod)(PARAMS))
{
  return NewDelegate(pObj, pMethod, UseVoid<IsVoid<TRet>::Result>());
}

Если вас успели утомить эти "хождения по мукам", у меня есть для вас хорошая новость. Проблема, которую мы только что решили, была последней. Осталось заменить возвращаемые значения методов Invoke и operator() в классе CDelegate на DelegateRetVal<TRet>::Type, чтобы получить законченную реализацию делегатов для Visual C++ 6.0.

Полную версию реализации делегатов для Visual C++ 6.0 можно найти на сопровождающем компакт-диске.

Больше, лучше, быстрее

Реализация делегатов, которую мы рассмотрели выше, вполне работоспособна. Тем не менее, некоторые её особенности вызывают озабоченность. Во-первых, интенсивное использование шаблонов может привести к чрезмерному разбуханию кода. Во-вторых, объекты делегатов распределяются динамически (при помощи оператора new). Поскольку на создание объектов в куче тратится гораздо больше времени, чем на создание стековых объектов, это может привести к проблемам производительности. В этом разделе мы рассмотрим некоторые пути преодоления этих проблем.

С точки зрения разбухания кода наиболее неблагополучно выглядит класс CDelegateX. Его специализация генерируется для каждой сигнатуры, для которой будет использоваться делегат. Но методы Add, Remove и RemoveAll никак не используют информацию о сигнатуре. То есть для этих методов каждый раз будет генерироваться один и тот же код. Чтобы изменить ситуацию, можно вынести реализацию этих методов в отдельный нешаблонный класс CDelegateImpl. Тогда все специализации шаблона IDelegateX унаследуют эту реализацию, и она останется в программе в единственном экземпляре.

Чтобы реализовать эту идею, для начала разобьём интерфейс IDelegateX на два интерфейса. Базовый, IComparableDelegate, будет "отвечать" за сравнение делегатов. Производный, уже знакомый нам IDelegateX, будет определять дополнительный метод Invoke.

class IComparableDelegate
{
public:
  virtual ~IComparableDelegate() {}
  virtual bool Compare(IComparableDelegate* pDelegate) = 0;
};

template<class TRet TEMPLATE_PARAMS>
class I_DELEGATE : public IComparableDelegate
{
public:
  virtual TRet Invoke(PARAMS) = 0;
};

Обратите внимание, что в интерфейсе IComparableDelegate шаблоны не используются. Теперь в терминах этого интерфейса можно реализовать базовый класс CDelegateImpl, который будет отвечать за поддержку списка делегатов. Соответственно, в нём будут реализованы методы Add, Remove и Invoke.

class CDelegateImpl
{
public:
  typedef std::list<IComparableDelegate*> DelegateList;

  CDelegateImpl(IComparableDelegate* pDelegate = NULL) { Add(pDelegate); }
  ~CDelegateImpl() { RemoveAll(); }
  bool IsNull() { return (m_DelegateList.empty()); }

protected:
  void Add(IComparableDelegate* pDelegate)
  {
    if(pDelegate != NULL)
      m_DelegateList.push_back(pDelegate);
  }

  void Remove(IComparableDelegate* pDelegate)
  {
    DelegateList::iterator it;
    for(it = m_DelegateList.begin(); it != m_DelegateList.end(); ++it)
    {
      if((*it)->Compare(pDelegate))
      {
        delete (*it);
        m_DelegateList.erase(it);
          break;
      }
    }
  }

  void RemoveAll()
  {
    DelegateList::iterator it;
    for(it = m_DelegateList.begin(); it != m_DelegateList.end(); ++it)
      delete (*it);

    m_DelegateList.clear();
  }

protected:
  DelegateList m_DelegateList;
};

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

template<class TRet TEMPLATE_PARAMS>
class C_DELEGATE : public CDelegateImpl
{
public:
  typedef I_DELEGATE<TRet TEMPLATE_ARGS> IDelegate;

  C_DELEGATE(IDelegate* pDelegate = NULL) :
    CDelegateImpl(pDelegate) {}

  C_DELEGATE<TRet TEMPLATE_ARGS>& operator=(IDelegate* pDelegate)
  {
    RemoveAll();
    Add(pDelegate);
    return *this;
  }

  C_DELEGATE<TRet TEMPLATE_ARGS>& operator+=(IDelegate* pDelegate)
  {
    Add(pDelegate);
    return *this;
  }

  C_DELEGATE<TRet TEMPLATE_ARGS>& operator-=(IDelegate* pDelegate)
  {
    Remove(pDelegate);
    return *this;
  }

  TRet operator()(PARAMS)
  {
    return Invoke(ARGS);
  }

private:
  TRet Invoke(PARAMS)
  {
    DelegateList::const_iterator it;
      for(it = m_DelegateList.begin(); it != --m_DelegateList.end(); ++it)
        static_cast<IDelegate*> (*it)->Invoke(ARGS);

    return static_cast<IDelegate*> (m_DelegateList.back())->Invoke(ARGS);
  }
};

Обратите внимание на появившиеся приведения типов. В данном случае они никак не сказываются на типобезопасности делегатов, так как в списке m_DelegateList могут храниться только указатели на объекты классов CStaticDelegateX и CMethodDelegateX, а эти указатели заведомо приводятся к указателю на IDelegate.

В заключение несколько слов о проблеме производительности. Как уже говорилось, она может возникать из-за распределения объектов делегатов в куче. К сожалению, реализовать делегаты как стековые объекты не представляется возможным, так как для них существенным свойством является полиморфное поведение. Но и тут ситуацию можно существенно улучшить. Поскольку все делегаты централизованно создаются внутри функции NewDelegate, для них вполне возможно написать специализированный аллокатор, который будет распределять память для делегатов быстро и эффективно. Написание такого аллокатора оставляется читателю в качестве упражнения.

Заключение

Хочется отметить, что рассмотренный нами пример реализации делегатов может служить иллюстрацией как сильных, так и слабых сторон языка C++. Слабая сторона C++ – это его сложность. Особенно хорошо она заметна при реализации библиотек на базе шаблонов. Их код трудно читать и ещё труднее писать, так как в них семантическая сложность усугубляется сложностью синтаксической. Сильной же стороной C++ является совершенно невероятная гибкость этого языка. В рамках C++ можно реализовать и бесшовно интегрировать в язык самые разные возможности. Причём сделать это удаётся даже несмотря на грубейшие ошибки и недоработки разработчиков некоторых компиляторов.

Ведущий рассылки: Алекс Jenter   jenter@rsdn.ru
Публикуемые в рассылке материалы принадлежат сайту RSDN.

| Предыдущие выпуски     | Статистика рассылки