Бьерн Страуструп. Язык программирования С++. Специальное издание (2011) (1004033), страница 109
Текст из файла (страница 109)
В этом случае итерирующий код не должен зависеть от типа контейнера. Желательно, чтобы один и тот же фрагмент пользовательского кода мог работать с обоими типами контейнеров. Решение здесь следующее: определить абстрактный класс итератора с операцией «получить следующий элемент», от которого и наследовать для конкретных типов контейнеров. Например: Глава ) б. Организация библиотеки и контейнеры 526 Гесгог Иог Улвг аког Кес1ог 11ог Внутреннее устройство двух итераторов совершенно разное, но пользователей это не касается. Можно итерировать что угодно, для чего имеется реализация 11ог.
Например: !пг соип1(11ог<сяаг>а й, сваг гегт) ( )пгс = 0; ГОГ (С)1аГ* Р = й.г)ГВ1 () 1 Р; Р=й. ПЕХГ ( ) ) () (*Р==(ЕГт) Свез ге1игп с; Здесь, однако, имеется одна неприятность. Несмотря на то, что операции с итераторами типа 11ог весьма просты, они все же вносят дополнительные накладные расходы на вызов виртуальных функций. Во многих случаях эти затраты незначительны по сравнению с объемом основной работы. Но в системах, где требуется особая эффективность, итерации поверх простых контейнеров становятся критическими операциями, в которых вызов функции многократно дороже целочисленного сложения или разыменования указателя, выполняемых методом пехг() для вено(оров и списков. Поэтому рассмотренная модель неприменима или плохо применима для стандартной библиотеки.
Однако на практике рассмотренная контейнерно-итераторная модель успешно применяется во многих программных системах. Много лет я сам применял ее для большинства приложений. У нее есть свои достоинства и недостатки: + Контейнеры индивидуального дизайна просты и эффективны. + От контейнеров не требуется особой общности. Итераторы и классы-обертки (В25.7.1) помогают интегрировать индивидуально спроектированные контейнеры в общую среду разработки. г Единообразность применения обеспечивается итераторами (а не общим базовым контейнерным классом; В)6.2.2).
+ Для одного и того же контейнера можно определить разные итераторы с разными целями. е Контейнеры по умолчанию безопасны по типу элементов и однородны по нему же (все элементы имеют один и тот же тип). Разнородные контейнеры реализуются как однородные контейнеры указателей на общий базовый тип. + Контейнеры неинтрузивны (ненавязчивы) — элементы контейнера не обязаны иметь общий базовый класс или специальное связующее поле. Неинтрузивные контейнеры одинаково хорошо работают и со встроенными типами данных, и со структурами, раскладка которых жестко задается извне. — Каждое обращение к итератору влечет за собой вызов виртуальной функции с временными затратами, значительными по сравнению с простыми встраиваемыми функциями доступа. 16.2, Дизайн контейнеров 527 — Иерархия классов итераторов по мере развития постепенно запутывается.
— Контейнеры между собой не имеют ничего общего, равно как и содержащиеся в них объекты. Все это препятствует созданию универсальных служб долговременного хранения объектов (регз(зтепсе зегисез) и объектного ввода/вывода. Здесь знаком + помечены достоинства, а знаком — помечены недостатки. Я придаю большое значение гибкости, которую обеспечивают итераторы. Их общий интерфейс, такой как йог, может быть реализован много позже этапов проектирования и реализации самих контейнеров (здесь это Уесгог и ХЫ). Начиная проектировать, мы обычно сначала порождаем что-нибудь достаточно конкретное. Например, сначала у нас появляются просто массив и список.
И лишь после этого мы обнаруживаем абстракцию, объединяющую массивы и списки в некотором контексте. Фактически мы можем выполнять такую «позднюю абстракцию» многократно. Предположим, нам потребовалось реализовать абстракцию «множество». Хотя эта абстракция и отличается от абстракции Тгог, мы все равно можем реализовать интерфейс Юет (множество) способом, похожим на способ реализации интерфейса 1гог для Уесгог и Хпг. Уесгог М $ Уесго~ зег Уесгог дог 7.Ь! йог свг зег Таким образом, поздняя абстракция посредством абстрактных классов позволяет нам обеспечивать разные реализации концепций, даже если между ними нет сильного сходства.
Например, списки и вектора имеют очевидные общие черты, но ведь можно реализовать Тгог и для (зггеат. В представленном выше списке два последних пункта являются главными недостатками рассматриваемого подхода. То есть даже если для итераторов и иных подобных интерфейсов устранить накладные расходы на вызов функций (что в ряде случаев возможно), то все равно этот подход не станет идеальным для стандартной библиотеки. Неинтрузивные контейнеры в ряде конкретных случаев требуют большего расхода памяти и времени по сравнению с интрузивными контейнерами, но я не вижу в этом большой проблемы — при необходимости итератор вроде Тгог можно реализовать и для интрузивного контейнера (З16.51111).
16.2.2. Контейнеры с общим базовым классом Интрузивный контейнер можно определять и без шаблонов или иных средств параметризации типа. Например: Глава ) б. Организация библиотеки и контейнеры 528 Фгис! Аигй ( рйпй* рге; Пп!г* вис; // ... )' е!ат Аи! ( !лай* Ьеаг(! Ипй* сиге; // текущий элемент риЫ/е: А1пй* еег() ! войт ри! (Йтй*); //... )' //удалить и вернуть текущий элемент // вставить перед текущим элементом Теперь Пж это список структур типа Ипй, и в нем можно хранить объекты любых типов, производных от Пп/с.
Например: е!аввЯйр: риЫ/е!тй (/* ... */); го(й 1'(Ам!* т!) ( тййе(1тй* ро = 1Ф вЂ” >лег() ) ( р (янрь рв = йупат(е еал!<ЯЫр*> (ро) ) ( / используем 5Ь(р ) ейе ( // Оорл, делаем что-нибудь другое ) ) У бlир должен быть полииорфным Д!5.4.!) е1авв Санга(пег: риЫге ОЬ!ее! ( риЫ1с: гйггиа1 ОЬуес!* де! ( ); лиг!ив! го/й ри! (ОЬ|ее!*); г!этна! ОЬ/ее!л а орегагог ( ] (в(ее 6; //удалить и вернуть текущий элемент // вставить перед текущим элементом // индексация Язык Яепи1а определяет свои стандартные контейнеры подобным образом, так что для языков объектно-ориентированного программирования такой подход можно считать врожденным.
В наши дни общий класс всех объектов принято называть ОЬуее! или чем-то в этом роде. Класс ОЬ|ес! обычно предоставляет и другие полезные услуги помимо обеспечения связи контейнеров. Часто, но не всегда, этот подход расширяется до предоставления общего контейнерного типа; 16.2. Дизайн контейнеров Операции контейнера Солги!иег виртуальные, так что их можно соответствующим образом замешать для частных случаев контейнеров: с(ат й!ег: риЫ(с Сота!век ( риЫ(с: ОЬ!ес!* Бег ( ); гоЫ ри! ( ОЬ!ес!* ); У.,.
)1 с!ахт Вес(ог: риЫ(с Сои!атее риЬ|с: ОЬ!ЕС!*Ь ОрЕга1аг() (ЫЕЕ 1) ! У... Сразу же обнаруживается одна проблема — какие операции мы хотим получить от класса Соигатег? Мы можем обеспечить здесь только операции, общие для всех контейнеров. Однако пересечение множества операций всех контейнеров — до смешного узкий интерфейс. Более того, во многих практически интересных случаях такое пересечение вообще пусто. Поэтому исходя из реальности мы должны предоставить объединение наиболее существенных операций для множества контейнеров, которое мы намереваемся поддержать. Такое объединение часто называют жирным интерфейсом Да! т!енсе) (524.4.3).
В рамках жирного интерфейса мы можем либо обеспечить поведение функций по умолчанию, либо сделать их чисто виртуальными, заставив, тем самым, все производные классы предоставлять собственные реализации этих функций. В любом случае мы получаем множество функций, которые просто сообщают об ошибках времени выполнения. Например: с(алл Сои!атег: риЫ(с ОЬ!ес! ( риЫ(с: е!гис! Баг! ор В класс исключений ( соим слог* р; Ваг! ор (соил! слог* рр):р (рр) ( ) г(ггиа! кой!риг(ОЬ!ес!*) (одеон Ваг! ор("риг"); ) Ыииа( ОЬ1есг* Ве!(] (!Ьгои Ваа' ор(кде!ч); ) г(ииа! ОЬ1есг*ь орега1ог() (тг) (едгои Вагг ор(" () "); ) В...
Для защиты от ситуации, когда контейнер не поддерживает функцию Ве!(), мы просто перехватываем исключение Сои!атег:: Ва(! ор. Для иллюстрации перепишем пример с классом Яир следующим образом: БЗО Глава ) б. Организация библиотеки и контейнеры с)азз Яир: риЫ!с ОЬ!ес! (/* ... */); юй( 17 (Сои!а!пег* рс) !гу ( вй!)е (ОЬ!ес!* ро = рс->ае! ( ) ) ( Ц'(БЬ(р* рз = йупагп!с сазг<бйф*> (ро) ) ( // используем 5Ь!р ) е)зе ( // Оорз, делаем чгло-нибудь другое ) сагой (Сои!а!пег:: Вагг арь Ьай) ( // Оорз, делаем что-нибудь другое ) ) Все это утомительно, поэтому можно положиться на перехват Ваг( ор где-либо в ином месте программы, что заметно упрощает наш пример: го1Ы/2 ( Селга!пег* рс) ( юй11е(ОЬ!ес!* ро = рс->яе!() ) ( ЯЬ!ра з = Иупага!с саз1<ЯЬ!ра> ( гро) // используем Яир Однако упование на проверку исключений в иных местах программы я считаю неэффективным, безвкусным, и в итоге предпочитаю в подобного рода случаях статическую проверку: юй(ЗЗ (Йог<31ир>* !) ( пй!1е (Яир* рз = 1->пел!() ) ( // используем Яир ) ) У подхода к построению контейнеров на базе общего родительского класса есть свои достоинства и недостатки: — Операции над конкретными контейнерами требуют дополнительных затрат на вызов виртуальных функций.
16,2. Дизайн контейнеров — Все типы контейнеров должны быть производными от Солта[лег. Это чревато применением «жирных интерфейсов», требует большой степени предвидения и приводит к необходимости проверки типов на стадии выполнения. Интеграция независимо разработанных контейнеров в общую среду разработки по меньшей мере неудобна (см.
516.5[12[). «Общий базовый класс Солта(яег повышает взаимозаменяемость контейнеров, предоставляющих схожие наборы операций. — Контейнеры разнородны и в общем случае небезопасны по типу элементов (единственное, на что можно положиться, так это то, что элементы относятся к типу ОЬгесг'). При необходимости безопасные и однородные контейнеры могут определяться шаблонами. — Контейнеры интрузивны (каждый элемент должен иметь тип, производный от ОЬгесг). Объекты встроенных типов и структуры, чья раскладка жестко задается извне, поместить в контейнер непосредственным образом невозможно.
— Извлеченный из контейнера элемент требует явного приведения типа до момента использования этого элемента. «Класс Солгаглег и класс ОЬГесг служат базой для решения проблемы реализации универсальных сервисов, пригодных для любых контейнеров и любых обьектов, таких как долговременное хранение объектов и объектный ввод/вывод. Здесь знак плюс маркирует достоинство, а знак минус — недостаток.
По сравнению с подходом, использующим несвязанные контейнеры и итераторы, подход с общим базовым классом всех объектов выплескивает сложности на голову пользователя, вызывает значительные дополнительные расходы времени и памяти и налагает ограничения на объекты, которые можно поместить в контейнер. Кроме того, для многих классов наследование от ОЬГесг означает открытие деталей реализации.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
