Идиомы и стили С++ - страница 19

Шрифт
Интервал

стр.

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

>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. Скринсавер вообще выполняет море абсолютно бесполезных и сверхсложных вычислений - Вам это мешает?


стр.

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