Бьерн Страуструп (947334), страница 45

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 45)

прием, когда объекты хранятся в "первичном" списке, имеющим

принудительную связь, а списки без принудительной связи используются

только, когда требуется включение объекта в несколько списков:

void f(name* p)

{

Islist<name> lst1;

Slist<name*> lst2;

lst1.insert(p); // связь через объект `*p'

lst2.insert(p); // для хранения `p' используется

// отдельный объект типа список

// ...

}

Конечно, подобные трюки можно делать только в отдельном компоненте

программы, чтобы не допустить путаницы списочных типов в

интерфейсах различных компонент. Но это именно тот случай, когда

ради эффективности и компактности программы на них стоит идти.

Поскольку конструктор Slist копирует параметр для insert(),

список Slist пригоден только для таких небольших объектов, как

целые, комплексные числа или указатели. Если для объектов копирование

слишком накладно или неприемлемо по смысловым причинам, обычно

выход бывает в том, чтобы вместо объектов помещать в список

указатели на них. Это сделано в приведенной выше функции f() для

lst2.

Отметим, что раз параметр для Slist::insert() копируется, передача

объекта производного класса функции insert(), ожидающей объект

базового класса, не пройдет гладко, как можно было (по наивности)

подумать:

class smiley : public circle { /* ... */ };

void g1(Slist<circle>& olist, const smiley& grin)

{

olist.insert(grin); // ловушка!

}

В список будет включена только часть circle объекта типа smiley.

Отметим, что эта неприятность будет обнаружена транслятором в том

случае, который можно считать наиболее вероятным. Так, если бы

рассматриваемый базовый класс был абстрактным, транслятор запретил

бы "урезание" объекта производного класса:

void g2(Slist<shape>& olist, const circle& c)

{

olist.insert(c); // ошибка: попытка создать объект

// абстрактного класса

}

Чтобы избежать "урезания" объекта нужно использовать указатели:

void g3(Slist<shape*>& plist, const smiley& grin)

{

olist.insert(&grin); // прекрасно

}

Не нужно использовать параметр-ссылку для шаблонного класса:

void g4(Slist<shape&>& rlist, const smiley& grin)

{

rlist.insert(grin); // ошибка: будет созданы команды,

// содержащие ссылку на ссылку (shape&&)

}

При генерации по шаблону типа ссылки, используемые подобным образом,

приведут ошибкам в типах. Генерация по шаблону типа для функции

Slist::insert(T&);

приведет к появлению недопустимой функции

Slist::insert(shape&&);

Ссылка не является объектом, поэтому нельзя иметь ссылку на ссылку.

Поскольку список указателей является полезной конструкцией,

имеет смысл дать ему специальное имя:

template<class T>

class Splist : private Slist<void*> {

public:

void insert(T* p) { Slist<void*>::insert(p); }

void append(T* p) { Slist<void*>::append(p); }

T* get() { return (T*) Slist<void*>::get(); }

};

class Isplist : private slist_base {

public:

void insert(T* p) { slist_base::insert(p); }

void append(T* p) { slist_base::append(p); }

T* get() { return (T*) slist_base::get(); }

};

Эти определения к тому же улучшают контроль типов и еще больше

сокращают необходимость дублировать функции.

Часто бывает полезно, чтобы тип элемента, указываемый в шаблоне

типа, сам был шаблонным классом. Например, разреженную матрицу,

содержащую даты, можно определить так:

typedef Slist< Slist<date> > dates;

Обратите внимание на наличие пробелов в этом определении. Если между

первой и второй угловой скобкой > нет пробелов, возникнет

синтаксическая ошибка, поскольку >> в определении

typedef Slist<Slist<date>> dates;

будет трактоваться как операция сдвига вправо. Как обычно, вводимое

в typedef имя служит синонимом обозначаемого им типа, а не является

новым типом. Конструкция typedef полезна для именования для

длинных имен шаблонных классов также, как она полезна для любых

других длинных имен типов.

Отметим, что параметр шаблона типа, который может по разному

использоваться в его определении, должен все равно указываться среди

списка параметров шаблона один раз. Поэтому шаблон типа, в котором

используется объект T и список элементов T, надо определять так:

template<class T> class mytemplate {

T ob;

Slist<T> slst;

// ...

};

а вовсе не так:

template<class T, class Slist<t> > class mytemplate {

T obj;

Slist<T> slst;

// ...

};

В $$8.6 и $$R.14.2 даны правила, что может быть параметром шаблона

типа.

8.3.3 Реализация списка

Реализация функций slist_base очевидна. Единственная трудность

связана с обработкой ошибок. Например, что делать если пользователь

с помощью функции get() пытается взять элемент из пустого списка.

Подобные ситуации разбираются в функции обработки ошибок

slist_handler(). Более развитый метод, рассчитанный на особые

ситуации, будет обсуждаться в главе 9.

Приведем полное описание класса slist_base:

class slist_base {

slink* last; // last->next является началом списка

public:

void insert(slink* a); // добавить в начало списка

void append(slink* a); // добавить в конец списка

slink* get(); // удалить и возвратить

// начало списка

void clear() { last = 0; }

slist_base() { last = 0; }

slist_base(slink* a) { last = a->next = a; }

friend class slist_base_iter;

};

Чтобы упростить реализацию обеих функций insert и append, хранится

указатель на последний элемент замкнутого списка:

void slist_base_insert(slink* a) // добавить в начало списка

{

if (last)

a->next = last->next;

else

last = a;

last->next = a;

}

Заметьте, что last->next - первый элемент списка.

void slist_base::append(slink* a) // добавить в конец списка

{

if (last) {

a->next = last->next;

last = last->next = a;

}

else

last = a->next = a;

}

slist* slist_base::get() // удалить и возвратить начало списка

{

if (last == 0)

slist_handler("нельзя взять из пустого списка");

slink* f = last->next;

if (f== last)

last = 0;

else

last->next = f->next;

return f;

}

Возможно более гибкое решение, когда slist_handler - указатель на

функцию, а не сама функция. Тогда вызов

slist_handler("нельзя взять из пустого списка");

будет задаваться так

(*slist_handler)(" нельзя взять из пустого списка");

Как мы уже делали для функции new_handler ($$3.2.6), полезно

завести функцию, которая поможет пользователю создавать свои

обработчики ошибок:

typedef void (*PFV)(const char*);

PFV set_slist_handler(PFV a)

{

PFV old = slist_handler;

slist_handler = a;

return old;

}

PFV slist_handler = &default_slist_handler;

Особые ситуации, которые обсуждаются в главе 9, не только дают

альтернативный способ обработки ошибок, но и способ реализации

slist_handler.

8.3.4 Итерация

В классе slist_base нет функций для просмотра списка, можно только

вставлять и удалять элементы. Однако, в нем описывается как друг

класс slist_base_iter, поэтому можно определить подходящий для

списка итератор. Вот один из возможных, заданный в том стиле, какой

был показан в $$7.8:

class slist_base_iter {

slink* ce; // текущий элемент

slist_base* cs; // текущий список

public:

inline slist_base_iter(slist_base& s);

inline slink* operator()()

};

slist_base_iter::slist_base_iter(slist_base& s)

{

cs = &s;

ce = cs->last;

}

slink* slist_base_iter::operator()()

// возвращает 0, когда итерация кончается

{

slink* ret = ce ? (ce=ce->next) : 0;

if (ce == cs->last) ce = 0;

return ret;

}

Исходя из этих определений, легко получить итераторы для Slist и

Islist. Сначала надо определить дружественные классы для итераторов

по соответствующим контейнерным классам:

template<class T> class Islist_iter;

template<class T> class Islist {

friend class Islist_iter<T>;

// ...

};

template<class T> class Slist_iter;

template<class T> class Slist {

friend class Slist_iter<T>;

// ...

};

Обратите внимание, что имена итераторов появляются без определения

их шаблонного класса. Это способ определения в условиях взаимной

зависимости шаблонов типа.

Теперь можно определить сами итераторы:

template<class T>

class Islist_iter : private slist_base_iter {

public:

Islist_iter(Islist<T>& s) : slist_base_iter(s) { }

T* operator()()

{ return (T*) slist_base_iter::operator()(); }

};

template<class T>

class Slist_iter : private slist_base_iter {

public:

Slist_iter(Slist<T>& s) : slist_base_iter(s) { }

inline T* operator()();

};

T* Slist_iter::operator()()

{

return ((Tlink<T>*) slist_base_iter::operator()())->info;

}

Заметьте, что мы опять использовали прием, когда из одного базового

класса строится семейство производных классов (а именно, шаблонный

класс). Мы используем наследование, чтобы выразить общность классов

и избежать ненужного дублирования функций. Трудно переоценить

стремление избежать дублирования функций при реализации таких простых

и часто используемых классов как списки и итераторы. Пользоваться

этими итераторами можно так:

void f(name* p)

{

Islist<name> lst1;

Slist<name> lst2;

lst1.insert(p);

lst2.insert(p);

// ...

Islist_iter<name> iter1(lst1);

const name* p;

while (p=iter1()) {

list_iter<name> iter2(lst1);

const name* q;

while (q=iter2()) {

if (p == q) cout << "найден" << *p << '\n';

}

}

}

Есть несколько способов задать итератор для контейнерного класса.

Разработчик программы или библиотеки должен выбрать один из них

и придерживаться его. Приведенный способ может показаться слишком

хитрым. В более простом варианте можно было просто переименовать

operator()() как next(). В обоих вариантах предполагается взаимосвязь

между контейнерным классом и итератором для него, так что можно

при выполнении итератора обработать случаи, когда элементы добавляются

или удаляются из контейнера. Этот и некоторые другие способы задания

итераторов были бы невозможны, если бы итератор зависел от функции

пользователя, в которой есть указатели на элементы из контейнера.

Как правило, контейнер или его итераторы реализуют понятие "установить

итерацию на начало" и понятие "текущего элемента".

Если понятие текущего элемента предоставляет не итератор, а сам

контейнер, итерация происходит в принудительном порядке по отношению

к контейнеру аналогично тому, как поля связи принудительно хранятся

в объектах из контейнера. Значит трудно одновременно вести две

итерации для одного контейнера, но расходы на память и время при такой

организации итерации близки к оптимальным. Приведем пример:

class slist_base {

// ...

slink* last; // last->next голова списка

slink* current; // текущий элемент

public:

// ...

slink* head() { return last?last->next:0; }

Характеристики

Список файлов книги