я внес три изменения в код, чтобы скомпилировать его без ошибок (хотя не смог избежать ряда предупреждений о сужающих преобразованиях) компилятором Microsoft VC++ 7.1 (2003):

• добавил отсутствующее слово typename в класс AlignedPOO;

• добавил отсутствующую конструкцию this->, чтобы в converterToo: :unit<>: :Dovisit() сделать имя зависимым;

• добавил символы новой строки в конце ряда заголовочных файлов, как того требует стандарт С++ (некоторые компиляторы недостаточно строги в этом отношении и допускают отсутствие таких символов в качестве расширения; VC++ строго относится к этому требованию).

Вот как прокомментировал автор [Мап1еу02] компромиссы дизайна Александреску: Этот способ не использует динамическую память, а также избегает проблем, связанных с выравниванием и переключением типов. К сожалению, у меня нет компилятора, который бы мог скомпилировать этот код, так что я не могу сравнить его производительность с вариантами, использующими myunion и any. Подход Александреску требует наличия 9 заголовочных файлов общим объемом около 80 Кбайт, что влечет за собой множество проблем поддержки (К. Мэнли, частное письмо). Все это так.

Я не намерен резюмировать здесь три статьи Андрея, но если вам они интересны - то они доступны в Web и указаны в списке литературы.

> Рекомендация

Если вам надо использовать вариантный тип, то лучше всего воспользоваться для этого классом boost; -.any (или чем-то в той же степени простым).

Когда используемый вами компилятор станет поддерживать шаблоны в достаточном объеме, а в стандарт включат поддержку выравнивания, наступит время рассмот-

реть в качестве возможной замены объединений шаблон наподобие variant. Резюме

Хотя дизайн и реализация myunion полны недостатков, сама проблема вполне реальна и стоит того, чтобы ею заняться. Я хотел бы поблагодарить К. Мэнли за то, что он нашел время и написал свою статью, привлекшую внимание к проблеме вариантных типов, а также Кевлину Хенни (Kevlin Henney) и Андрею Александреску за их вклад в решение данной проблемы. Это очень сложная проблема, и подходы Мэнли и Александреску оказываются не строго переноси.мы, хотя variant Александреску приближается к этому идеалу - он переносим настолько, что на практике его не способен скомпилировать ни один из распространенных компиляторов.

В настоящий момент наиболее предпочтительным оказывается использование такого класса, как boost::any. Если в конкретных местах измерения указывают, что вам действительно требуется повышенная эффективность или дополнительные возможности, предоставляемые классом наподобие Variant Александреску, и у вас есть время и знания, то вы можете поэкспериментировать в написании собственных версий Variant путем применения только тех идей из [Alexandrescu02], которые вы сможете объяснить компилятору.

5 Я благодарен коллеге Джеффу Пейлу (Jeff Pell) за его замечание об этом требовании [С++03] § 2.1/1, которое гласит: "Если непустой исходный файл не завершается символом новой строки или завершается символом новой строки, непосредственно перед которым идет символ обратной косой черты, поведение является неопределенным".

Задача 37. Ослабленная монолитность.

Часть 1: взгляд на std:: stri ng Сложность: 3

я решил завершить раздел, посвященный изучению конкретных примеров, минисерией, где рассматривается часть стандартной библиотеки, а именно - std:.string. Мы начнем наше рассмотрение с обзора важных правил, с учетом которых разрабатывался стандартный класс string.

Вопрос для новичка

1. Что такое монолитный класс и чем он плох? Поясните свой ответ., Вопрос для профессионала

2. Перечислите поименно все функции-члены std: :basic string.

Решение

Избегайте чрезмерно монолитных конструкций

1. Что такое монолитный класс и чем он плох? Поясните свой ответ.

Слово "монолитный" используется для описания программного обеспечения, которое представляет собой единое, неделимое большое целое наподобие монолита. Слово "монолит" происходит от слов "моно" (один) и "лит" (камень); оно вызывает в памяти образ огромного булыжника, который наглядно демонстрирует массивность и неделимость такого кода.

Единая тяжеловесная программа, которая предназначена "для всего", - зачастую просто тупик, в который зашли се создатели. В конечном счете часто оказывается, что чем сложнее приложение, тем уже область его применения. В частности, таким монолитом может оказаться класс, в функции-члены которого затолкали всю мыслимую функциональность, несмотря на то, что всю ее можно с тем же успехом реализовать в виде функций, не являющихся ни членами, ни друзьями этого класса. У такого подхода как минимум два недостатка.

• (Главный). Потенциально независимая функциональность оказывается локализованной в одном классе. Интересующая нас операция могла бы использоваться и с другими типами, но из-за жесткой закодированности в конкретном классе это оказывается невозможно (в то время как если бы эта операция была реализована как шаблон функции, не являюитйся членом класса, она могла бы использоваться существенно более широко).

• (Второстепенный). Этот подход может препятствовать расширению класса с использованием новой функциональности. "Минутку! - может возразить кто-то из читателей. - Не имеет значения, реализован ли существующий интерфейс класса при помощи функций-членов или не членов, так как я в любом случае могу расширить его при помощи моих собственных функций-не членов". Технически это так, но если вся функциональность класса достигается посредством функций-членов, т.е. реализована как естественная идиома класса, то расширение при помощи функций-не членов противоречит используемой идиоме и всегда остается решением второго сорта. То, что класс предоставляет свою функциональность в виде функций-членов класса, является семантическим указанием для его пользователей, которые привыкнут к такому стилю его использования, но который невозможно будет использовать при его расширениях.

Практичнее по возможности разбивать обобщенные компоненты на части.

> Рекомендация

Пользуйтесь идиомой "один класс (или функция) - одна задача".

Где это возможно - предпочтительно использовать функции, которые не являются членами и друзьями.

Остальная часть данной задачи просто дает нам дополнительное подтверждение приведенной рекомендации.

Класс string

2. Перечислите поименно все функции-члены std: :basic string .

•Это дсйствигслыю длинный список...

С учетом конструкторов в классе string не менее 103 функций-членов. Честно! Если это не монолит, то тогда я уж и не знаю, как он должен выглядеть...

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

Вдохните поглубже и задержите дыхание на время чтения ISO/1EC 14882;2003(Е)".

namespace std {

tempiate<class charT, class traits = char traits<charT>, class Allocator = al1ocator<charT> > class basic string {

: некоторые typedef :

explicit basic stringCconst Allocator& a = AllocatorO); basi c st ri ng(const basic string& str, si ze type pos = 0,

size type n = npos,

const Allocators a = AllocatorO); basicstring(const charT* s, size type n,

const Allocators a = AllocatorO) : basic stringCconst charT* s,

const Allocators a = AllocatorO); basic string(size type n, charT c,

const Allocators a = AllocatorO); tempiate<class inputiterator>

basic string(inputIterator begin, Inputlterator end, const Allocators a = AllocatorO); ~basic stringO;

basic strings operator=(const basic string& str); basic strings operator=(const charT* s); basic strings operator=(charT c); iterator begin(); const„iterator beginO const; iterator end(); const iterator end() const; reverse iterator rbeginO; const reverse iterator rbeginO const; reverse i terator rendO; const reverse iterator rendO const; size„type sizeO const; size type lengthO const; size...type max size() const; void resize(size type n, charT c); void resize(size type n); size type capacity() const;

Толстый TOM, известный также как стандарт ISO С++ [С++03]. Задача 37. Ослабленная монолитность. Часть 1: взгляд Hastd:;string 243