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

if (previos != NULL) {

delete that;

that = previos;

previos = NULL;

}

}

// реализация указателя

CSomeClass* operator-›() { return that; }

};

int main (void) {

// проверим быстренько

CSimpleTr lvPair;

lvPair-›x = 5;

lvPair-›y = 8;

lvPair.BeginTrans();

lvPair-›x = 7;

lvPair-›y = 11;

lvPair.Rollback();

lvPair.BeginTrans();

lvPair-›x = 7;

lvPair-›y = 11;

lvPair.Commit();

return 0;

}

Что может быть проще? Семантика значений, очевидно. Классы должны иметь полный набор обязательных функций, как обычно; в нашем случае класс CSomeClassбольно уж тривиален, поэтому сойдет и так. Класс CSimpleTrимеет смысл переписать в виде шаблона, если не хотите его заново переписывать для каждого нового клиента, да еще добавить функцию isStarted(). Функциональность на Ваш вкус и фантазию. MTS, например, восстановит отмененную транзакцию, если Вы после отмены сделаете закрепление: SetAbort(); SetComplete();сработает так, как будто SetAbort();не было вовсе.

Раз уж взялись, что мешает вставить в наш умный указатель с поддержкой отмены не один, а несколько предыдущих состояний объекта? Ничего. Только чтобы потом несколько раз не переделывать, решим несколько чисто технических моментов:

1. Какую структуру будем использовать в качестве коллекции состояний? Можно взять стек, можно кольцевой буфер, а можно и карту (словарь, хэш-таблицу); стек явно проще, зато за кольцевым буфером можно не следить вообще, пусть устаревшие состояния пропадают бесследно (конечно по желанию).

2. Определимся с семантикой. Смешивать значения и указатели не стоит, верный путь заработать себе геморрой. У меня не оказалось под рукой подходящего стека, и я написал для этого Шага два варианта - один хранит значения, другой - указатели; первый стек сначала казался проще, но использующий его класс указателя оказался ощутимо сложнее по простой причине - функции стека с указателями могут возвращать NULL, а это совсем немало.

3. Оформим все в виде шаблонов; вообще контейнеры просто просятся быть шаблонами, а smart-указатели несомненно являются контейнерами.

Код ниже, а сейчас пояснения:

Класс CTypeпросто проверочный, чтобы вкладывать в шаблоны; так проще отлаживать шаблон: сначала сделать контейнер-не-шаблон для класса Type, а потом просто приписать сверху объявления строку template‹Type›. Шаблон класса ampstack‹Type›- шаблон стека указателей; pushсохраняет указатель, popдостает верхний указатель, isEmptyпроверяет на пустоту, emptyAllочищает.

Шаблон класса MLTrans- наконец тот, который нам нужен. Указатель thatхранит текущее значение, Pushсохраняет текущее значение, PopOneделает однократную отмену, Rollbackотменяет все изменения, до первоначального, Commitудаляет историю.

// Это маленький класс для проверки

class CType {

int a;

public:

void set (int _a) { a=_a; }

int get (void) { return a; }

};

// Шаблон стека

template ‹class Type›

class ampstack {

private:

int iTop; // верх стека

int iSize; // размер стека

Type** array; // массив указателей

public:

// Конструктор-деструктор

ampstack(int size=10) : iTop(0), iSize(size), array(new Type*[size]) {}

~ampstack() {

for (int iCounter = 0; iCounter ‹ iTop; iCounter ++)

if (*(array+iCounter)!= NULL) delete *(array+iCounter);

delete[] array;

}

// Управление стеком

// Направить указатель в стек

void push (Type* _t) { array[iTop++]=_t; }

// Вынуть указатель из стека

Type* pop (void) {

if (iTop == 0) return NULL;

else return array[--iTop];

}

// Стек пуст?

int isEmpty (void) { return iTop==0; }

// Очистить стек

void emptyAll (void) {

for (int iCounter = 0; iCounter ‹ iTop; iCounter ++)

if (*(array+iCounter)!= NULL) delete *(array+iCounter);

iTop = 0;

}

};

// Шаблон класса с многоуровневой отменой

template ‹class Type›

class MLTrans {

typedef ampstack‹Type› stack;

private:

Type* that; // Текущее значение

stack history; // контейнер предыдущих значений

public:

// конструктор-деструктор

MLTrans(): that(new Type) {}

~MLTrans () { delete that; }

// Сохранение текущего значения, aналог SAVE TRANSACTIONв SQLсерверах