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

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

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

Давайте попробуем придумать класс, объекты которого вели бы себя как массивы? Поехали. Решим, что класс внутри себя должен иметь для простоты массив, ну там счетчик элементов… вроде больше нечему там быть. Ну раз так, то возьмем стек из Шага 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();

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

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

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

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

Они не правы.

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

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

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

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

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

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

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