«Идиомы и стили С++»

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

Шаг 1 - Введение. Зачем все это надо и что это такое.

Чтобы сразу пояснить свой план, сообщу - здесь и далее я собираюсь вместе с Вами разобрать следующие темы:

1. Объекты-указатели на другие объекты.

2. Объекты-интерфейсы к другим объектам.

3. Использование шаблонов как средства безопасности.

4. Массивы данных, итераторы и курсоры.

5. Нестандартное управление памятью.

6. Разное.

Давайте посмотрим, что мы имеем на этот день. Если Вы добрались сюда, и начали читать, значит Вы облазили FirstSteps по всем разделам, вероятно, списали часть разделов себе на винчестер, и держите на столе пачку книг по программированию. Предполагаю так же, что Вы имеете за своей спиной 2-4 работающих проекта на FoxPro, Delphi или C/C++. То есть опыт имеете, но супермастером себя ПОКА не считаете. Но почему, собственно? Что нам мешает? Разве в Lotus или Microsoft работают одни гении (звучит прикольно, кстати)? Почему какие-то ребята вполне способны написать Windows или PhotoShop, или там DeltaForce, а нам то что мешает? Вы только подумайте - С++ изобрел один Бьярн Страуструп. Один! И перевернул мир. А STL придумал Алексей Степанов. Один. Сейчас в Хьюлет-Паккарде сидит. Тоже мир перевернул. (Если не верите, сравните второе и третье издание Страуструпа, "Язык программирования С++").

Похоже где-то есть неслабый пробел. Ну, может Вас, в институте учили разным штучкам и фенечкам в программировании, а меня, помнится, учили, что: "Компьютер состоит из монитора, системного блока и клавиатуры; при выходе из строя системного блока необходимо заменить системный блок". И если про бинарные деревья и хэш-таблицы можно почитать у Д. Кнута, то есть огромная область, которой похоже не учат до сих пор. Похоже на то, как если Вы выучили иностранный язык, и можете на нем читать-писать, а вот как разговорная речь так вроде все слова понятны, а вместе не ложатся. (Христос за это апостолов корил: "Какое слово вам непонятно!") Почему? Потому, что слова в разговорной речи, а равно и в программировании, складываясь, могут приобретать иной смысл и становиться фразеологизмами, или идиомами. И нам этот смысл надо постигать посредством чтения умных книжек. А что там? А там посмотришь на прилавки - выбор каков - "С++ для тупых", "С++ для Бивиса и Батт-хеда" да плюс справочники по функциям и алгоритмам. Но того, о чем я говорю, практически нет.

Итого получается, что не хватает нам того, чтобы секреты мастерства нам кто-то передавал. Секретов-то много, своим умом не дойдешь. Это в древности хорошо было - помирает старый мастер, перед смертью в двух словах раз-два, сказал пару слов и глазки закатил. Ну вы знаете - "Как ты делаешь такой вкусный чай" - "Ложите побольше заварки!". С программированием такого не бывает. Надо секрет загодя узнавать, мастера душить. Найти бы его только. Но делать то что-то надо!

Так вот, что я предлагаю: Я тут сижу и прорабатываю пачку книжек на эту тему. По мере продирания через них буду шкрябать статейки, и размещать их на FS. Надеюсь, авторы не обидятся. Напишу пяток-десяток, если будут отклики - продолжу. Если нет - значит не надо.

Насчет чего статейки будут - я выше перечислил. Еще будут объекты, поддерживающие транзакции, блокировки, очереди запросов на транзакции, имитация (в том числе и безопасная) массивов, инкапсуляция небезопасных типов в безопасные шаблоны, итераторы, создающие упрощенные копии сканируемого массива, управление памятью с оптимизацией и сборкой мусора, обработка исключений, виртуальные конструкторы(!), двойная и N-мерная диспетчеризация. Во всяком случае я это планирую (Самому страшно от того, что я перечислил; Но может силов мущинских моих не хватит, тогда не знаю…) Все это по силам практически любому, кто досюда вообще дочитал, и не помер со скуки. А пользы, как говорил Коровьев, он же Фагот, "от этого пения целый вагон". Вот например, самое простое - объект-указатель при отладке и на ранней стадии реализации проекта может управлять безопасным и низкопроизводительным массивом, а в релиз версии - самым обычным. При этом вы пользуетесь объектом-указателем как самим массивом.

Ну и ладно. Закончим со вступлением.

На всякий случай укажу свои основные источники, у которых я беру поносить идеи и мысли на время:

1. Jeff Alger. C++ for real progammers. (Джефф Элджер. С++).

2. James Coplien. Advanced C++ Styles and Idioms.

3. Мейерс, Скотт. Эффективное использование С++.

4. Страуструп, Бъярни. Язык программирования С++. Третье издание.

5. Буч, Гради. Объектно-ориентированное проектирование с примерами на С++. Второе издание.

6. Бабе, Бруно. Все о С++.

7. Microsoft corp. Официальное пособие по разработке приложений на VC++6.0

Вообще говоря, в основном все буду брать у Элджера. Проще, и интереснее. Мы же не умереть собираемся.

Ну и все. Начнем, пожалуй.

Шаг 2 - Умные указатели.

Сначала договоримся о терминах. Перегрузка функций (overloading) - многократное определение функции с разным набором аргументов (сигнатурой). В сигнатуру включается модификатор const, но не включается возвращаемое значение. Перегрузка операторов (overloading) - то же самое (операторы это собственно функции, только имя у них предопределенное), ПЛЮС само определение такого оператора. Если вы определили оператор для какого-то класса, это уже считается перегрузкой. Переопределение функций (overriding) - определение функций в субклассах с тем же именем. Правила переопределения функций достаточно сложны, и я не хотел бы грузить вас ими. Скажу только, что в Object Pascal они не в пример яснее, и компилятор укажет вам, что вы тормоз, если тормознете. А в Плюсах компилятор просто скроет функции, которые вы переопределите неправильно. Ну мы ему отомстим.

В C++ мы можем перегрузить почти все операторы, за исключением нескольких. Во всяком случае, оператор -› перегружается, и это имеет значение крайне важное. Кстати, он называется селектором (member selector). Итак, попробуем:

#include ‹mem.h›

class Cthat {

public:

 void doIt(void){return;};

};

class CPthat {

private:

 Cthat* aThat;

public:

 CPthat(Cthat* _that=NULL):aThat(_that){}

 ~CPthat() { if (aThat) delete aThat; }

 operator Cthat* () { return aThat;} // Оператор преобразования типа

 CThat* operator-›() { return aThat; }; // Оператор селектора -›

 CPthat operator+(ptrdiff_t _offset) { return CPthat(aThat+_offset); }

// ^^^^^^^^^

};

int main () {

 Cthat* aThat = new Cthat;

 aThat-›doSomething();

 CPthat pthat(new Cthat);

 pthat-›doIt(); // Вариант обращения через -›

 ((Cthat*)pthat)-›doIt (); //Вариант обращения через Cthat*

 delete aThat;

 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.

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

Шаг 3 - Как это применять.

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

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;}

};

1. Обработка обращения к NULL.

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

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!!! "Матрицу" видели?

2. Отладка и трассировка.

Ну это совсем банально. Выносим определение операторов за определение класса и ставим там точку останова. Чтобы не тормозило в релиз версии, окружаем слово 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;

}

3. Статистика классов и объектов.

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

4. Кэширование.

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

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

Шаг 4 - О двойной диспетчеризации.

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

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().

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

Круто? Это - подвиг неизвестного программиста. У Элджера был разобран пример со сложением чисел, очень красивый, но не сразу понятный. Там числа происходят от одного предка, что левый, что правый операнд оператора +, и по моему, обе диспетчеризации происходят по механизму виртуальных функций. Увы, мне лень набирать код.

Код к данному шагу я не проверял, в отличие от предыдущих. К диспетчеризации мы еще вернемся. Или не вернемся. Но следующий шаг однозначно про указатели.

Шаг 5 - Ведущие указатели (Master Pointers). Важные конструкторы.

Если мы уж взялись заниматься умными указателями, то очень быстро придем к выводу, что неплохо ограничить их свободу так, чтобы два указателя не указывали на один объект. Далее я их называю ведущими указателями. Для этого нужно реализовать буквально три-четыре правила:

1. Порождение ведущего указателя порождает объект, уничтожение ведущего указателя уничтожает объект;

2. Копирование ведущего указателя создает точную копию объекта;

3. Присваивание ведущего указателя уничтожает предыдущий объект и ставит на его место копию нового объекта.

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

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

class CThat {

private:

 int i;

public:

 CThat (int _i=0):i(_i) {}

 CThat (const CThat& _that):i(_that.i) {}

 CThat& operator=(const CThat& _that) {

  if (this == &_that) return *this;

  i = _that.i;

  return *this;

 }

};

class MasterPointer {

private:

 CThat* t;

public:

 // MasterPointer():t(new CThat){}

 MasterPointer(CThat _that=0):t(new CThat(_that)) {}

 MasterPointer(const MasterPointer& mp): t(new CThat((*mp.t))) {}

 ~MasterPointer() { delete t; }

 MasterPointer& operator=(const MasterPointer& mp) {

  if (this != &mp) {

   delete t;

   t = new CThat(*(mp.t));

  }

  return *this;

 }

};

Напоминать не надо, что this - это указатель на самого себя? Кстати и оказалось, что для реализации ведущего указателя класс указываемого объекта должен и сам иметь:

1. Конструктор без аргументов или с аргуметами, имеющими значения по умолчанию (default constructor). Компилятор вам нарисует такой один, если вы не определите конструкторов вообще никаких. На вид это будет просто ежик чернобыльский. Попытка создать внутри функции (я имею в виду в стеке) массив таких объектов наплодит вам массив дегенератов (это вне семантики ведущих указателей, мы же договариваемся, что без ведущих указателей такие объекты вообще не существуют). Так что не рискуйте.

2. Конструктор копии. Если вы не определите его, то компилятор нарисует свой. ТАКОЕ компилятору можно позволять только в крайнем случае, или перед пенсией, ибо по сравнению с этим чудовищем упомянутый ранее ежик просто Киану Ривз.

3. Оператор присваивания. То же самое. Подробности можно узнать в любой книге по C++, или в киоске с видеокассетами в разделе "Ужасы".

4. Виртуальный деструктор. Ну это еще ничего. Если Вы его не определите, то компилятор не задушит Вас ночью. Но вообще… должны быть очень серьезные причины для того, чтобы деструктор не был виртуальным, если вы наследуете свой класс или собираетесь от него наследовать.

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

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

template ‹class T›

class MP {

private:

 T* t;

public:

 MP():t (new T) {}

 MP(const MP‹T›& mp):t(new T((*mp.t))) {}

 ~MP() {delete t;}

 MP‹T›& operator= (const MP‹T›& mp) {

  if (this != &mp) {

   delete t;

   t = new T(*(mp.t));

  }

  return *this;

 }

};

Чувствуете ли Вы, что идеология умных указателей близка к идеологии COM? Если еще нет, то готовьтесь - сходство явится самое ближайшее время. IUnknown, QueryInterface, ClassFactory и интерфейсы объектов - все полностью взято из идиоматики умных указателей.

Шаг 6 - Ведущие указатели. Еще пара слов.

Применение ведущих указателям таково: Вы можете изменять поведение указываемого класса без применения наследования и не изменяя его код, и его новое поведение не будет отражаться на субклассах. Не обязательно СУЩЕСТВЕННО изменять поведение. Можно вести статистику класса или объекта, или сделать объект "только на чтение", поставив модификаторы const на сам оператор -› и возвращаемое значение:

const T* operator-›() const;

И вовсе не надо изменять код класса. Это совсем немаловажно, если у Вас, к примеру, коммерческая библиотека классов.

А еще можно сделать умный указатель на ведущий указатель. Или ведущий указатель на ведущий указатель. Вам не стало еще плохо? Если нет, то alors, en route!

Шаг 7 - Интерфейсы. Интерфейсные указатели.

Извините, тут лирическое отступление. Если хотите пропустить - нажмите PageDown.

2001, март, 5 число. Вот уже седьмой шаг. Я ухлопал на эти шаги весь свой законный Курбан-Байрам, и не соблюдаю намаз. Одако не забываю добавлять коньяк в кофе, что придает определенный колорит… шагам. Остановлюсь на некоторое время. Посмотрим, что получится. Честно говоря, мне нужна обратная связь. Я не Толстой, и не Буч, и не совсем уверен, что эти шаги нужны человечеству. Поэтому я прошу Вас сообщить мне, насколько Вам интересны темы, затронутые мною, и если Вас это не затрудняет - несколько слов о том, кто Вы и какой Ваш опыт работы (я хочу выяснить, в какую аудиторию я попадаю, и куда ввязываюсь), буквально пару строк. У меня есть материал примерно еще на 20-30 шагов по идиоматике, а потом можно будет поковырять объектный анализ. Про анализ замечу: софт девелоперу за бугром предлагается 55-70 тонн баксов в год, а аналисту 90-120. Есть разница? Да и вообще, зачем разбирать идиоматику C++, если потом нарисовать диалоговое окно, положить в него одну кнопку, а на OnClick повесить обработчик одного сообщения, весом в 20 тысяч строк. Ну это личное дело каждого. Я сам так делаю. На дельфях и фокспре.

А можно еще потолковать о распределенных приложениях. Или архитектурных решениях. Блин, надо же подняться как-то над WinAPI и RAS, они же и в MSDN есть. Ну ладно, будет с этим. Конец лирического отступления. Вернемся к нашим баранам, то бишь указателям.

Давайте подумаем, какой интерфейс есть у класса. Его объявление? Верно. Но не все. Интерфейс - это то, что видит клиент. А видят разные клиенты разное. Отношения дружбы, наследования, модификаторы доступа сами по себе изменяют интерфейс. Как мы можем приобрести почти неограниченный контроль над интерфейсом? Ранее рассмотренные ведущие указатели не позволяют изменять интерфейс, ибо перегруженный оператор -› действительно позволяет осуществлять доступ к настоящему интерфейсу, а значит, информация о нем должна быть доступна. Ну и не будем его перегружать. Ничего не мешает просто скопировать нужную часть его интерфейса в определение указателя, и вызывать нужные функции объекта в одноименных функциях указателя. Если нас интересует секретность, то делаем все функции не-подстановочными (то есть определяем их вне объявления класса и без модификатора inline). Вот код:

// Это находится в заголовочном файле.

class Cthat;

class CPthat {

private:

 Cthat* t; // обычный указатель на объект

public:

 CPthat ();

 CPthat (const CPthat&);

 ~CPthat ();

 CPthat& operator=(const CPthat&);

 // Новый интерфейс - дубликат

 void funct1(void);

 void funct2(void);

};

// Это все содержится в cpp-файле.

// и первое - определение указываемого объекта

class Cthat {

 friend class CPthat;

private:

protected:

 Cthat();

public:

 // Родной интерфейс.

 void funct1(void);

 void funct2(void);

};

//Реализация членов-функций класса указателя.

CPthat::CPthat ():t(new Cthat) {}

CPthat::CPthat (const CPthat& _cp):t(new Cthat(*(_cp.t))) {}

CPthat::~CPthat (){ delete t; }

CPthat& CPthat::operator=(const CPthat& _cp) {

 if (this != &_cp) {

  delete t;

  t = new Cthat(*(_cp.t));

 }

 return *this;

}

void CPthat::funct1(void) { t-›funct1(); }

void CPthat::funct2(void) { t-›funct2(); }

// Реализация членов-функций класса объекта

Cthat::Cthat() {}

void Cthat::funct1(void) {}

void Cthat::funct2(void) {}

Все, приплыли. От класса указываемых объектов остался только перископ в виде class Cthat;, а более ничего. CPthat действует вместо него. Он сам стал им. Класс CPthat является классом интерфейсного указателя.

Теперь можете идти за пивом. Вы властелин вселенной. Вы можете превратить кого угодно во что угодно. Имея на вооружении идиомы умных, ведущих и интерфейсных указателей, сочетая их в любых комбинациях, Вы можете превратить в урода любой класс на выбор. Или в красавца. Ваше желание - закон, господин. Мне кажется, Вы уже знаете, о чем будет следующий шаг. Но я не могу подобрать нормального термина этому. Слово "интерфейс" заездили до последней степени. Скоро руль и педали назовут интерфейсом автомобиля к шоферу, а вилка, ложка и нож будут универсальным интерфейсом еды. И конечно, Мелкомякг именно это слово применил для следующей идеи. А еще это называют "suite" - комплект, или "facet" - грань. В общем, следующий шаг - о множественных интерфейсных указателях на объект.

Шаг 8 - Еще раз о статистике класса.

Пока праздники не начались и не кончились, пока работает интернет и библиотека, снова займемся любимым делом - статистикой класса. Мы уже говорили о ней, и уяснили, что здесь неплохо работает идиома ведущих указателей. Но на плюсах работает в течение 20 лет сотни тысяч программеров, и было бы неверно предположить, что они за это время не изобрели иных приличных способов реализовать статистику. Так… что же они там навыдумывали?

Мысль о классе, ответственном за статистику, приходит быстро. Да, это работает, но как только иерархия классов разрастается, увеличивается количество геморроя. Наследование становится множественным, потом виртуальным, статические члены сохраняются в классах мертвым грузом… ну в небольших иерархиях работает, но я не для этого взялся за шаг.

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

// Это шаблон класса, ответственного за статистику.

template ‹class T›

class CCounter {

public:

 CCounter() { ++m_iCount; }

 CCounter(const CCounter&) { ++m_iCount; }

 ~CCounter() { --m_iCount; }

 static int GetCount() { return m_iCount; }

private:

 static int m_iCount;

};

// Парашютики, парашютики берем не забываем!

// Инициализируем статическую мембер-переменную.

template ‹class T› int CCounter‹T›::m_iCount = 0;

// Использование статистики.

class CClass {

public:

 static int GetCount() { return CCounter‹CClass>::GetCount(); };

private:

 CCounter‹CClass› cInstance;

};

Нор убавить нейзер прибавить, сказать нечего, разве вместо неуместного int поставьте size_t. Это макрос, он расширяется в зависимости от модели памяти или в int или в long. Я уж чтоб народ не смущать, в конце концов сайт называется "Первые Шаги", а не Последний Путь. Можно применить наследование, но не советую. Мейерс нашел какие-то преимущества, но меня не убедил.

Да еще это КРАЙНЕ важно - модификатор const в объявлении функций - не гнушайтесь его юзать! Если функция не изменяет ничего в классе, ставьте не ленясь. Если кто-то захочет позже использовать ее в константной функции, то не сможет - без вмешательства в код, а это надо? Шансы на то, что этот кто-то будете Вы, но более опытный, крайне велики. Трудно набирать? Купите себе кривую клаву и потренируйтесь месячишко стучать вслепую. Эта инвестиция окупится, уверяю Вас как специалист по фондовому рынку. То же с аргументами, передаваемыми в функцию. Не забывайте, что const изменяет сигнатуру функции.

Шаг 9 - Множественные интерфейсные smart-указатели.

Вполне возможно, что Вы работаете с действительно крупным проектом, иерархия классов развилась до огромных размеров, а каждый класс (особенно внизу иерархии) обладает десятками или сотнями открытых функций. Конечно, неплохо задаться вопросом "Насколько разумно это?". Еще лучше, если этот вопрос задать до начала написания кода. Тогда можно вовремя почитать Гради Буча, установить на компьютер "Rational Rose" или сходную CASE-систему, и более чем тщательно спроектировать иерархию классов. К сожалению, вопросы объектного анализа и проектирования выходят далеко за рамки данного Шага и моих способностей. Но на всякий случай сообщу, что Microsoft серьезнейшим образом почистила библиотеку своих классов при выпуске версии для карманных компьютеров, и только в результате такой меры ЭТО стало вообще работать в каких-то разумных пределах и объемах; ошибки этапа моделирования вообще обходятся очень дорого впоследствии, особенно если система развивается.

Тем не менее, функций в классах остается достаточно много. Очевидно, что они группируются по своему назначению. Практически всегда есть группы, отвечающие за:

1. конструирование и инициализацию;

2. уничтожение и деактивацию;

3. сохранение и загрузку;

4. отображение;

5. обработку сообщений (событий).

Тут можно провести такую аналогию: если каждую функцию представить в виде одного провода, то их можно объединить в стандартный разъем: LPT, RS-232 или иной, и этот разъем будет обладать новыми, высшими свойствами, какими по отдельности провода не обладают; объединяя функции в цельные функциональные наборы мы так же получаем нечто новое. Присвоим этим наборам название, потом займемся реализацией. Термин возьмем у Microsoft. Необычно, нетривиально, метко, а главное, свежо: интерфейс. Элджер дает термин facet (грань), и suite (комплект, а не костюм). Где-то я еще видел термин sub-pointer, но этот термин применим только для одной реализации, но не отражает общей концепции. По счастью, именно об этой реализации мы и собираемся поговорить.

Итак, как же объединить функции-члены в наборы, опираясь на средства языка? Да просто: определить их в абстрактных базовых классах, а потом объединять их при помощи множественного наследования. Это вполне неплохая идея. Именно так создаются объекты на основе ATL: дается набор стандартных шаблонов для стандартных интерфейсов, потом объединяется при помощи множественного наследования. Указатели на интерфейсы Вы можете легко получать при помощи dynamic_cast‹T›, только на всякий случай обрабатывайте исключение (обратного преобразования так легко не сделать, к сожалению; вообще это проблема - преобразование базового класса в производный в случае множественного наследования; я собираюсь поговорить об этом позже, а в этом Шаге заклинаю Вас не использовать явного преобразования указателей, только dynamic_cast‹T› с перехватом исключения и проверкой на NULL). Но есть и недостатки, причем кроме чисто технических, на мой взгляд, есть еще один серьезный этап проектирования: множественное наследование в объектном анализе, применяется для реализации какого-то одного, редкого аспекта поведения, присущего разным несвязанным классам - "повадки" класса. Наследование от класса, склеенного из нескольких других, выведет проблему на новый уровень иерархии. Вывод - такая техника оправдана в листьях дерева классов, в самом низу иерархии.

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

class Cоbject {

// функции набора 1

// функции набора 2

};

class Cfuncset1 {

private:

 Cobject* obj;

public:

// функции набора 1

};

class Cfuncset2 {

private:

 Cobject* obj;

public:

// функции набора 2

};

Обращаю внимание - использовать нужно именно простые умные указатели, или интерфейсные указатели из Шага 7, но не ведущие. Проблемы этого варианта очевидны, хотя бы чисто технические: преобразование интерфейсов и создание-удаление реального указываемого объекта. Smart-указатели тоже можно наследовать от абстрактных базовых классов, тогда Вы получите определенную жесткость своей конструкции. Сам указываемый объект может быть каким угодно. Склеили ли вы его через множественным наследование, или как единое целое он вообще не существует, а реализован как несколько жестко связанных объектов (бывает и такое) - клиентам это без разницы, если они все равно имеют к нему доступ через стандартные интерфейсы.

Подробности разберем в следующих Шагах, а сейчас я призываю Вас вспомнить, как в COM/DCOM сделано сохранение объектов: Вы имеете IStorage - умный указатель на объект "файл-хранилище", IPersist - умный указатель на объект, подлежащий записи, затем натурально сцепляете их, передавая указатель на IStorage в IPersist, и теперь Ваш объект просто выливается в свое хранилище, как молоко в глиняный кувшин. Объект может иметь любое количество иных интерфейсов, но наличие стандартного IPersist позволяет легко и красиво выполнить стандартную операцию.

Последнее: читайте Гради Буча! Учтите, что с первого раза он никогда (вообще!) не доходит. Только на второй или третий, не меньше, и то, если будете перемежать его с UML. Если Ваш проект действительно серьезный, то без грамотной модели он не существует. Этель Лилиан Войнич никогда бы не дописала свой роман "Овод", если бы с самого начала не задалась моделью: класс ‹солдат› обязательно должен иметь функцию ‹застрелить› экземпляр класса ‹мятежник›, а класс ‹офицер› во-первых, наследует от класса ‹солдат›, во-вторых, может отсортировать набор ‹солдат› в порядке возрастания - построить их на расстрел, в третьих - может и сам пристрелить врага при необходимости. Сильно подозреваю, что в этой модели функция ‹застрелить› является для ‹мятежника› дружественной. Выбирайте друзей правильно!

Шаг 10 - Множественные интерфейсные указатели. Продолжение.

Humpty-Dumpty: "With a name of Your,

You might be any shape, almost!"

L. Carroll. Throw the looking glass.

Сейчас мы поговорим о реализации, но до начала позвольте мне вернуться немного назад и добавить, что есть еще один неплохой способ организации множества интерфейсов. Он выглядит слегка неуклюже, но при известной дисциплине вполне работает: это метод вложенных классов из MFC COM. В самых общих чертах - там применяется явное получение смещения родительского класса от вложенного. Желающие могут посмотреть в MSDN по ключевому слову METHOD_PROLOGUE.

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

Итак, мы уже решили иметь к некоему сложному объекту набор стандартных интерфейсов, и реализовать их при помощи smart-указателей. Но сами по себе они не имеют никакой пользы, если мы не сможем получать интерфейсы и объект друг из друга; для этого надо заиметь специальные средства, ибо интерфейсные указатели есть самостоятельные объекты, и вообще могут изменять свой указываемый объект в течение своего существования, и даже изменять тип объекта, если угодно (этого не может даже BASIC).

Для получения интерфейса по объекту проще всего нарисовать конструктор, получающий в качестве аргумента объект:

// Это объект

CComplexObject {};

// Это интерфейс

CInterface {

private:

 CComplexObject* co; // Укаэатель на объект

public:

 CInterface (CComplexObject _co){}; // Это конструктор

};

Немного подумав, решаем перенести обязанности по порождению интерфейсов на объект. Конструктор интерфейса перекладываем в private, объявляем класс объекта дружественным классу интерфейса, в классе объекта перегружаем операторы преобразования (или русским языком говоря - рисуем операторы преобразования объекта к интерфейсу).

// Это объект

class CComplexObject {

 operator CInterface() { return new CInterface(this); } // оператор преобразования

};

// Это интерфейс

CInterface {

private:

 CComplexObject* co; // Укаэатель на объект

 CInterface (CComplexObject* _co) {} // Это частный конструктор

};

Думаем еще раз: перенести ответственность за преобразование интерфейсов на специально выделенный smart-указатель, и временно назовем его Super-указателем. Идея с супером просто счастливая - мало того, что не надо изменять объект (код класс объекта), так еще и преобразование упрощается: сначала получим супер по интерфейсу, а потом другой интерфейс по суперу. Да, конечно, два преобразования подряд, но это все же лучше чем в каждом интерфейсе определять преобразование ко всем остальным. Зато интерфейсы ничего не знают друг о друге, им нет нужды, если им известен супер. И потом, поскольку интерфейсы являются простыми smart-ами, надо пожалуй задать функциюшечку, которая бы проверяла - есть ли вообще в природе изрядно подзабытый нами объект. Это место небезуспешно может занять перегруженный оператор operator!().

// Предварительные объявления классов

class CComplexObject;

class CInterface;

class CSuperObject;

// Определение объекта пропускаю, это Ваше занятие.

// Определение супера

class CSuperObject {

private:

 CComplexObject* co; // указатель на объект

public:

 // конструктор супера,

 CSuperObject(CComplexObject* _co): co(_co) {}

 // Живой ли наш объект? Дима! Помаши рукой маме!

 bool operator!(){ return co==NULL; }

 // преобразование к интерфейсу

 operator CInterface();

}

// Это интерфейс

CInterface {

private:

 CComplexObject* co; // Укаэатель на объект

 CSuperObject* cs; // указатель на супер

 CInterface (CComplexObject* _co) {} // Это частный конструктор

public:

 bool operator!(){ return co==NULL; } //проверка на существование объекта

 operator CSuperObject (); //преобразование к суперу

};

Ну все, с этой темой я закругляюсь, но думаю, что идея понятна. Комбинации умных, ведущих, интерфейсных указателей, наследование смартов от абстрактных базовых классов, наследование смартов и указываемых объектов от одних и тех же базовых классов позволяют Вам достичь удивительной гибкости. Помните, как Шалтай-Болтай говорил Алисе "с таким именем ты можешь оказаться кем угодно… просто КЕМ УГОДНО!"? Мы лучше. Мы оказываемся кем угодно, когда угодно, и по собственному желанию.

Напоследок прописная истина для тех, кто не знает: общие определения полиморфизма, наследования, инкапсуляции, понимание перегрузки операторов, перегрузки и переопределения функций, абстрактных классов, виртуальных и чистых виртуальных функций, конструкторов и деструкторов КРИТИЧЕСКИ ВАЖНЫ ПРИ ПОИСКЕ РАБОТЫ ЗА БУГРОМ!!! Если Вы запнетесь хоть на одном из этих терминов, то Ваш интервьюер никогда Вам больше не позвонит, а если он еще и работает на крупную фирму, то Вас занесут в базу данных как никчемного ламера, и с ней будут сверяться десятки рекрутеров по всем Юнидос Эстадос. Вот так.

Шаг 11 - Нетривиальное конструирование объектов.

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

CClass {

protected:

 CClass () {}

};

А если Вы еще хотите так же и запретить наследование, то конструкторы перемещаются в закрытую часть объявления:

CClass {

private:

 CClass () {}

};

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

// Вариант 1: производящая функция-член.

CClass {

public:

 static CClass* factory (void);

private:

 CClass () {}

};

CClass* CClass::factory(void) { return new CClass(); }

// Где-то в коде

CClass* cc = CClass::factory(void);

// Вариант 2. Дружественная функция.

CClass {

 friend CClass* factory (void);

private:

 CClass () {}

};

// Дружественная Функция, создающая экземпляры класса.

CClass* factory (void) {

 return new CClass;

}

// Где-то в коде

CClass* cc = factory(void);

Вы видите, что разницы между двумя вариантами практически нет? Единственно, что дружественная функция лежит вне области видимости класса. Но она фактически является элементом его интерфейса! Именно это наблюдение позволило Мейерсу сделать несколько неожиданный вывод: дружественные функции могут улучшать инкапсуляцию класса! Не знаю, как для Вас, но мне пришлось прочитать его статью дважды, а потом еще найти перевод на русский язык, потому как сразу это не в голове не уложилось. Подробности читайте в "С++ Journal", апрель 2000 года.

Желая продолжить изыскания в области ограничения конструирования, зададим вопрос: А можно ли совсем запретить конструирование экземпляров класса, даже для друзей и для статических функций? Ответ: Да. Можно. Нужно сделать как минимум одну функцию чистой виртуальной (pure virtual). Для этого есть специальный синтаксис:

virtual void f(void)=0;

В этом случае компилятор не может создать для класса виртуальную таблицу, и соответственно не может создать экземпляр.

Вернемся опять к статической функции. Статическую функцию класса можно вызвать двумя способами - указав либо имя класса, либо через экземпляр класса.

CClass* cc1 = CClass::factory(void);

CClass* cc2 = cc1-›factory(void); // Вызов производящей функции

// Не знаю, откуда мы его берем, но это стековый экземпляр

CClass cc3;

CClass* cc4 = cc3.factory(void); // Еще один вызов производящей функции

Тут-то и делается самый прикол. Мы делаем виртуальный конструктор: виртуальную производящую функцию:

CClass {

public:

 // Теперь виртуальная, а не статическая.

 virtual CClass* factory (void);

 // Конструктор делаем для простоты открытым,

 // поскольку все-таки нам нужен

 // базовый способ получения экземпляров

 CClass () {}

};

CClass* CClass::factory(void) { return new CClass(); }

// Где-то в коде

CClass* cc = new CClass();

// Виртуальное конструирование!!!

CClass* cc1 = cc-›factory(void);

Думаю, что на этом следует закончить этот шаг. К конструированию объектов мы будем возвращаться еще не раз… но не сегодня.

Примером производящих функций являются макросы DECLARE_SERIAL, IMPLEMENT_SERIAL, DECLARE_DYNCREATE, IMPLEMENT_DYNCREATE в MFC. Они конечно сложнее и делают много чего еще, но в конечном итоге это замазанные макросом производящие функции.

Шаг 12 - Двухэтапная инициализация.

Когда мы создаем нестековый экземпляр, то пишем такой код:

CClass* cc = new CClass();

Попробуем поразбираться. new - это глобальный оператор с определением:

void* operator new (size_t bytes);

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

1. Выделение памяти;

2. Конструирование.

Оба действия могут кончиться неудачей. Либо память не выделится, тогда негде будет инициализировать объект, либо память выделится, но инициализация будет неудачной. С 1998 года стандарт C++ предусматривает, что если инициализация прошла неудачно, то выделенная память должна автоматически освободиться - то есть вызваться оператор delete, но без передачи управления деструктору. До того это оставалось на совести разработчика компилятора, и довольно часто выделенная память могла застрять, и больше не вернуться в систему. Кроме того, конструктор ничего не возвращает. Только что проверить на NULL. Ну еще конечно исключения, да… но все так сложно, елы… Короче, не след бы нам смешивать разные вещи, даже если это совсем не суп и не мухи, а совсем выделение памяти и инициализация.

В какой-то степени по этой причине, но так же и по некоторым другим соображениям, в C++ применяется прием двухэтапной инициализации. На мой взгляд это не есть идиома, а довольно простой прием, но есть весьма важная причина, почему я должен о нем рассказать: его не используют.

Особенно часто этим грешат начинающие Delphi-щики, и VB-шники: слишком велик соблазн щелкнуть по методу формы OnCreate, OnShow (Form_Create, Form_Show), и прописывать инициализации там, или, что еще ужаснее, залезть из одной формы в другую и там изменять значения переменных. Не делайте этого! Граждане дельфинщики! Форма - такой же класс, как и все остальные. Не лишайте ее законного конструктора, дайте ей заслуженную инициализацию! Не чмарите свой инструмент, и он воздаст Вам сторицей!

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

class CClass {

private:

// Чудовищно сложные структуры, ресурсы,

// мьютексы-шмутексы, все сплошь критическое,

// пачками выбрасывающие исключения.

public:

 CClass (); // Конструктор, которому на Ваши проблемы плевать.

 // Вот тут мы и замучаем свои ресурсы.

 int InitInstance (‹список аргументов›) throw (‹список исключений›);

};

// Где-то в коде:

CClass* cc = new CClass;

if (cc != NULL) {

 try {

  int ret_code = cc-›InitInstance();

  // Тут еще и код возврата можно обработать, если не лень,

  // но только если инициализация прошла успешно.

  // если выскочило исключение, сюда мы не попадем.

 }  catch (…) {

  // да еще и исключения обработать.

 }

};

Все…

Шаг 13 - Перегрузка operator+.

Оператор operator-› мы уже перегружали. Результаты получились просто феерические. Давайте замучаем еще кого-нибудь и посмотрим, что получится? Давайте. Первейшим кандидатом на переопределение является оператор operator+,потому что в жизни (помимо С++) он выражает замечательное действие - добавление объекта к другому объекту. Конечно, Вы можете придать ему и другой смысл, но это будет как раз тот случай, где "если хочешь быть здоров - ешь один, и в темноте"…

Проиллюстрирую сказанное следующим примером: Вы пишете интерфейс на Паскале, и для добавления подменю или пункта меню используете функции AddSubMenu() и AddMenuItem(). Тогда для создания меню Вы прописываете замечательно изящное выражение с толстым-толстым слоем скобок в конце:

Menu.AddSubMenu(Submenu1,

 AddMenuItem(MenuItem1,

  AddMenuItem(MenuItem2,

   AddMenuItem(MenuItem3,

    AddSubMenu (SubMenu2, nil)

))));

А вот что получается на С++:

CMenu Menu = Menu() + SubMenu1() + MenuItem1() + MenuItem2() + MenuItem3() + SubMenu2();

Прошу извинить за отсутствие подробностей - на память не помню; но и так очевидно, что выражение в C++ выглядит просто красивее. Это одно из главных достоинств С++ - язык позволяет выражать наши намерения предельно ясно.

Есть еще один смысл, который можно придать оператору operator+, если "от перестановки мест слагаемых сумма не изменяется". Примером, кроме сложения и умножения чисел, может быть соударение объектов: столкнулся ли Титаник с айсбергом, айсберг ли столкнулся с Титаником, результат один - вызов деструктора для Титаника. (Я не утверждаю, что это НУЖНО делать так, это только можно!)

Немного ниже мы используем это для уменьшения количества диспетчерских функций при двойной диспетчеризации из Шага 4, а сейчас быстренько напишем код с переопределением operator+ для любимого стека всех времен и народов. Понятно, на месте стека может оказаться каждый, те же меню, опять же.

class CArray {

private:

 int a[100];

 int iTop;

public:

 CArray ():iTop(0) {}

 CArray (const CArray& _ca) {

  iTop = _ca.iTop;

  for (int i=0; i++; i ‹100) a[i]= _ca.a[i];

 }

 CArray& operator=(const CArray& _ca) {

  if (this==&_ca) return *this;

  for (int i=0; i++; i ‹100) a[i]= _ca.a[i];

  iTop = _ca.iTop;

  return *this;

 };

 // С этим еще можно согласиться

 CArray& operator+ (int _i) { a[iTop]=_i; iTop++; return *this; }

 // Это пример дурного стиля

 int operator-- () { iTop--; return a[iTop+1]; }

};

Для такого тестового стека определим оператор operator+ (и operator+=) для вставки объектов, а оператор operator- для выталкивания и удаления. Вы кстати знаете, что для operator++ и operator- есть постфиксная и префиксная форма? У постфиксной в скобках фиктивный параметр стоит:

const type& operator++(); // Префиксная

type operator++(int); // Постфиксная.

Я позволяю себе пропустить кучу деталей (например то, что вставка сто первого элемента слегка повесит программу), но обращаю внимание: определение конструктора копии и оператора присваивания - суровая необходимость. Не сделаете - пожалеете; почему - говорил в Шаге 5.

Еще нюанс: определение operator-- для выбора из стека есть, мягко говоря, спорный стиль; некоторые считают даже перегрузку operator‹‹ и operator›› для работы с потоками крайне неудачной идеей. Так что это я только для примера…

Пример имеет семантику значений, а не семантику указателей. Это в общем значит, что в коллекции хранятся примитивные значения, а не указатели или ссылки.

Кстати, запомните эти умные слова, их круто вставить в разговор с приятелями или (еще лучше) с начальством, чтобы запутать его в камом-нибудь вопросе или снять с себя ответственность за неверно принятые решения. Если особенно ответственность лежит так же и на начальстве (оно же и аналитик), то объяснение "так и так, тут семантика значений" будет воспринято лучше, чем "вы все - тупицы и недоучки, неспособные к проектированию и анализу". Вообще, теоретические познания бывают как нельзя более кстати при поиске виновных, чем при повседневной работе. Вы можете колбасить программы на фокспре или хотя и на C++ c MTS и DCOM, но если Ваша программа повесит сервер бухгалтерии за день до зарплаты или годового отчета… то никакие познания не будут лишними, чтобы свалить вину на сисадминов!

Перед тем, как закончить Шаг, вернусь к стилю: если я для примера безграмотно переопределил операторы арифметики, это не значит, что то же самое должны делать Вы. Компилятор позволяет определить любое возвращаемое значение и запрограммировать любые действия, но понемногу изменяя семантику, в конце концов Вы выроете себе яму и попадете в нее. Есть еще одна опасность - поведение, приоритет и правила взаимодействия операторов ЗАДАНЫ раз и навсегда, а компилятор не может оценить Ваш интеллектуальный уровень, и действует так, как ДОЛЖЕН, а не так, как Вы ДУМАЕТЕ, что он должен. Из-за этого НИКОГДА не переопределяйте операторы operator&&() и operator||(), и всегда правильно задавайте возвращаемое значение операторов.

Шаг 14 - Двойная диспетчеризация. Продолжение.

В Шаге 4 мы говорили о двойной диспетчеризации. Она очень хорошо подходит при необходимости отображения одних объектов посредством других, но не только; она в общем применима, когда Вам нужно обрабатывать попарные (и более) взаимодействия объектов двух и более разных классов. Получается этакая табличка, на осях которой нарисованы классы, а в ячейках - функции их взаимодействия. Количество функций равно произведению столбцов и строк этой таблички. А если диспетчеризация тройная или выше? Тогда еще умножаем на количество слоев, и дальше и дальше…

Как бы упростить жизнь? А вот так - если взаимодействие двух объектов дает один результат, пусть этим и занимается одна функция. Попробуем перевести на человеческий язык:

Пусть есть класс CTitanic и класс CIceberg. Их карма в том, чтобы столкнуться. Четыре варианта взаимодействия: Столкновение двух Ctitanic не ведет ни к чему, если вообще возможно, двух CIceberg - у них там свои дела, столкновение CTitanic и CIceberg, как известно, к семи Оскарам, и столкновение CIceberg и CTitanic - к тому же самому. То есть функций всего три. Определим взаимодействие этих классов как функцию hit(). Вот код:

#include ‹iostream.h›

// Форвардные объявления

class CTitanic;

class CIceberg;

class CFloating;

// Абстрактный базовый класс

class CFloating {

public:

 virtual void hit(CIceberg&)=0;

 virtual void hit(CTitanic&)=0;

public:

 virtual void hit(CFloating&)=0;

};

// Класс айсберга

class CIceberg {

public:

 virtual void hit(CIceberg&);

 virtual void hit(CTitanic&);

public:

 virtual void hit(CFloating&);

};

// Первая диспетчерская функция

void CIceberg::hit(CFloating& _co) {

 _co.hit(*this);

}

// Две реализации взаимодействия

void CIceberg::hit(CIceberg& _ci) {

 cout ‹‹ "ci+ci" ‹‹ endl;

}

void CIceberg::hit(CTitanic& _ct) {

 cout ‹‹ "ci+co" ‹‹ endl;

}

// Класс Титаника

class CTitanic {

public:

 virtual void hit(CIceberg&);

 virtual void hit(CTitanic&);

public:

 virtual void hit(CFloating&);

};

// Еще одна диспетчерская функция

void CTitanic::hit(CFloating& _co) { _co.hit(*this); }

// А вот эта функция могла бы быть реализацией

// но мы ее тоже делаем диспетчерской;

// в этом фрагменте диспетчеризация тройная.

void CTitanic::hit(CIceberg& _ci) {

 // cout ‹‹ "co+ci" ‹‹ endl; Это могла быть реализация

 _ci.hit(*this);

}

void CTitanic::hit(CTitanic& _ct) {

 cout ‹‹ "co+co" ‹‹ endl;

}

// проверим по быстрому, как работает

int main () {

 CIceberg i1;

 CTitanic t1;

 CIceberg i2;

 CTitanic t2;

 i1.hit(t1);

 i1.hit(i2);

 t1.hit(i1);

 t1.hit(t2);

 return 0;

}

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

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

Есть еще способы уменьшить их количество, основанные на преобразованиях классов - неявных или через конструкторы. Я правда не знаю, что раньше может запутать - количество диспетчерских функций или неявные преобразования; тут, пожалуй, можно только порадоваться появлению в стандарте ограничивающего модификатора explicit, который подавляет неявные вызовы конструкторов.

Увы, двойная диспетчеризация в C++ всегда громоздкая и неудобная вещь, и вряд ли будет другой. Если мы добавляем новые классы в диспетчеризацию, приходится переписывать ранее написанные классы; все классы имеют доступ к функциям друг друга или функции должны быть открытыми.

Это - плата за отсутствие в C++ функций, виртуальных по отношению к 2 и более классам.

Шаг 15 - Как сделать массив из чего угодно.

Массивы и оператор operator[].

Давайте попробуем придумать класс, объекты которого вели бы себя как массивы? Поехали. Решим, что класс внутри себя должен иметь для простоты массив, ну там счетчик элементов… вроде больше нечему там быть. Ну раз так, то возьмем стек из Шага 13, для чистоты эксперимента выкинем спорные перегрузки operator+, operator+= и operator-, а для доступа к элементу пишем функцию int getat (int). Но что получается? Значит, добавление-изъятие мы пишем как функции только ради чистоты стиля, а других мотивов нет? А с доступом к элементу нам вообще ничего не мешает - пусть вместо getat() будет operator[](), а возвращает ссылку - ссылке же можно присвоить значение, а значит, работать будет в обе стороны, и на чтение и на запись!

class CArray {

private:

 int a[100];

 int iTop;

public:

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

 CArray ():iTop(0) {}

 CArray (const CArray& _ca) {

  iTop = _ca.iTop;

  for (int i=0; i++; i ‹100) a[i]= _ca.a[i];

 }

 CArray& operator=(const CArray& _ca) {

  if (this==&_ca) return *this;

  for (int i=0; i++; i ‹100) a[i]= _ca.a[i];

  iTop = _ca.iTop;

  return *this;

 }

 CArray& add (int _i) {a[iTop]=_i; iTop++; return *this;}

 int pop(void) {iTop-; return a[iTop+1];}

 // Две функции доступа к элементам массива

 int& getat (int _i){return a[_i];}

 int& operator[](int _i){return a[_i];}

};

// проверим наши рассуждения

CArray c;

int main() {

 c.add(1);

 c.add(2);

 c.add(3);

 c.add(4);

 c.add(5);

 c.getat(3) = 10;

 c[2]=20;

 return 1;

}

Разумеется, я пропустил ВСЕ детали, и важные и мелкие, но это не главное. Самое главное - последние две функции декларации.

Надеюсь, Вы понимаете значение сделанного? Вы снова Властелин. Allmighty God. А как же? Вы полностью контролируете все и всех. Как назвать того, кто издает законы, по которым живут все без исключения? Творения которого рождаются и умирают лишь по воле его? Нарушившего закон его постигает немедленная и неотвратимая кара? (Да-да, именно, как у Буча там: "сервер, не выполняющий… инварианты Господа нашего…" ой нет, не было такого, но он имел в виду!)

Практически Вы можете проверять значение индекса не меньше 0 и не больше iTop. Можете вместо массива положить указатель на массив int** a, тогда в operator[] возвращать нужно не int& а int*& - а вести себя будет точно так же. Можете вообще читать с диска или с бараньей лопатки. Более того (и это кстати очень важно) перегрузить operator[] не только для int но и чего угодно другого: для строки, float и всего остального, и не один раз. Есть ограничение правда - аргумент может быть только один. Ха, смешные потуги жалкого компилятора, нас уже не остановить:

// Это класс, объединяющий пару аргументов

class pair {

public:

 int x; int y;

 pair(int _x=0, int _y=0):x(_x), y(_y)р {}

};

// Перегруженный operator[]

int& operator[](pair);

//использование.

OurArray[pair(1,2)].OurFunction();

Тормознем немного. Королева в восхищении, но… есть немного проблем.

Шаг 16 - Как сделать массив из чего угодно. Продолжение.

In spring, when woods are getting green,

I'll try and tell You what I mean.

L.Carroll. Through the looking glass.

Проблема собственно в том, что ради такой простой структуры нечего и сыр-бор разводить. Если нам нужен просто массив, можно просто взять его шаблон из STL или MFC. Клянусь, это будет замечательное решение, у Вас будет огромный набор возможностей, да к тому же реализованных компактно и эффективно (в меру); если у Вас нет отклонений в психике, и Вы не порываетесь ежедневно вставить ассемблерный код в прогу на VB, этого будет достаточно. Увы, иногда нужно больше.

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

Наша карта сильно стала похожа на разреженный массив. Отличие в том, что в классическом разреженном массиве между "ключевыми" элементами хранятся нули, а у нас там лежит (как будто) значение предыдущего элемента. Процессы чтения и записи существенно различаются; в предыдущем шаге мы могли работать со ссылкой, читать и записывать ее. Сейчас операция чтения возвращает нам какую-то неопознанную… или неучтенную… шняжку новогоднюю, толку в нее писать никакого, она все равно свежевычисленная. Операция записи пишет. Вещи абсолютно разные, ничего общего. Авторитетные специалисты пишут: "никакого толку от оператора [],… возможности разделить чтение и запись нет… надо писать на BASIC… на бумажечке".

Они не правы.

Выход есть. Нужно взять новогоднюю шняжку, опознать и учесть ее. Потом перегрузить у ней операторы operator[](), operator-›() и оператор приведения типа к элементу массива. Вы узнаете ее? Да это сэр Хьюго Баскервиль собственной персоной, он же Умный Указатель, он же Курсор, он же Proxy-объект! Вот черт, кто бы знал… Далее его именуем Курсором за сходство с аналогом из баз данных.

Так теперь перед кодом давайте самое важное вычленим:

1. Массив возвращает в операторе operator[] курсор.

2. Курсор имеет перегруженный оператор присваивания operator=(), что позволяет нам грамотно обрабатывать вставки и записи в массив.

3. Курсор может неявно преобразовываться к значению элемента массива, что позволяет нам грамотно читать из массива.

4. Курсор имеет перегруженный оператор operator-›(), что позволяет нам читать и… и в общем все, что нужно; смотри предыдущие шаги.

Теперь мы имеем семантический массив. Внутри может быть что угодно, но снаружи он совершенно неотличим, вообще. Элджер справедливо замечает: "внутреннюю реализацию Вы можете сменить даже на последних стадиях разработки". Я справедливо замечаю: "и ни одна… не до…". (Вообще это нам сержант Прищепкин говорил по поводу начищенности пряжки, но и здесь вполне подходит).

Еще по коду: Я написал для примера код, имитирующий базу данных наподобие SQL, потом засунул базу в класс такого массива и все такое… но получилось около 300 строк, и наглядность совсем пропала. Так что беру попроще - связанный список.

class CThat {int a;};

class CCursor;

class CArray;

class CNode;

class CNode {

public:

 int index;

 CThat* that;

 CNode* next;

 CNode (int _index, CThat* _that, CNode* _next): index(_index), that(_that), next(_next) {}

};

class CCursor {

public:

CArray* array;

int index;

CNode* node;

CCursor(CArray* _array, int _index):

array(_array), index(_index), node (NULL){};

CCursor(CArray* _array, CNode* _node):

array(_array), index (_node-›index), node (_node){};

CCursor& operator=(CThat* _that);

operator CThat*();

CThat* operator-›();

};

class CArray {

public:

 CNode* cells;

 CArray(): cells(NULL) {}

 CCursor operator[](int i);

};

CCursor CArray::operator[](int _index) {

 CNode* pNode = cells;

 while (pNode!=NULL) {

  if (pNode-›index -_index) {

   return CCursor(this, pNode);

  } else pNode=pNode-›next;

 }

 return CCursor(this, _index);

}

CCursor& CCursor::operator=(CThat* _that) {

 if (node==NULL) {

  node = new CNode (index, _that, array-›cells);

  array-›cells = node;

 } else {

  node-›that = _that;

 }

 return *this;

}

CCursor::operator CThat*() {

 return node != NULL ? node-›that : NULL;

};

CThat* CCursor::operator-›() {

 if (node == NULL) { throw 1; }

 return node-›that;

}

Шаг 17 - Как НЕ создавать локальные переменные.

Что он сделал? Я не постигаю. Что нибудь особенное есть в этих словах: "Буря мглою…"? ___ Повезло ___ стрелял в него этот белогвардеец ___ и тем обеспечил бессмертие.

М. Булгаков. Мастер и Маргарита.

Лирическое отступление номер 2. Нажмите PageDown, если Вам неинтересно.

2001, апрель, 15.

Спасибо всем, написавшим отклики. Постараюсь проработать еще 3-4 больших темы и возможно бОльшую пачку маленьких идиом и приемов.

Увы, есть ограничивающие факторы: в первую очередь, это - просто тяжелый труд, а иных стимулов, кроме гордыни и тщеславия, нет. Второй фактор - текущее место работы, я подумываю его сменить. Понимаете, напрягают одноэсить, 1C в смысле, и если заставят, то шагам конец, да и деньги опять же; а я человек увлекающийся, и тем, чем занимаюсь, живу в полном смысле. Я вообще за шаги взялся потому, что решил продвинуть статус MCP до MCSD, стал учебники листать-повторять да и увлекся…

Как следствие: Если Вас заинтересовали мои шаги, и у Вас есть свободные вакансии программиста (и интересная, лучше трудная работа), прошу Вас и Ваш HR department (отдел кадров) рассматривать данные шаги как мое резюме.

Да-да, а что Вы хотите - естественно, это реклама…

Так, все, далее - заготовленный текст шага.

Иной раз найдешь какую-нибудь красивую фенечку, поразишься гению человека, ее придумавшего… и остается только жалеть, что не ТЫ это придумал, а ведь мог же, ну что тут такого! С другой стороны, широкое использование идей других людей и есть тот феномен, который позволил так быстро развиться компьютерной индустрии, и в конечном счете дающий нам работу. (Имею в виду конечно покупку Биллом Гейтсом операционки DOS в прошлом тысячелетии).

Ну ладно, будет. Перейдем к делу.

Допустим у Вас есть блажь - запретить конструирование объектов в стеке. Или другими словами - запретить создание локальных переменных. Зачем? Да как зачем - хочется и все… Ну хотя бы затем, чтобы они не удалялись при выходе за скобки. Или опять же, Вы создаете сообщения и толкаете их в очередь на обработку. Или Вы написали свой менеджер памяти (неплохое занятие кстати, позже будем разбирать управление памятью, увидите, сколь сие плодотворно). Вообще, стек и куча (stack и heap) вещи разные, у них разная скорость и вообще много разного. Смешивать никак нельзя. Ясно, для Вас это сейчас не проблема. Даже если не знали раньше, прочитали в шагах:

1. Определяем ВСЕ необходимые конструкторы.

2. ВСЕ конструкторы кладем в private или protected.

3. Рисуем производящую функцю.

Как писал Зощенко, "стою, любуюсь крепкой тарой".

Есть еще один способ. Вы будете смеяться. Или плакать. Придёте в возбуждение. Так что зажгите сигарету загодя и хорошенько затянитесь.

1. Защищаем… деструктор!

2. Рисуем разрушающую функцию.

Vous savez, деструктор только один, да к тому же виртуальный. Эх, жалко нет метакласса… да и зачем нам метакласс, я же читать не умею (авторская разрядка здесь)!

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

Шаг 18 - Управление памятью.

Больше нет возможности обходить эту тему. Это слишком важно. Долго не хотел браться за нее, но она сама взялась за меня.В управлении памятью одна из самых больших проблем (для меня) состоит в том,что у авторов книг по C++ в этом месте случается как бы легкий интеллектуальный сдвиг… И их объяснения становятся похожи на прения на слете экстрасенсов, чародеев и магов. Или как если бы кто взялся объяснять герундий английского языка мне (Альберту Махмутову) по китайски.

В общем, даже простые вопросы оказываются настолько…, что понять их невозможно. Так что я начну потихоньку разбирать самые простые механизмы, без лишнего усложнения.

Вспомните Шаг 12. Что делается, когда компилятор видит ключевое слово new? Сначала выделяется память, и компилятор получает указатель на нее, потом вызывается конструктор; ясно, что где-то в глубине кода конструктор получает указатель на свежую, сырую память, исполняет себя, а потом возвращает указатель обратно клиенту. Как выделяется сырая память? На то есть оператор operator new.

Вот его прототип:

void* operator new(size_t);

Ничего сложного. Несколько необычно получает параметр, правда, но это только на первый взгляд, на то он и оператор. Параметр - это размер объекта; похоже на то, как если бы мы написали (но неверно разумеется):

CClass* cc = operator new(sizeof(CClass));

Зато мы можем перегрузить operator new (что не удивительно), да к тому же добавить параметров (что уже лучше). Главное, чтобы первый параметр был все равно size_t - размер объекта, а то из спецификаци языка вылетим. Обратите внимание - перегружается оператор operator new(), а не ключевое слово new, оно же элемент синтаксиса, можно сказать. Прототип перегрузки и пример использования:

void* operator new(size_t, int);

// V

// --‹-‹-‹---

// ¦

// V

CClass* cc = new(234) CClass;

У меня ни малейшего понятия, зачем Вы суете сюда int. Лично у меня на параметр свои виды. Я собираюсь пульнуть туда как раз тот указатель, который надо вернуть. А больше ничего не делать. Чтоб память НЕ ВЫДЕЛЯЛАСЬ. Потому что я намереваюсь ее раздобыть сам.

// Прототип оператора

void* operator new(size_t, void* buffer) {return buffer}

// Использование. Получаем шмат памяти

char* piece_of_memory[1000000000000];

// делаем вызов.

CClass* cc = new(piece_of_memory) CClass;

Мрачная картина. Душераздирающее зрелище. Но результат на лице: Это - менеджер памяти. Самый натуральный. Буферизованный оператор operator new. Виртуальный конструктор (не знаю почему; учитывая, что в официальных справочниках Microsoft разъясняется, что СИСТЕМНЫЙ диск это тот, с которого ЗАГРУЖАЕМСЯ, а ЗАГРУЗОЧНЫЙ тот, на котором СИСТЕМА, меня мало что удивляет в терминологиях).

Шаг 19 - Управление памятью. Продолжение 1.

Бог: "Я стер всякую жизнь. Впочем, я ничего не уничтожил. Я просто воссоединил в Себе частицы Себя. У меня на планете было множество типов с безумными глазами, которые болтали насчет слияния со Мной. Вот они и слились."

Кармоди: "Им это понравилось?"

Бог: "Откуда я знаю?"

Р. Шекли. Координаты чудес.

А что случается, когда компилятор видит ключевое слово delete? А кстати то же самое, только в обратном порядке. Сначала вызывает деструктор, потом вызывает operator delete(), прототип коего:

void operator delete (void* to_free_mem);

Параметр есть указатель на освобождаемую память. Да, но в нашем примере НЕ НАДО ничего освобождать. Мы сами добыли память, сами и освободим. Что делать? Вообще не употреблять delete (ключевое слово, не оператор). А употребить только деструктор.

ourObject-›~CClass();

Но с другой стороны, не следует навечно занимать память.Это нехорошо. Отдавать нужно так же, как и брали. Брали malloc() - отдаем через free(). Брали в стеке - ничего не делаем, само освободится. А может, брали через operator new() - тогда освобождаем через operator delete(). Вы наверное поняли, что сырую память можно взять через чистый оператор operator new():

// взяли память

char* piece_of_memory = operator new(100000000);

// положили на место.

operator delete (piece_of_memory);

Вроде управились со всем. Надо только запомнить, что всегда (превсегда) выделение и освобождение памяти должно идти только через комплементарные пары функций и механизмов. Потому что они (механизмы) совершенно друг друга не понимают. И память, выделенная через malloc, с точки зрения пары new-delete совсем не выделенная. А удаленная через free не удаленная. И наоборот. Полная несовместимость во все стороны.

А что нам проку от управления памятью, спросите Вы? Да хотя бы скорость. Когда выполняется operator new(), программа в общем случае обращается к операционной системе. Операционка, как Вы понимаете, не в восторге от толкающихся вокруг нее процессов и потоков, наперебой просящих у нее кусочки памяти, и выдает память в порядке очереди, к тому же у нее есть любимчики, да еще и себе нужно оставить… Ведет себя в точности так же, как нормальный начальник компьютерного отдела при распределении новой техники. Так что выгоднее сразу хапнуть достаточное количество памяти, а потом самостоятельно ее раздавать объектам.

А что касается освобождения памяти в нашем примере, то это вообще ураган: не нужно разрушать объекты по отдельности; Вы просто хрясь! - и освобождаете буфер целиком. Интересно, что чувствуют при этом объекты?

Конечно, нужно немного усложнить код, чем наши жалкие две строки. Следует "шмат памяти" оформить в виде класса, так чтобы выдавать память объектам последовательно. У объектов перегрузить операторы operator new() так, чтобы память бралась где нам надо, и operator delete() так чтобы он ничего не делал. И "шмат" называть "пулом". А то не поймут.

Я лишь чуть-чуть усложняю класс, только чтоб показать.

#include ‹stdlib.h›

// Класс пула

class CPool {

public:

 static char buffer[8096]; // статический буфер

 static char* position; // текущая позиция

 static void* getSomeMemory(size_t); // получить немного памяти

};

// вот получаем немного памяти.

void* CPool::getSomeMemory(size_t bytes) {

 void* ret_val = position; // вернуть надо текущую позицию.

 position+=bytes; // а счетчик увеличить

 return ret_val;

}

// Это так… эксперимент.

// Класс с собственным управлением памятью.

class CThat {

private:

 int m_some_number; // не знаю что.

public:

 // перегруженные operator new, operaton delete

 void* operator new(size_t bytes) { return CPool::getSomeMemory(bytes); }

 void operator delete(void*) {}

};

// инициализация статических членов.

char CPool::buffer[8096];

char* CPool::position = CPool::buffer;

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

Несколько строк занудства.

Операционка неохотно берет себе память обратно. Возможно, освобожденный фрагмент вообще останется в ведении менеджера памяти самой программы, до ее завершения. Но конечно крупные куски она заглатывает тут же. Если возитесь с мелочью, проверьте этот момент на всякий случай; нет ничего приятнее свопа или уборки мусора в нужное время!

Глобальный оператор ::operator new() и глобальный оператор ::operator delete() не трогайте. Проще и намного умнее перегружать операторы в классах.

new, operator new и конструктор, а так же delete, operator delete и деструктор - АБСОЛЮТНО разные вещи. Как мы уже выяснили, их можно вызывать по отдельности. Не давайте себя запутать, если кто-нибудь будет говорить об операторе new - такого не бывает, бывает или оператор operator new(), или ключевое слово new.

Шаг 20 - Временные объекты. Неявные вызовы конструкторов и их подавление.

Не удается углубиться в какую-либо тему. Приходится касаться по верхам, потом переключаться на что-то другое. С другой стороны, может это и правильно, часто достаточно только знать, что есть ТАКОЕ решение, а изучить детально можно и позже, когда сделаешь окончательный выбор. Да и не очень это интересно - что за радость переписать двадцать страниц из учебника, или перевести статью какого-нибудь доктора CS? Объяснения которого в точности так же логичны, как рассказ Ивана Бездомного насчет "…Берлиоза зарезало трамваем, а тот заранее знал про масло, которое Аннушка пролила" - то есть логика и связь есть - но только для него самого.

Чтож, к делу.

А кто такие временные объекты? Локальные переменные с замечательными именами a, a1, a2, a_1, tmp1, tmp2? (Кстати ни за что не берите на работу болванов, которые так именуют переменные; пусть на FoxPro пишут. Думаю написать про это отдельный Шаг - причины для немедленного увольнения.) Вообще-то нет. Временные объекты - это объекты, которые не имеют имен в коде и неявно создаются компилятором. Поскольку неявные "подарки" компилятора иногда бывают очень некстати, лучше заранее знать, чего можно ожидать от него. А зачем он их создает? Первое - при выполнении преобразования типов, для вызова функций. Второе - для возвращения объекта из функции.

Придется немного поэкспериментировать. Поэтому скопируйте себе код небольшого класса:

#include ‹iostream.h›

class CInt {

private:

 int m_i;

 int m_instance;

 static int iCounter;

public:

 CInt (int);

 CInt (const CInt&);

 ~CInt ();

 CInt operator+ (const CInt&);

 CInt& operator+=(const CInt&);

 CInt& operator= (const CInt&); // operator int ();

};

int CInt::iCounter = 0;

CInt::CInt (int _i=0): m_i(_i) {

 m_instance = ++iCounter;

 cout‹‹"defa constr " ‹‹ m_instance ‹‹ " "‹‹ m_i‹‹ endl;

}

CInt::CInt (const CInt& _i): m_i(_i.m_i) {

 m_instance = ++iCounter;

 cout‹‹"copy constr " ‹‹ m_instance ‹‹ " "‹‹ m_i‹‹ endl;

}

CInt::~CInt () {

 iCounter--;

 cout ‹‹"~destructor " ‹‹ m_instance ‹‹ " "‹‹ m_i‹‹ endl;

}

CInt& CInt::operator=(const CInt& _i) {

 m_i = _i.m_i;

 cout ‹‹"assert oper " ‹‹ m_instance ‹‹ " "‹‹ m_i‹‹ endl;

 return *this;

}

CInt CInt::operator+(const CInt& _i) {

 cout‹‹"addi operat " ‹‹ m_instance ‹‹ " "‹‹ m_i‹‹ endl;

 return CInt (m_i + _i.m_i);

}

CInt& CInt::operator+= (const CInt& _i) {

 m_i += _i.m_i;

 cout‹‹"autoadd ope " ‹‹ m_instance ‹‹ " "‹‹ m_i‹‹ endl;

 return *this;

}

/*

CInt::operator int () {

 return m_i;

}

*/

int main (void) {

 cout ‹‹ "start" ‹‹ endl;

 // Позиция 1.

 CInt i_test = CInt (2) + CInt (4);

 cout ‹‹ "firststop" ‹‹ endl;

 {

  // Позиция 2.

 }

 cout ‹‹ "thirdstop" ‹‹ endl;

 return 0;

}

Пояснения: класс представляет целые числа. Определены конструктор по умолчанию и копирования, присваивание, пара арифметических операторов, оператор преобразования в int (закомментирован). В функции main отмечены 2 позиции для экспериментов.

Еще момент - вызвала затруднения форма конструктора со списком инициализации, типа этой:

CClass::CClass (int _a, int _b, int _c) : m_a(_a), m_bc(_b, _c) {}

Тут нет ничего такого, просто конструкторы членов-переменных и базовых классов вызываются явно со своими параметрами, это выгоднее чем создавать пустые, а потом в теле конструктора выполнять ПРИСВАИВАНИЕ при помощи оператора operator=().

Попробуем в позицию 1 поставить:

CInt i_test = 1 + 2;

Вызовется только один конструктор - по умолчанию. Это одно и то же:

CInt i_test = 3; ‹=====› CInt i_test(3);

Попробуем так

CInt i_test;

i_test = CInt(1) + CInt(2);

Сначала создается первый объект, потом левый операнд, потом правый, потом результат, потом выполняется присваивание, потом оба операнда и результат удаляются, сразу после использования. Всего четыре объекта. Один - временный.

А если записать в одну строку?

CInt i_test = CInt(1) + CInt(2);

Подумаем немного. Сначала левый операнд, потом правый, потом результат, потом создается объект а при помощи конструктора копирования. Всего четыре. Три по умолчанию, один копирования. Лепота.

ДА НИЧЕГО ТАКОГО! Компилятору плевать на нашу логику. Он берет результат, и превращает его в i_test. Оптимизирует. Три вызова дефолт конструктора, и ни одного временного объекта.

Я встречал этот вопрос на BrainBench и на ProveIt.

А еще давайте сравним два варианта кода:

CInt i_test = CInt(1) + CInt(2) + CInt (4) + CInt(8);

и

CInt i_test = CInt (1);

i_test+=CInt(2);

i_test+=CInt(4);

i_test+=CInt(8);

Видите? В первом варианте конструктор вызывается 7 раз, а во втором 4.

С явными вызовами конструкторов все понятно. А неявные?

CInt i_test = CInt(1) + 2;

Компилятор пытается найти подходящий оператор operator+, но его нет для примитивного int. Тогда он считает, что конструктор CInt(int) - вполне подходящий способ преобразования, и на место двойки ставит CInt(2).

Теперь раскройте оператор operator int. Хочется ожидать разумного поведения компилятора; но увы - в нашем примере этого ожидать не стоит. Есть два способа вычислить последнее выражение - и компилятор не знает что выбрать, и подыхает, как Буриданов осел между двумя кучами сена. Чтобы помочь компилятору, нужно один вариант блокировать. Как?

Не определять оператор преобразования, а определять вместо них функции, типа operator int() ‹-› asInt()

В определении конструктора использовать модификатор explicit для подавления неявных вызовов.

Использовать proxy-object - промежуточный объект наподобие курсора из Шага 16, все назначение которого - быть другим объектом когда нужно, и не быть им, когда не нужно. Словами больно заумно, проще нарисовать код.

// Класс прокси-объекта

class CProxyInt {

 friend class CInt;

private:

 int m_i;

public:

 CProxyInt (int _i): m_i(_i) {}

 int getInt () const { return m_i; }

};

// Предыдущий класс инт.

class CInt {

 friend class CProxyInt;

private:

 int m_i;

 int m_instance;

 static int iCounter;

public:

 // Конструктор по умолчанию изменен

 CInt (CProxyInt);

 CInt (const CInt&);

 ~CInt();

 CInt operator+(const CInt&);

 CInt& operator+=(const CInt&);

 CInt& operator= (const CInt&);

// operator int ();

};

int CInt::iCounter = 0;

// Реализация конструктора, вместо инта стоит прокси

CInt::CInt (CProxyInt _i=0): m_i(_i.m_i) {

 m_instance = ++iCounter;

 cout‹‹"defa constr " ‹‹ m_instance ‹‹ " "‹‹ m_i ‹‹ endl;

}

CInt a(5); // Это компилируется нормально

CInt a = 5; // А это нет. И все неявные вызовы тоже.

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

В этом смысле smart-указатель несомненно тоже рroxy, (уменьш. ласк. проксятник, проксятничек).

Шаг 21 - О тщете сущего.

Прежде чем использовать приемы, описанные в предыдущих Шагах, тщательно подумайте - надо ли Вам это? (Примеры с памятью еще и упрощены до свинства, не вздумайте применять в таком виде).

Средний компилятор управляет памятью примерно так, как описано в Шаге 18-19, а именно запрашивает большие куски по необходимости у операционки через calloc(), потом раздает кусочки объектам. Если объект уничтожен, то (по возможности) использует свободное место повторно. Память вернется в операционку только после того, как все объекты в ней уничтожены. Если мы будем писать свой менеджер памяти не почитав теории для начала, то вернее всего ухудшим использование памяти.

Неявные преобразования через конструкторы и операторы преобразований хороши, конечно. Но почему-то пришлось вводить ограничения на них. Чтоб неявно не вызывались. Сколь мне известно, компания Borland/Inprise собирась вводить в Delphi 4/5 перегрузку операторов, но как-то передумала…

Неявные объекты в большинстве случаев не мешают нам жить. Более того, запись в предыдущем шаге, где вызывается 7 конструкторов вместо 4, более читабельна-сопровождабельна, красива, соответствует духу и букве C++ (семантике и синтаксису). Если функция исполняется в программе раз в час, неважно, сколько раз вызовется в ней конструктор - 4 или 44. Скринсавер вообще выполняет море абсолютно бесполезных и сверхсложных вычислений - Вам это мешает?

А что касается виртуальных функций, то и MFC, и OWL, и VCL - все используют их как можно реже - на то веские причины! Если бы все функции в них были виртуальными, то с полметра памяти уходило бы в каждой программе только на поддержание виртуальных таблиц, да по лишнему указателю в каждом объекте.

Есть такое правило "80-20": 20 процентов кода вызывает 80 процентов затруднений, 20 процентов кода занимает 80 процентов процессорного времени. Возможно, оно даже сильнее - "90-10". В данном Шаге это значит - не зашивайтесь в "дешевой" части кода.

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

Шаг 22 - Классы объектов, поддерживающие транзакции.

Бывает особенно приятно, когда занимаешься теорией. Занимаешься, думаешь: "ну никакой связи с жизнью, хоть бы минимум пользы"… и вдруг раз! и польза является во всей своей красе, блистая в лучах солнца и хрустя пачками денег. Что чувствовал Менделеев, когда после долгих изысканий, жутких таблиц, являвшихся ему в ночных кошмарах, вдруг получил-таки нормальную, не паленую, 40-градусную водку? Или Эйлер, когда, после терзаний и депрессий, извлек таки сопротивляющийся, визжащий и цепляющийся щупальцами и жвалами квадратный корень из минус единицы? К чему это я? А вот к чему: концепция smart-указателей может предложить простые и прозрачные решения для некоторых сложных задач; и если Вы считаете, что поддержка транзакций (а так же многоуровневой отмены и повтора) есть сложная задача, то смарты помогут Вам с замечательной легкостью.

Вспомним для начала, что делает транзакция:

1. Если транзакция началась, то все изменения в ней либо вносятся вместе, либо не вносятся вообще (это вообще определение транзакции).

2. Если клиент начал и не завершил транзакцию, то другие клиенты не видят его изменений.

3. Две транзакции не могут одновременно изменять одни и те же данные.

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

#include ‹iostream.h›

// Некий скромный класс.

class CSomeClass {

public:

 int x;

 int y;

};

// Его оплетка: smart-pointer с поддержкой отмены.

class CSimpleTr {

public:

 CSomeClass* that; // текущее значение

 CSomeClass* previos; // предыдущее значение

public:

 // конструктор-деструктор-присваивание-копирование

 CSimpleTr(): previos(NULL), that(new CSomeClass) {}

 CSimpleTr(const CSimpleTr& _st): that(new CSomeClass(*(_st.that))), previos(NULL) {}

 ~CSimpleTr() {delete that; delete previos;}

 CSimpleTr& operator=(const CSimpleTr& _st) {

  if (this!=&_st) {

   delete that;

   that = new CSomeClass(*(_st.that));

  }

  return *this;

 }

 // начало транзакции

 void BeginTrans() {

  delete previos;

  previos = that;

  that = new CSomeClass(*previos);

 }

 // закрепление

 void Commit() {

  delete previos;

  previos = NULL;

 }

 // отмена транзакции

 void Rollback() {

  if (previos != NULL) {

   delete that;

   that = previos;

   previos = NULL;

  }

 }

 // реализация указателя

 CSomeClass* operator-›() { return that; }

};

int main (void) {

 // проверим быстренько

 CSimpleTr lvPair;

 lvPair-›x = 5;

 lvPair-›y = 8;

 lvPair.BeginTrans();

 lvPair-›x = 7;

 lvPair-›y = 11;

 lvPair.Rollback();

 lvPair.BeginTrans();

 lvPair-›x = 7;

 lvPair-›y = 11;

 lvPair.Commit();

 return 0;

}

Что может быть проще? Семантика значений, очевидно. Классы должны иметь полный набор обязательных функций, как обычно; в нашем случае класс CSomeClass больно уж тривиален, поэтому сойдет и так. Класс CSimpleTr имеет смысл переписать в виде шаблона, если не хотите его заново переписывать для каждого нового клиента, да еще добавить функцию isStarted(). Функциональность на Ваш вкус и фантазию. MTS, например, восстановит отмененную транзакцию, если Вы после отмены сделаете закрепление: SetAbort(); SetComplete(); сработает так, как будто SetAbort(); не было вовсе.

Шаг 23 - Классы объектов, поддерживающие транзакции. Продолжение.

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

1. Какую структуру будем использовать в качестве коллекции состояний? Можно взять стек, можно кольцевой буфер, а можно и карту (словарь, хэш-таблицу); стек явно проще, зато за кольцевым буфером можно не следить вообще, пусть устаревшие состояния пропадают бесследно (конечно по желанию).

2. Определимся с семантикой. Смешивать значения и указатели не стоит, верный путь заработать себе геморрой. У меня не оказалось под рукой подходящего стека, и я написал для этого Шага два варианта - один хранит значения, другой - указатели; первый стек сначала казался проще, но использующий его класс указателя оказался ощутимо сложнее по простой причине - функции стека с указателями могут возвращать NULL, а это совсем немало.

3. Оформим все в виде шаблонов; вообще контейнеры просто просятся быть шаблонами, а smart-указатели несомненно являются контейнерами.

Код ниже, а сейчас пояснения:

Класс CType просто проверочный, чтобы вкладывать в шаблоны; так проще отлаживать шаблон: сначала сделать контейнер-не-шаблон для класса Type, а потом просто приписать сверху объявления строку template‹Type›. Шаблон класса ampstack‹Type› - шаблон стека указателей; push сохраняет указатель, pop достает верхний указатель, isEmpty проверяет на пустоту, emptyAll очищает.

Шаблон класса MLTrans - наконец тот, который нам нужен. Указатель that хранит текущее значение, Push сохраняет текущее значение, PopOne делает однократную отмену, Rollback отменяет все изменения, до первоначального, Commit удаляет историю.

// Это маленький класс для проверки

class CType {

 int a;

public:

 void set (int _a) { a=_a; }

 int get (void) { return a; }

};

// Шаблон стека

template ‹class Type›

class ampstack {

private:

 int iTop; // верх стека

 int iSize; // размер стека

 Type** array; // массив указателей

public:

 // Конструктор-деструктор

 ampstack(int size=10) : iTop(0), iSize(size), array(new Type*[size]) {}

 ~ampstack() {

  for (int iCounter = 0; iCounter ‹ iTop; iCounter ++)

   if (*(array+iCounter)!= NULL) delete *(array+iCounter);

  delete[] array;

 }

 // Управление стеком

 // Направить указатель в стек

 void push (Type* _t) { array[iTop++]=_t; }

 // Вынуть указатель из стека

 Type* pop (void) {

  if (iTop == 0) return NULL;

  else return array[--iTop];

 }

 // Стек пуст?

 int isEmpty (void) { return iTop==0; }

 // Очистить стек

 void emptyAll (void) {

  for (int iCounter = 0; iCounter ‹ iTop; iCounter ++)

   if (*(array+iCounter)!= NULL) delete *(array+iCounter);

  iTop = 0;

 }

};

// Шаблон класса с многоуровневой отменой

template ‹class Type›

class MLTrans {

 typedef ampstack‹Type› stack;

private:

 Type* that; // Текущее значение

 stack history; // контейнер предыдущих значений

public:

 // конструктор-деструктор

 MLTrans(): that(new Type) {}

 ~MLTrans () { delete that; }

 // Сохранение текущего значения, aналог SAVE TRANSACTION в SQL серверах

 void Push() {

  history.push(that);

  that = new Type(*that);

 }

 // удаление промежуточных состояний

 void Commit () { history.emptyAll(); }

 // Откат на одну позицию; уничтожает текущее значение.

 void PopOne() {

  if (!history.isEmpty()) {

   delete that;

   that = history.pop();

  }

 }

 // Откат к началу транзакции.

 void Rollback() {

  Type* old = history.pop();

  Type* older = NULL;

  if (old!= NULL) {

   while ((older = history.pop())!= NULL) {

    delete old;

    old = older;

   }

   delete that;

   that = old;

  }

 }

 // Переопределенный operator-›

 Type* operator-›() { return that; }

}

// проверим работу

int main() {

 int t;

 MLTrans‹CType› a;

 a-›set(5);

 t = a-›get();

 a.Push();

 a-›set(6);

 t = a-›get();

 a.Push();

 t = a-›get();

 a-›set(7);

 t = a-›get();

 a.Push();

 t = a-›get();

 a-›set(9);

 t = a-›get();

// a.Push();

 t = a-›get();

 a.PopOne();

 t = a-›get();

 a.Rollback();

 t = a-›get();

 return 0;

}

Шаг 24 - Как создавать ТОЛЬКО локальные переменные.

В Шаге 17 мы изыскали способ подавить создание локальных переменных. Решим обратную задачу - как подавить иные способы их создания. А какие иные? Любые другие способы предполагают вызов оператора operator new() для выделения памяти и потом вызов конструктора. Значит, надо объявить operator new() закрытым членом класса, да и все. Ничего в нем делать не надо, а сразу назад. Попробуем?

class CNoHeap {

public:

 int a;

private:

 void* operator new(size_t size) { return NULL; }

};

int main () {

/*

CNoHeap* firstTestNoHeap = new CNoHeap; // Не откомпилируется

*/

 CNoHeap secondTestNoHeap; // А это пожалуйста.

 return 0;

}

Теперь, если определить макрос:

#define DECLARE_LOCAL \

 private: \

 void* operator new(size_t size) { return NULL; }

и потом вкладывать его во всякие разные объекты, отвечающие за захват и освобождение ресурсов, то получится весьма удобно; Вы ГАРАНТИРОВАННО освободите любые ресурсы, захваченные в конструкторе и освобождаемые в деструкторе, в том числе в исключении. В любом случае, всякое ограничение уменьшает энтропию.

Для Шага 17, где мы рисовали производящие и разрушающие функции, тоже можно нарисовать макрос… и назвать его DECLARE_DYNCREATE. То есть, я хочу сказать, что Вы можете аккуратно переписать нужное из него в свою версию, а в результате получите

class CSomeClass {

 DECLARE_NOLOCAL

public:

 bool Initialize (param list);

};

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

Шаг 25 - Как сделать виртуальной свободную функцию.

Чаще всего этот прием я видел в отношении оператора operator‹‹. Точнее, не чаще, а всегда. На нем и разберем. Пусть у нас есть иерархия классов, и мы хотим определить диагностическую функцию Dump(). Она должна вываливать диагностику в заданное что-то (CDestination). У нас есть два варианта: или сделать функцию виртуальной в иерархии классов:

class CBase {

 virtual void Dump(CDestination& ds) = 0;

};

class CFirst: public CBase {

 void Dump (CDestination& ds);

};

class CSecond: public CBase {

 void Dump (CDestination& ds);

};

Или перегружать ее для каждого класса иерархии или в классе, или в свободной функции:

CDestination {

 void Dump (CFirst& fs);

 void Dump (CSecond& sc);

};

void Dump (CDestination& ds, CThird& td);

void Dump (CDestination& ds, CFourth& fr);

Ясно, первый вариант предпочтительнее. Во-первых, он обеспечивает полиморфное поведение. Во-вторых, своей диагностикой класс занимается сам, что тоже большой плюс. А второй способ почти невозможен: переписывать класс вывода каждый раз при появлении нового потомка в иерархии нереально (в двойной диспетчеризации дело другое, там просто нет иного выхода); в конце концов, он может быть в купленной библиотеке.

Но у второго варианта есть одно преимущество: функцию Dump() можно обозвать оператором operator‹‹, и это будет выглядеть весьма презентабельно:

// Это декларация

CDestination {

 CDestination& operator‹‹ (CFirst& fs);

};

CDestination& operator‹‹ (CDestination& ds, CSecond& sc);

// А это применение

dStream ‹‹ dObject;

Как сделать так, чтобы сохранить замечательное полиморфное поведение первого варианта, и применить эту радость идиота operator‹‹? Легко: пусть operator‹‹ вместо реальной работы просто вызывает виртуальную Dump(). Именно так сделано в MFC - объект afxDump вызывает виртуальную Dump() именно через operator‹‹. (Можно что угодно говорить про Microsoft, но факт есть факт - огромное число полезных и интересных приемов использовано в их продуктах и "… взять их у нее - наша задача!").

#include ‹iostream.h›

class CNoChange;

class CBase {

public:

 virtual void passTo (CNoChange& _cb) { cout ‹‹ "base passed" ‹‹ endl; }

};

class CFirst: public CBase {

public:

 void passTo (CNoChange& _cb) { cout ‹‹ "first passed" ‹‹ endl; }

};

class CSecond: public CBase {

public:

 void passTo (CNoChange& _cb) { cout ‹‹ "second passed" ‹‹ endl; }

};

class CNoChange {

public:

 int a;

 // Это вариант с оператором - членом класса.

 CNoChange& operator‹‹ (CBase& _cb) { _cb.passTo(*this); return *this; }

};

// а это - свободная функция.

//CNoChange& operator‹‹ (CNoChange& _nc, CBase& _cb)

// {_cb.passTo(_nc); return _nc;};

// проверить надо.

int main() {

 CNoChange nc;

 CFirst fs;

 CSecond sc;

 nc‹‹fs;

 nc‹‹sc;

 return 0;

}

Шаг 26 - Как сделать массив из чего угодно. Продолжение 2.

Итераторы.

В Шагах 15 и 16 мы повозились с имитацией массива (коллекцией). Мы добились нормальной работы при чтении и записи в ячейки массива. Но работа с массивом этим не ограничивается. Вот захочется нам сделать что-то со всеми элементами массива, а он индексирован по строке.

// Бред

for (string cCounter= "a"; a ‹ "zzzz"; a++) array.[cCounter].doit();

Нет, это неправильно. Нужно сделать так, чтобы коллекция сама себя перебирала.

CIndex index = array.getStart();

while (!array.eof()) {

 index = array.getIndex ();

 array[index].doIt();

 array.getNext();

};

Ну вот, на что-то похоже. Появился некий элемент index класса CIndex, без которого в принципе можно обойтись, если коллекция будет хранить текущее значение перебора внутри себя. Но вот беда - если вдруг коллекцию захотят перебрать разные клиенты? Ну глобальная она, существует вместе с программой, а обращаются к ней разные объекты, как себя перебрать бедной коллекции? В общем, подход тут такой же, как и в жизни: тебе надо, ты и шевелись, в смысле перебирай. Упомянутый выше index тут как нельзя кстати. Называем его Зингельшухером… (oops!) Простите - итератором, объявляем его дружественным коллекции, прописываем в него текущую позицию, пишем скромный набор функций навигации типа goFirst, goNext, isLast. В зависимости от того, где мы их пишем, итератор будет или активным - если функции навигации в нем, или пассивным - если они лежат в коллекции.

Итак, что делаем: в шаблон ampstack‹Type› из Шага 23 вписываем дружбу к классу итератора:

friend class ampIter;

и сам шаблон класса итератора:

// Класс итератора, дружественный нашему стеку.

template ‹class Type›

class ampIter {

private:

 ampstack‹Type›* m_stack;

 int iPosition;

public:

 ampIter(ampstack‹Type›* _as = NULL) : m_stack(_as), iPosition (0) {}

 int isLast(void) { return iPosition + 1 - m_stack-›iTop; }

 void moveStart(void) {iPosition = 0; }

 Type* moveNext(void) { return m_stack-›array[iPosition++]; }

};

Итераторы - это тема, граничащая с безумием. Мы вовремя остановились на активном итераторе, шаблоне, не вложенном, с семантикой указателей. А ведь их можно вкладывать (т.е. объявлять класс итератора внутри класса коллекции), связывать с курсорами, перегружать их операторы, изменять семантику, вводить многопоточность, создавать внутри (!) итератора мгновенную частную копию коллекции и это только начало. По счастью, о нас уже позаботился Алексей Степанов, и подарил нам Библиотеку Стандартных Шаблонов - Standart Template Library, полную итераторов, равно коллекций и алгоритмов. Немного о них можно почитать на этом же сайте в разделе VC++-›STL у Артема Каева, а много - в MSDN.

Так же добавлю, что пользуюсь при подготовке Шагов компилятором BC3.1, а он поддерживает шаблоны не вполне так, как это делают современные компиляторы. То есть, если Вы просто скопируете код, вероятно он сразу даже не откомпилируется. Так что предупреждаю - если собираетесь пользоваться шаблонами - проверьте, что на эту тему думает компилятор (а так же насчет исключений и операторов вида xxxxxxx_cast‹›()).

Мне же итератор нужен был исключительно для следующих Шагов, а совпадения фамилий, характеров и событий прошу считать случайными.

Шаг 27 - Умные указатели. Перегрузка operator*, operator(),operator-›*.

Пробегая по верхам интересных идиом я упустил одну важную вещь. Поначалу она была не так важна, но пришло время замучать и ее. Я имею в виду то, что наши замечательно умные указатели, smart pointers, вообще-то имеют неполную семантику. То есть, они не полностью имитируют обычные, настоящие указатели. За примерами не надо ходить далеко - попробуем разыменовать смарт или вызвать функцию по указателю:

obj = *(smart_ptr);

(obj-›*ptr_to_funct) (some_parameter);

С первой проблемой рассчитаться легко. Если Вы НЕ читаете сейчас этот Шаг, не беспокойтесь - решение придет само, в тот момент, когда задача возникнет.

//Ясно, это реализации перегруженных операторов-селекторов.

CSmth* operator-›() const { return prt_real; }

CSmth& operator* () const { return *ptr_real; }

operator CSmth* () const { return ptr_real; }

А что вторая проблема? Да, тут ситуация намного серьезнее, и если Вы опять-таки не читаете этот Шаг, то нужно немедленно прочесть его - или первоисточник - статью Мейерса в Dr. Dobb's Journal. Только там придется продираться через тучные стада шаблонов и долгих рассуждений. Без шаблона конечно не обойтись, но нужно ухватить хотя бы идею. Поэтому сделаем так, как нормальный человек читает детективы Марининой: первые и последние две страницы.

Сначала, кто такой operator-›*. Это который вызывает функцию-член по указателю. Такую функцию нужно вызывать с указанием объекта, если из другой функции-члена, то в виде (this-›*mpf)() или (*this).*mpf().

// Этот класс используется так же дальше

class CSmth {

public:

 int a;

 int pf (void) {return a;}

};

typedef int (CSmth::*PF)(void);

Если мы нарисуем умный указатель на объект класса CSmth, определять operator-›*() нужно самостоятельно. Что он должен вернуть? Нечто такое, к чему можно применить operator(). То есть, это снова proxy-объект. Мейерс называет его "незавершенный вызов функции-члена" (Pending Member Function Calling). Он должен знать, к какому объекту применяется, и знать об указателе на функцию, то есть он должен иметь в себе указатели на них обоих, и инициализировать их в конструкторе. А operator() должен возвращать уже нужный нам int, или все что угодно другое, что может вернуть указываемая функция.

// класс незавершенного вызова. Это самое важное.

class pmfc {

private:

 // два указателя - на объект и на функцию

 CSmth* m_smth;

 PF m_pfunct;

public:

 // конструктор

 pmfc (CSmth*& _smth, PF& _pfunct) : m_smth(_smth), m_pfunct(_pfunct) {}

 // вызов конечной функции из оператора ()

 int operator()() const { return (m_smth-›*m_pfunct)(); }

};

// класс умного указателя.

class CPtr {

private:

 CSmth* a;

public:

 CPtr() { a = new CSmth(); }

 ~CPtr() { delete a; }

 CSmth* operator-›() const { return a; }

 CSmth& operator* () const { return *a; }

 operator CSmth* () const { return a; }

 // возвращает PMFC. Это тоже важно.

 pmfc operator-›*(PF _pf) { return pmfc (a, _pf); }

};

// проверим все

int main() {

 CPtr t;

 t-›a = 10;

 // заодно проверим operator*

 (*t).a = 16;

 int b = 0;

 // получили указатель на функцию.

 PF lpF =&CSmth::pf;

 // вызвали функцию по указателю при помощи нашей конструкции

 b = (t-›*lpF)();

 return 0;

}

С тоской взглянув на полученный результат, сразу осознаешь, что без шаблонов не обойтись - ведь нужно обслуживать разные типы указателей на функции. Но зато мы минимум знаем, как решать эту проблему. Еще раз испытали proxy-объекты. Потрогали указатели на функции и функции члены. Перегрузили операторы * и (). И если встанет проблема - то знаем, где искать решение (у Скотта Мейерса).

Шаг 28 - Классы объектов, поддерживающие транзакции. Продолжение 2.

Классы объектов, хранящие состояния, получились очень неплохие - при минимальных интеллектуальных затратах, хотя о транзакциях говорить рано: для транзакций они недостаточно кислотные. (ACID - Atomic, Consistent, Isolated, Durable). Не хватает вот чего:

1. Объекты, задействованные в транзакции, блокируются на запись.

2. Объекты, задействованные в транзакции, представляют другим клиентам свое состояние до транзакции.

Мы уже понимаем общий принцип: если нужна дополнительная логика - вынесите ее на отдельный уровень. Что означает это в нашем случае? То, что 1: транзакция должна быть представлена отдельным уровнем - отдельным классом; 2: объекты, задействованные в транзакции, должны поддерживать специальный стандартный интерфейс, за который транзакция должна ими рулить. То есть, они либо должны быть порождены от специального абстрактного базового класса, либо они должны быть упакованы в специальный смарт-указатель - делающий то же самое.

Все остальное - дело техники. Сразу поясняю код: класс CLockable (базовый) содержит указатель на транзакцию, к которой принадлежит в данный момент, а так же чистые виртуальные функции rollback и commit, назначение которых очевидно. Класс CTransaction представляет собой транзакцию, и содержит в себе список задействованных объектов - затем чтобы роллбачить или коммитить их все вместе, да чтоб на ходу можно проверить - принадлежит ли объект некоей транзакции или нет. Функция addLock() добавляет объект к транзакции, то есть распространяет свое действие на него, тем самым блокируя изменения со стороны других клиентов. После использования объекты автоматически разрегистрируются.

Хочу еще раз напомнить о принципе, который в этом Шаге формулируется первый раз: если существует определенная, законченная логика взаимодействия объектов или систем - она выносится на отдельный уровень. Поддержка транзакций очевидно является законченной бизнес-логикой, и, следовательно, должна быть вынесена на специальный уровень. Пусть классы реализуют свою функциональность, не заботясь о свопе, многозадачности-поточности, транзакциях, доступе, приоритетах, авторизациях, синхронизации, сборке мусора (garbage collection) или уплотнении памяти - это не его проблемы. Это - другие уровни, которыми занимаются другие классы, или даже системы. В современном компьютерном мире этот принцип сегодня доминирует, именно на него работают новомодные COM+ с MTS, IBM-websphera, JavaBeans, и множество иных. То, что грамотная корпоративная система должна работать в минимум четырех уровнях, уже является прописной истиной: данные, бизнес-логика сервера, бизнес-логика клиента, клиент.

Понимаете теперь, в чем преимущество смарт-указателей? Они позволяют с легкостью создавать новые уровни бизнес-логик без привлечения дополнительных средств и схем, а едиными только средствами языка. Попробуйте сделать что-либо подобное на языке, который не поддерживает указателей и перегрузки операторов (да шаблоны еще)! Вот код.

#include "ampstack.h"

// Абстрактный базовый класс

class CLockable {

 friend class CTransaction;

protected:

 // текущая транзакция, если есть

 CTransaction* m_trans;

public:

 CLockable (): m_trans (NULL) {}

 // регистрируемся в какой-то транзакции

 int regObj (CTransaction* _pt);

 // и разрегистрируемся

 void unregObj();

 virtual ~CLockable() {}

 virtual void rollback () =0;

 virtual void commit() =0;

};

// Класс транзакции

class CTransaction {

 friend class CLockable;

private:

 // коллекция зарегистрированных объектов

 ampstack‹CLockable› m_locks;

 // добавить объект к транзакции

 void addLock (CLockable*);

public:

 virtual ~CTransaction ();

// закрепить или отменить все изменения во всех

// зарегистрированных объектах.

 void commit();

 void rollback();

// проверить, зарегистрирован ли объект в этой транзакции

 int allready_locked(CLockable*);

};

// зарегистрироваться в транзакции

inline int CLockable::regObj (CTransaction* _pt) {

 if (m_trans!= NULL) return 0;

 else {

  _pt-›addLock(this);

  m_trans = _pt;

  return 1;

 }

}

// разрегистрироваться

inline void CLockable::unregObj() {

 m_trans = NULL;

}

// добавление объекта к транзакции.

inline void CTransaction::addLock(CLockable* _lc) {

 // а именно, воткнуть указатель на него в стек.

 m_locks.push (_lc);

}

// закрепление всех объектов

void CTransaction::commit() {

 // создаем итератор

 ampIter‹CLockable› it(&(this-›m_locks));

 // пробежались по всем, закрепились.

 it.goStart();

 while (!it.isLast()) it.moveNext()-›commit();

 // Всех выкинуть из стека, разрегистрировать.

 while (!m_locks.isEmpty()) m_locks.pop()-›unregObj();

}

// отмена всех объектов

void CTransaction::rollback() {

 // создали итератор

 ampIter‹CLockable› it(&(this-›m_locks));

 // пробежались по всем, отменились.

 it.goStart();

 while (!it.isLast()) it.moveNext()-›rollback();

 // Всех выкинуть из коллекции и разрегистрировать

 while (!m_locks.isEmpty()) m_locks.pop()-›unregObj();

}

// проверка, зарегистрирован ли объект.

int CTransaction::allready_locked(CLockable* _lc) {

 // создали итератор

 ampIter‹CLockable› it(&(this-›m_locks));

 it.goStart();

 while (!it.isLast()) if (it.moveNext() == _lc) return 1;

 return 0;

}

Шаг 29 - Единственный экземпляр класса - Одиночка или Singleton.

Как гарантировать единичность экземпляра некоего класса?

Предположим, что Вы проектируете программную систему, в которой некое устройство должно быть исключительно в одном экземпляре. Какие у нас варианты?

1. Создать класс устройства, объявить его экземпляр в специальном файле globals.cpp, и обязать программистов использовать строго его (именно так я делал на заре карьеры; наш шеф под роспись давал нам "Меморандум о писании программ", там много было интересного).

2. Создать класс устройства, объявить в нем устройство статическим членом.

3. Реализовать в классе устройства подсчет экземпляров, ограничить максимальное количество единицей.

4. Создать "закрытый" класс устройства, создать смарт-указатель на него так, чтобы смарт следил за одиночеством класса устройства.

Первый вариант сразу на помойку. Второй более интересен, но есть несколько неприятных проблем, связанных со статическими и глобальными данными. Правила C/C++ не определяют порядок конструирования таких объектов, если они находятся в разных файлах. То есть, у Вас прога уже вовсю дышит, работает - а находятся такие объекты, которые даже еще не инициализировались! Получается, что глобальные и статические объекты не должны рассчитывать друг на друга. С другой стороны, если объявить статический член, его нужно инициализировать - а данные могут быть еще не готовы.

Третий вариант кажется подходящим, но только кажется. Мы получим ошибку создания во время исполнения. Вот радость то, конструируем объект, а он нам исключения выбрасывает, мы об этом уже говорили в Шаге 12.

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

Зато интересно сделать вот что: пусть класс одинокого устройства будет смарт-указателем на самого себя[1]!

class CSingleton {

public:

 static CSingleton* GetInstance (void);

 static void DestroyInstance (void) {

  if (m_instance) delete m_instance;

 }

private:

 static CSingleton* m_instance;

protected:

 CSingleton() {}

};

CSingleton* CSingleton::m_instance = NULL;

CSingleton* CSingleton::GetInstance() {

 if (!m_instance) m_instance = new CSingleton;

 return m_instance;

}

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

Примечания

1

 Э.Гамма, Р.Хелм, Р.Джонсон, Дж.Влиссидес. "Паттерны проектирования."

Крайне интересная книжка, описывает 23 стандартных шаблона (паттерна) проектирования; предполагает определенную подготовку; охватывает более высокий уровень программирования и проектирования. Данный прием там именуется как "паттерн Singleton"

(обратно)

Оглавление

Шаг 1 - Введение. Зачем все это надо и что это такое.

Шаг 2 - Умные указатели.

Шаг 3 - Как это применять.

  1. Обработка обращения к NULL.

  2. Отладка и трассировка.

  3. Статистика классов и объектов.

  4. Кэширование.

Шаг 4 - О двойной диспетчеризации.

Шаг 5 - Ведущие указатели (Master Pointers). Важные конструкторы.

Шаг 6 - Ведущие указатели. Еще пара слов.

Шаг 7 - Интерфейсы. Интерфейсные указатели.

Шаг 8 - Еще раз о статистике класса.

Шаг 9 - Множественные интерфейсные smart-указатели.

Шаг 10 - Множественные интерфейсные указатели. Продолжение.

Шаг 11 - Нетривиальное конструирование объектов.

Шаг 12 - Двухэтапная инициализация.

Шаг 13 - Перегрузка operator+.

Шаг 14 - Двойная диспетчеризация. Продолжение.

Шаг 15 - Как сделать массив из чего угодно.

  Массивы и оператор operator[].

Шаг 16 - Как сделать массив из чего угодно. Продолжение.

Шаг 17 - Как НЕ создавать локальные переменные.

Шаг 18 - Управление памятью.

Шаг 19 - Управление памятью. Продолжение 1.

Шаг 20 - Временные объекты. Неявные вызовы конструкторов и их подавление.

Шаг 21 - О тщете сущего.

Шаг 22 - Классы объектов, поддерживающие транзакции.

Шаг 23 - Классы объектов, поддерживающие транзакции. Продолжение.

Шаг 24 - Как создавать ТОЛЬКО локальные переменные.

Шаг 25 - Как сделать виртуальной свободную функцию.

Шаг 26 - Как сделать массив из чего угодно. Продолжение 2.

  Итераторы.

Шаг 27 - Умные указатели. Перегрузка operator*, operator(),operator-›*.

Шаг 28 - Классы объектов, поддерживающие транзакции. Продолжение 2.

Шаг 29 - Единственный экземпляр класса - Одиночка или Singleton. . .

Реклама на сайте