class Widget {...}:
bool operator==(const Widget& lhs. const Widgets rhs):
При вызове этой функции в контексте
if (х==у) // Предполагается, что х и у
// относятся к классу Widget
Объекту х, находящемуся слева от оператора =, в объявлении operator
Что касается имени класса Widge
Вопросы эффективности
Сначала я хотел включить в книгу отдельную главу, посвященную вопросам эффективности, но в итоге решил, что лучше оставить привычное деление на советы. Тем не менее многие советы посвящены минимизации затрат памяти и ресурсов на стадии исполнения. Для удобства ниже приводится краткое содержание «виртуальной главы», посвященной эффективности.
Совет 4.Вызывайте empty вместо сравнения size() с нулем
Совет 5.Используйте интервальные функции вместо одноэлементных
Совет 14.Используйте reserve для предотвращения лишних операций перераспределения памяти
Совет 15.Помните о различиях в реализации string
Совет 23.Рассмотрите возможность замены ассоциативных контейнеров сортированными векторами
Совет 24.Тщательно выбирайте между map::operator[] и map::insert
Совет 25.Изучите нестандартные хэшированные контейнеры
Совет 29.Рассмотрите возможность использования istreambuf_iterator при посимвольном вводе
Совет 31.Помните о существовании разных средств сортировки
Совет 44.Используйте функции контейнеров вместо одноименных алгоритмов
Совет 46.Передавайте алгоритмам объекты функций вместо функций
Рекомендации
Рекомендации, составляющие 50 советов этой книги, основаны на мнениях и наблюдениях опытнейших программистов STL. Они в краткой форме подводят итог всему, что практически всегда следует (или наоборот, не следует) делать для успешного использования библиотеки STL. С другой стороны, это всего лишь рекомендации, и в некоторых ситуациях их нарушения вполне оправданны. Например, в заголовке совета 7 говорится о необходимости вызова delete
для указателей перед уничтожением контейнера. Но из текста совета становится ясно, что это правило действует лишь в тех случаях, когда объекты, на которые ссылаются указатели, должны уничтожаться раньше самого контейнера. Обычно это действительно так, но не всегда. Приведу другой пример — в заголовке совета 35 предлагается использовать алгоритмы STL для выполнения простых сравнений строк без учета регистра, но из текста совета следует, что в некоторых случаях лучше использовать функцию не только внешнюю по отношению к STL, но даже не входящую в стандарт С++!
Только хорошее знание специфики программы и условий ее работы позволит определить, стоит ли нарушать представленные рекомендации. Обычно этого лучше не делать, но в отдельных случаях возможны исключения. Как рабская покорность, так и безрассудное легкомыслие одинаково вредны. Прежде чем сходить с проторенной дороги, убедитесь в том, что для этого есть достаточно веские причины.
Контейнеры
В STL входит немало полезных компонентов (в том числе итераторы, алгоритмы и объекты функций), однако большинство программистов С++ ставит на первое место именно контейнеры. По сравнению с массивами контейнеры обладают большей гибкостью и функциональностью. Они динамически увеличивают (а иногда и уменьшают) свои размеры, самостоятельно управляют памятью, следят за количеством хранящихся объектов, ограничивают алгоритмическую сложность поддерживаемых операций и обладают массой других достоинств. Популярность контейнеров STL легко объяснима — просто они превосходят своих конкурентов, будь то контейнеры из других библиотек или самостоятельные реализации. Контейнеры STL не просто хороши. Они
В этой главе приведены общие сведения, относящиеся ко всем типам контейнеров STL (конкретные типы контейнеров будут рассмотрены в других главах). В частности, мы рассмотрим такие вопросы, как выбор подходящего контейнера при заданных ограничениях; возможность работы кода, написанного для одного типа контейнера, с другими типами контейнеров; особая роль операций копирования объектов в контейнерах; проблемы, возникающие при создании контейнеров с указателями auto_ pt
Список получился внушительным, но пусть вас это не пугает. Материал излагается небольшими порциями, а попутно вы встретите немало полезных идей, которые сможете
Итак, STL предоставляет в ваше распоряжение множество разных контейнеров, но знаете ли вы, насколько широко это разнообразие? Следующая краткая сводка поможет вам убедиться в том, что вы ни о чем не забыли.
Совет 1. Внимательно подходите к выбору контейнера
•Стандартные последовательные контейнеры STL: vecto
и list
.
•Стандартные ассоциативные контейнеры STL: set, multiset, map
и multimap
.
•Нестандартные последовательные контейнеры: slist
и rope
. Контейнер slist
представляет односвязный список, а rope
— строку с дополнительными возможностями. Краткий обзор этих нестандартных (но достаточно широко распространенных) контейнеров приведен в совете 50.
•Нестандартные ассоциативные контейнеры: hash_set, hash_multiset
, hash_ map
и hash_multimap
. Эти популярные разновидности стандартных ассоциативных контейнеров, построенные на базе хэш-таблиц, рассматриваются в совете 25.
•vector<char>
как замена для string
. Условия, при которых возможна подобная замена, описаны в совете 13.
•vector
как замена для стандартных ассоциативных контейнеров. Как будет показано в совете 23, в некоторых ситуациях vector
превосходит стандартные ассоциативные контейнеры как по быстродействию, так и по экономии памяти.
•Некоторые стандартные контейнеры, не входящие в STL: массивы, bitset
, valarray
, stack
, queue
и piority_queue
. Поскольку эти контейнеры не относятся к STL, в этой книге они практически не упоминаются, хотя в совете 16 описан случай, когда массив оказывается предпочтительнее контейнеров SQL, а в совете 18 объясняется, почему bitset
может быть лучше vector<bool>
. Также стоит помнить о возможности использования массивов с алгоритмами STL, поскольку указатели могут работать как итераторы массивов.
При столь широком ассортименте контейнеров возрастает и количество факторов, которыми следует руководствоваться при их выборе. К сожалению, многие описания STL ограничиваются поверхностным взглядом на мир контейнеров и полностью игнорируют многие факторы, относящиеся к выбору оптимального контейнера. Этот недостаток присущ даже Стандарту, который предлагает выбирать между vecto
и list
на основании следующих критериев: «
Если ограничиться алгоритмической сложностью, эта рекомендация звучит вполне разумно, но на практике приходится учитывать множество других факторов.
Вскоре мы рассмотрим некоторые факторы, учитываемые в дополнение к алгоритмической сложности, но сначала я должен представить критерий классификации контейнеров STL, которому, к сожалению, обычно не уделяется должного внимания. Речь идет о различиях между контейнерами с блоковым и узловым выделением памяти.
В vecto
string
и deque
. Нестандартный контейнер rope
также является блоковым.