Ну, положим, Вам необходимо работать с геологической картой. Размер 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.
