Бьерн Страуструп. Язык программирования С++. Специальное издание (2011) (1004033), страница 142
Текст из файла (страница 142)
йегшог!пяег! (Иега!ог рояй!оп, сопи Тя я) 1 Тлпй адос::ротгег р = а.адоса!е (1); И получит» Тдп/с У... ) И... )! Поскольку 7!ай — это член класса!Ы, он также параметризуется аллокатором (513.2.1). Как следствие, типы 1!ай для контейнеров йпй с разными аллокаторами тоже разные, как и типы самих контейнеров (917.3.3). сто. Например, невозможно средствами языка С++ предоставить абсолютно совершенный ссылочный тип.
Однако разработчики языка и библиотек могут воспользоваться этими туреИеу'для поддержки типов, которые не могут быть предоставлены рядовым пользователем. Например, речь может идти об аллокаторе, предоставляющем доступ к долговременной памяти. Или о «длинных указателях», предоставляющих доступ к памяти за пределами обычного 32-адресного пространства. Обычный пользователь может ввести тип необычного указателя лля аллокатора, служащего каким-то специфическим нухсдам. Этого, однако, нельзя сделать для ссылок. Аллокаторы упрощают работу с объектами типа, специфицированного параметром шаблона. Однако большинство контейнеров работает и с объектами иных типов. Например, разработчику контейнера Из!требуется размещать в памяти объекты типа 71пй.
И обычно их нужно размеШать в памяти аллокатором контейнера Ияг. Любопытный тип геЫпИ введен для того, чтобы позволить аллокаторам размещать в памяти объекты произвольных типов. Рассмотрим следующий оператор яуреИеу". 678 Глава ) 9. Итераторы и аллокаторы 19.4.2.
Пользовательский аллоквтор с1азз Роо! ( лгис(А1пй ( йтй* пех11 ); мгис1 Сйипй ( епит (5!ге = 8*1024-1б); //слегка меньше 8К, чтобы кусок памяти умещался в 8К сйаг тегп [5!ге) 1 // для достижения точного выравнивания Сйипй* пехл )1 Сйипй* сйипйз; со51 ип518пеа Ы1 ез!ге; Ыпй* йеа41 Роо!(Роо(а) 1 гоЫ орегазог= (Ров!5 ); го148гон () 1 //защита от копирования // защита от копирования //увеличить пул риЫгс: Роо( (ип518пег( тг и ); -Роо1() 1 // н это размер элементов гоЫ* а!!ос() 1 гоЫ7гее (гоЫ* Ь) 1 //выделить намять под один элемент /возвращение элемента в пул тйпе гоЫ* Роо(:: а11ос ( ) ( (!'(Ьеа4==0) 8 ош () 1 йгпй* р = йеаа) йеаа = р->пех11 ге1игп р1 // вернуть первглй элемент Ыйпе гоЫ Роо1::7гее (гоЫ* Ь) ( Ыпй* р = 5(аас са51<74пй'> (Ь) Часто разработчики контейнеров применяют операции а!оса!с() и 8еа11осаге() по одному разу на каждый объект.
Для простейшей реализации а11осаге() это означает массу вызовов функции орега(ог пеп(), а реализации последней не так уж и эффективны в этом случае. В качестве примера пользовательского аллокатора я применяю схему с заранее сформированным пулом участков памяти фиксированного размера, из которого можно будет выделять память под объекты более эффективно, чем зто делает стандартная функция общего назначения орега(ог пезг() .
В свое время я столкнулся с распределителем памяти из заранее сформированного пула, который работал правильно, но имел неправильный интерфейс (так как был разработан задолго до изобретения аллокаторов). Это был класс Роо1, который и формировал понятие пула элементов фиксированного размера, из которого пользователь мог быстро выделять память под объекты и освобождать ее.
Это был низкоуровневый тип, работавший с памятью напрямую и учитывавший необходимость в выравнивании границ памяти: 679 19.4. Аплокаторы (распределители памяти) р->пехт = йеаА йеад = р; ) Роо(:: Роо( (ипз!епед тг ля) : ел!ге (зг<з!гео!'(Тллй) зз!гео! (Тллй): зг) ( йеаг(= Ог сйилйз = О; ) !освободить все куски (сйипйз) Роо1:: -Роо1 () ( Сйипй* и = сйггпйз; пй((е (и) ( Салий* р = и; и = и->лехт; Фе!е!е р; ) го!О Роо1::лгот () й выделяет новый 'сйинй ' организуя его в виде связанного П списка элементов размером 'емге' ( Сйипй* и = пеи Сйипй; п->пех! = сйипйз; сйиийз = и; сопя! 1п! ле1ет = Салий:: иге)ез!яе; сйаг* з1аИ = л->тет; сйог* !аз! = автои [ (пе(ет-1) *ез!ге) )ог (сйаг* р = моиг р<1аз1; р+=емге) ге(пгегрге! саят<1!пй*> (р) ->иск! = гет1егргет сазт<1ллй*> (р+езае) гет!егргег саят<Ила*> (1ам) ->пехт = О; йеад = ге!и!егрге! саят<Тяпа* > (я!огт); ) Чтобы продемонстрировать чуть-чуть реализма, я буду использовать Роо1 в неизменном виде как часть моего собственного аллокатора (вместо того, чтобы исправлять его интерфейс).
Мой аллокатор на базе фиксированного пула призван быстро выделять и освобождать память под один элемент, и именно это делает класс Роо!. Расширение данной модели на более обшие случаи выделения памяти под несколько объектов или под объекты разных размеров (как того требует гей1л(1) я оставпяю в качестве упражнения (519.6[9]).
При наличии Роо1 определение Роо1 о11ос тривиально: гетр(о!е <с!азз Т> с1азз Роо) а!!ос ( р с!кате: зазт!с Роо! тегл; 1 лул элементов размером зтгеоЯТ) риЫ!с: й аналогично стандортному алоса!ог !зт)94. !) Глава 19. Итераторы и аллокаторы 680 <стр<а<с<с<ат Т> Роо< Роо! айос<Т> <: тат (игеоу (Т) ) <етр<а<с<с<ат Т> Роо1 айос<Т><:Ров< алас() () <етр1а<е<с1ат Т> Т* Рос! айос<Т>:: айоса<с (к<ге <уре п, гоЫ* = О) ( (1(и == 1) ге<игл найс саа«Т*> (тат.аИос() ) < й... ) <етр<а<е<с1ат Т> гоЫ Роо< айос<Т>:: <<еайоса<е (рот<с< р, Иге <уре и) ( <1 (п == 1) тет.1гсе (р) < ге<ига < ) й...
) Применение аллокатора также очевидно: гетог<т<, Роо< айос<!и<» г< тор<к<<!пй, питЬег, Роо< айос<ра1 <сова< а<с<ай, питЬег» > т; й используем кок обычно гес<ог«п<> г2 = ю ~У еггог: иные параметры оллокоторо Я предпочел сделать поле типа Роо< статическим в классе Роо! айос из-за ограничений, которые стандартная библиотека накладывает на аллокаторы стандартных контейнеров: реализации стандартных контейнеров могут обращаться с объектами своего аллокаторного типа как с эквивалентными объектами. Это существенно повышает эффективность реализации. Из-за этого ограничения, например, не нужно выделять память под аллокаторы объектов типа Аий (в типичных случаях они параметризуются аллокаторами своих контейнерных классов; 5! 9.4.1), и операции над элементами двух последовательностей (например, з)гор () ) могут не проверять, одинаковые ли аллокаторы обслуживают элементы обоих последовательностей.
Указанное ограничение, однако, не позволяет аллокаторам иметь доступ к данным конкретных экземпляров объектов. Перед тем, как разрабатывать или применять пользовательский аллокатор, убедитесь в его реальной необходимости. Я предполагаю, что многие стандартные аллокаторы могут предоставлять классические оптимизационные схемы, а в таком случае нет нужды в собственных разработках. 19.4.3.
Обобщенные аллокаторы Класс айоса<ог представляет собой простой оптимизирующий вариант идеи о передаче информации контейнеру через параметр шаблона (513.4.1, $16.2.3). Например, имеет смысл требовать, чтобы память под каждый элемент контейнера выделялась исключительно через аллокатор. В то же время, если разрешить двум спискам типа ля<иметь разные аллокаторы, то в таком случае зр11се() (91722.1) нельзя 19,4.
Аллокаторы (распределитепи памяти) 681 было бы реализовывать обменом ссьиок; пришлось бы применять поэлементное копирование и все по причине учета такого редкого случая, когда вр11се ) ) действует над элементами последовательностей с разными аллокаторами одного и того же аллокаторного типа. Аналогично, если сделать аллокаторы совершенно универсальными, то механизмы вроде геЬ!пс(, позволяющие аллокаторам выделять память под элементы произвольных типов, стали бы слишком сложными. Как следствие, стандартным аллокаторам запрещается работать с данными объектов, и реализации стандартных контейнеров могут извлекать из этого выгоду.
Удивительно, но кажущееся драконовским ограничение на пообъектную информацию в аллокаторах не слишком серьезно. Большинство аллокаторов не нуждается в пообъектных данных и могут работать быстрее без такой информации. Однако аллокаторы могут хранить данные на уровне типа аллокатора. Если нужны разные данные, можно воспользоваться разными типами аллокаторов. Например: гетр!асе<сгазв Т, с!ат Р> сгавв Му айос д' айосасог длл Т с реализацией посредствои Р ( Р сгс д'нужно длл Му а!!ос<Т,Р> л'...
)! сурейе(Му айос<спс, Регз!лсепс сп1о> Регпзсепс! Суресге( Му ассов<!пС, 5ЬагесС !п(о> з)саге«С; суресгеС' Му аНос<тс, Реуаисс 1п)о> Ре(пи!с; 1Ьс<!пс, РеглЬсепс> !в!1; 1йс<тс, Ягсагесг> !Ф2! сйс<!пс, Ре(пи!с> ЬсЗс Списки 1м1, 1ес2 и ЫЗ относятся к разным типам. Поэтому при работе с двумя из этих списков мы должны использовать универсальные алгоритмы (глава 18), а не специализированные операции класса списков (517.2.2.1).
В итоге, серьезных проблем при использовании различных аллокаторов не возникает — просто выполняется копирование элементов, а не переназначение ссылок. Ограничение на пообъектную информацию в аллокаторах накладывается в первую очередь из-за строжайших требований к высочайшей эффективности стандартной библиотеки. К примеру, расходы памяти под аллокаторные данные списков невелики, но они сильно возрастают, если хранить данные о каждой связи. Теперь рассмотрим, как можно было бы применить аллокаторную технологию, если бы не было строжайших ограничений на эффективность работы. Это актуально либо для нестандартных библиотек, от которых не требуется высокой эффективности для любой структуры данных и любого типа программы, либо для некоторых специфических реализаций стандартной библиотеки.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
