дотпратить копирование, используя контейнер со ссылочной семантикой. За подробностями обращайтесь на с. 226.

О Требуется возмоэююсть присваивания элемента оператором присваивания. Контейнеры и алгоритмы используют оператор присваивания для замены старых элементов новыми.

О Требуется возможность уничтожения элемента деструктором. Контейнеры уничтожают свои внутренние копии элементов при удалении этих элементов из контейнера. Следовательно, деструктор не должен быть закрытым (private). Кроме того, как обычно в С++, деструктор не должен инициировать исключения, иначе возможны абсолютно непредсказуемые последствия.

Эти три операции - копирование, присваивание, уничтожение - автоматически генерируются для любого класса. Следовательно, любой класс автоматически удовлетворяет требованиям, если для него не были определены специальные версии этих операций или их нормальная работа не нарушается другими членами класса.

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

О Для некоторых функций классов последовательных контейнеров требуется конструктор по умолчанию. Например, можно создать непустой контейнер или увеличить количество элементов без указания значений новых элементов. Такие элементы создаются вызовом конструктора по умолчанию для соответствующего типа.

О Для некоторых операций требуется определить проверку па равенство оператором ==. Такая необходимость особенно часто возникает при поиске.

О Для ассоциативных контейнеров требуется, чтобы элементы поддерживали критерий сортировки. По умолчанию используется оператор <, вызываемый объектом функции iesso.

Семантика значений и ссылочная семантика

Все контейнеры создают внутренние копии своих элементов и возвращают эти копии. Следовательно, элементы контейнера равны, но не идентичны объектам, заносимым в контейнер. При модификации объектов, являющихся элементами К01ггейиера, вы модифицируете копию, а ие исходный объект.

Копирование значений означает, что контейнеры STL поддерживают семантику значений. Они содержат значения вставляемых объектов, а не сами объекты. Но на практике также возникает необходимость в ссылочной семантике, при которой контейнеры содержат ссылки на объекты, являющиеся их элементами.

В некоторых старых системах С++ приходится обеспечивать выполнеше этих дополнительных требований, даже если они ие используются в программе. Например, некоторые реализации vector требуют обязательного наличия деструктора по умолчанию для элементов. В других реализациях всегда должен присутствовать оператор ciJasEie-ння. В соответствии со стандартом эти требования незаконны; скорее всего, в будущем подобные ограничения будут устранены.

Реализация ссылочной семантики с применением указателей хорошо знакома программистам С. В языке С аргументы функций передаются только по значению, поэтому для передачи по ссылке приходится использовать указатели.

Принятый D STL подход, то есть поддержка только семантики значений, имеет свои положительные и отрицательные стороны. К достоинствам такого подхода относятся:

О простота копирования элементов;

О при использовании ссылок часто возникают ошибки (программист должен следить за тем, чтобы ссылки не относились к несуществующим объектам, кроме того, необходимо предусмотреть обработку возможных циклических ссылок).

Недостатки:

О при отказе от ссылочной семантики копирование элементов может выполняться неэффективно или становится невозможным;

О невозможность одновременного присутствия объектов в нескольких контейнерах.

На практике нужны оба подхода: копии, независимые от исходных данных (семантика значений), и копии, ссылающиеся на исходные данные и изменяющиеся вместе с ними (ссылочная семантика). К сожалению, стандартная библиотека С++ не поддерживает ссылочную семаитику. Впрочем, ее можно реализовать в контексте семантики значений.

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

Более разумное решение основано на применении умных указателей - объектов, поддерживающих интерфейс указателей, но выполняющих дополнительную внутреннюю проверку или другие операции. Но здесь возникает важный вопрос: насколько умными должны быть эти указатели? В стандартную библиотеку С++ входит класс умного указателя auto ptr (см. с. 54), который на первый взгляд мог бы пригодиться. К сожалению, этот класс не подходит, поскольку не удовлетворяет одному из основных требований к элементам контейнеров, а именно: после копирования или присваивания объектов класса auto ptr оригинал и копия не эквивалентны. Исходный объект auto ptr изменяется, нотому что значение передается, а не копируется (см. с. 59 и 62). На практике это означает, что сортировка и даже простой вывод элементов контейнера может привести к их уничтожению. Следовательно, объекты auto ptr пе должны использоваться как элементы контейнеров (в системе С++, соответствующей стандарту, такие попытки приводят к ошибкам компиляции). Дополнительная информация приведена на с. 59.

Чтобы реализовать ссылочную семантику для контейнеров STL, вам придется написать собственны!! класс умного указателя. Но будьте внимательны: исноль-

зование умного указателя с подсчетом ссылок (умного указателя, который автоматически уничтожает связанный объект при уничтожении последней ссылки на него) вызовет немало проблем. Например, при прямом доступе к элементам возможна модификация их значений, пока они находятся в контейнере. В ассоциативном контейнере это приведет к нарушению порядка следования элементов, а это недопустимо.

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

Ошибки и исключения внутри STL

Ошибки случаются, хотим мы того или нет. Они могут быть обусловлены как действиями программы (а точнее, программиста), так и контекстом или рабочей средой программы (например, нехваткой памяти). Обе разновидности ошибок обрабатываются при помощи исключений (начальные сведения об исключениях приводятся на с. 31). Данный раздел посвящен принципам обработки ошибок и исключений в STL.

Обработка ошибок

при проектировании STL главным приоритетом была максимальная произ-водигельность, а не безопасность. Проверка ошибок требует времени, поэтому в STL она практически не выполняется. Если вы умеете программировать без ошибок, все замечательно, а если нет - дело кончится катастрофой. Перед включением библиотеки STL в стандартную библиотеку С++ обсуждался вопрос о том, не нужно ли расширить обработку ошибок. Большинство высказались против по двум причинам.

О Обработка ошибок снижает быстродействие, а высокая скорость работы попреж-нему остается основной целью большинства про1рамм. Как упоминалось выше, быстродействие было одним из приоритетов при проектировании STL.

О Тот, кто ставит на первое место надежность, может добиться своего при помощи интерфейсных оболочек или специальных версий STL. С другой стороны, невозможно повысить быстродействие за счет отказа от проверки ошибок, если эта проверка включена во все базовые операции. Например, если при любой выборке элемента по индексу проверяется, принадлежит ли индекс к интервалу допустимых значений, вам не удастся написать собственную процедуру индексации без проверки. А вот обратная ситуация вполне возможна.

В результате проверка ошибок в STL возможна, но не обязательна.

В спецификации стандартной библиотеки С++ указано, что любое использование STL, нарушающее предварительные условия, приводит к непредсказуемому поведению. Следовательно, при недействительном индексе, итераторе или