(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 {
