Читаем Идиомы и стили С++ полностью

  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;

Перейти на страницу:

Похожие книги

97 этюдов для архитекторов программных систем
97 этюдов для архитекторов программных систем

Успешная карьера архитектора программного обеспечения требует хорошего владения как технической, так и деловой сторонами вопросов, связанных с проектированием архитектуры. В этой необычной книге ведущие архитекторы ПО со всего света обсуждают важные принципы разработки, выходящие далеко за пределы чисто технических вопросов.?Архитектор ПО выполняет роль посредника между командой разработчиков и бизнес-руководством компании, поэтому чтобы добиться успеха в этой профессии, необходимо не только овладеть различными технологиями, но и обеспечить работу над проектом в соответствии с бизнес-целями. В книге более 50 архитекторов рассказывают о том, что считают самым важным в своей работе, дают советы, как организовать общение с другими участниками проекта, как снизить сложность архитектуры, как оказывать поддержку разработчикам. Они щедро делятся множеством полезных идей и приемов, которые вынесли из своего многолетнего опыта. Авторы надеются, что книга станет источником вдохновения и руководством к действию для многих профессиональных программистов.

Билл де Ора , Майкл Хайгард , Нил Форд

Программирование, программы, базы данных / Базы данных / Программирование / Книги по IT