Albert Makhmutov - Идиомы и стили С++

return 0;

}

Что получилось: Имеем класс Cthat, который может иметь экземпляры, хотя и не имеет наполнения, и может исполнить пустую функцию. (Обратите внимание. Пустой объект имеет размер 1, и если добавить переменную char, то размер будет тот же. Экземпляры пустых объектов существуют, и они различаются.) Имеем класс объекта-указателя CPthat, в котором храним обычный указатель, но доступ к нему ограничиваем, и перегружаем для него операторы:

1. приведения типа Cthat

2. member selector -›.

3. Операторы арифметики указателей. Я указал только один, сложение.

Идея ясная. Нужно переопределить все восемь, или не переопределять их вовсе. Вопрос в том, направлен ли Ваш указатель на массив, или нет. Во всяком случае, не спешите с этим. Да, и в Ваших плюсах скорее всего тип ptrdiff_tнадо заменить на ptr_diff. Я просто дома на BC3.1все проверяю.

Что здесь хорошего? Мы получили класс объектов-указателей, которые можно смело применять вместо настоящих. Деструктор ~CPthat()уничтожает указуемый объект, поскольку сам по себе последний не имеет имени, и без своего указателя утрачивает идентичность. Проще говоря, останется в нашей памяти навечно, как герой. Ну можно конечно вызывать деструктор и явно, а что? Вот так:

pthat-›~Cthat();

Тогда удаление уберите из деструктора указателя.

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

template ‹class T›

class SmartPointer {

private:

T* tObj;

public:

SmartPointer(T* _t=NULL):tObj(_t);

~SmartPointer(){ if (tObj) delete tObj; }

operator T*(){ return tObj; }

T* operator-›(){ return tObj; }

};

Для интереса посмотрите, как сделан auto_ptrв STL.

Передохнем. Кофе. Джоггинг. Пиво. Сигарета. Нужное подчеркнуть, выпить, покурить.

Берем код параметризированного класса.

template ‹class T›

class SmartPointer {

private:

T* tObj;

public:

SmartPointer(T* _t=NULL): tObj(_t);

~SmartPointer() {if (tObj) delete tObj;}

operator T*(){return tObj;}

T* operator-›(){return tObj;}

};

Заменяем реализацию оператора -›на:

T* operator-›() {

if (!tObj) {

cerr ‹‹ "NULL";

tObj = new T;

}

return tObj;

}

или

T* operator-›() {

if (!tObj) throw CError;

return tObj;

};

Здесь CErrorкласс исключения. Или втыкаем статический экземпляр-шпион.

private:

T* tObj; // Это было;

static T* spy; // Это добавлено

Ну и сам перегруженный оператор.

T* operator-›() {

if (!tObj) return spy;

return tObj;

};

Здесь нужно пояснить: spyсовсем не обязательно класса T. Можно воткнуть производный, и переопределить его функции. Тогда он будет Вам докладывать о попытках обращения к NULL. Не забудьте его создать, инициализировать, и прицепить к указателю. А то вся идея на помойку. Вы пытаетесь отловить обращение к NULL, а там… NULL!!! "Матрицу" видели?

Ну это совсем банально. Выносим определение операторов за определение класса и ставим там точку останова. Чтобы не тормозило в релиз версии, окружаем слово inlineифдефами.

template ‹class T›

#ifndef DEBUG

inline

#endif

SmartPointer‹T›::operator T*() {

return tObj;

}

template ‹class T›

#ifndef DEBUG

inline

#endif

T* SmartPointer‹T›::operator T-›() {

return tObj;

}

Ну все, здесь уже совсем все просто. Ничего писать не буду, кроме напоминания о том, что всенепременнейше нужно определять статистические переменные класса, в том числе и для параметризированного (то бишь для шаблона), и ровно один раз.

Здесь сложнее. Об этом мне самому нужно почитать и полапать руками. Идея, как можно догадаться, в том, что если при обращении к умному указателю объект отсутствует в памяти, он считывается с диска. Проблемы самые очевидные в том, когда его снова отгружать на диск, разрушать объект, и как гарантировать единичность копии объекта при наличии многих ссылок.

Так. Пока тормозим. Интересно, о чем я напишу следующий шаг?

Предположим, у нас есть массив, в котором мы храним карту местности. Разумеется, что элементы массива разнообразные - дома, колодцы, казино… ничего общего. Кроме суперкласса - предка естественно.

CBuilding

¦

______¦_______

¦ ¦ ¦

CHouse CWell CCasino

А карту эту мы отражаем разными способами. И даже не то, что разными способами, а имеем для такой благой цели несколько видов карт. Ну я не знаю, не картограф. Черви и пики. Нет, ладно. Радиоактивность и карма.

CMap

|

____________

| |

CRadioMap CCarmaMap

И что получается? Кто будет себя отрисовывать? И кто кого? Для каждой комбинации наследников CBuildingи CMapсвой уникальный алгоритм. Что делать то будем? Какие феерические решения приходят… нет… не вам! Вашему коллеге или начальнику или подчиненному в голову? Да они ни сном ни духом о двойной диспетчеризации! Они скорее всего предложат получить информацию о типе во время исполнения, и запузырить в Ваш прекрасный проект кривоногий switch (){}. Да еще и положить в каждый класс статический член с информацией о типе… Одно звучание предыдущей фразы наводит на подозрения. Но что делаем мы? вот что:

class CBuilding: {

public:

virtual void doDraw(CMap* map)=0;

}

class CHouse: public CBuilding {

public:

virtual void doDraw (CMap* map) {

// ВОТ ОНА САМАЯ КОРКА!

map-›doDraw(*this);

}

};

// Эти такие же.

class CWell: public CBuilding {

public:

virtual void doDraw (CMap* map) {map-›doDraw(*this);}

};

class CCasino: public CBuilding {

public:

virtual void doDraw (CMap* map) {map-›doDraw(*this);}

};

// Это абстрактный класс для карт.

class CMap {

public:

virtual void doDraw (CHouse& cb)=0;

virtual void doDraw (CWell& cb)=0;

virtual void doDraw (CCasino& cb)=0;

};

Это конечно не все. Теперь нужно наследовать CRadioMapи CcarmaMapот общего предка CMapи в каждом классе рисовать реализацию алгоритма. За отрисовку отвечает карта, но какая масть - решает виртуальная CBuilding::doDraw(), а какое строение - выбирается перегруженная CMap::doDraw().

Одинаковое имя для функций отрисовки в разных классах давать не обязательно, но это является хорошим тоном при двойной диспетчеризации, и плохим без нее.