Шаг 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; }
