Герб Саттер - Стандарты программирования на С++. 101 правило и рекомендация

Здесь есть возможность читать онлайн «Герб Саттер - Стандарты программирования на С++. 101 правило и рекомендация» весь текст электронной книги совершенно бесплатно (целиком полную версию без сокращений). В некоторых случаях можно слушать аудио, скачать через торрент в формате fb2 и присутствует краткое содержание. Город: Москва, Год выпуска: 2005, ISBN: 2005, Издательство: Издательский дом Вильямс, Жанр: Программирование, на русском языке. Описание произведения, (предисловие) а так же отзывы посетителей доступны на портале библиотеки ЛибКат.

Стандарты программирования на С++. 101 правило и рекомендация: краткое содержание, описание и аннотация

Предлагаем к чтению аннотацию, описание, краткое содержание или предисловие (зависит от того, что написал сам автор книги «Стандарты программирования на С++. 101 правило и рекомендация»). Если вы не нашли необходимую информацию о книге — напишите в комментариях, мы постараемся отыскать её.

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

Стандарты программирования на С++. 101 правило и рекомендация — читать онлайн бесплатно полную книгу (весь текст) целиком

Ниже представлен текст книги, разбитый по страницам. Система сохранения места последней прочитанной страницы, позволяет с удобством читать онлайн бесплатно книгу «Стандарты программирования на С++. 101 правило и рекомендация», без необходимости каждый раз заново искать на чём Вы остановились. Поставьте закладку, и сможете в любой момент перейти на страницу, на которой закончили чтение.

Тёмная тема
Сбросить

Интервал:

Закладка:

Сделать

// Объявляем копирующий конструктор как explicit (у данного

// решения имеется побочное действие, так что требуется

// улучшение этого метода)

class B { // ...

public:

explicit B(const B& rhs);

};

class D : public B { /* ... */ };

Вызывающий код все равно в состоянии выполнить срезку, если это необходимо, но должен делать это явно:

void Transmogrify(B obj); // Теперь эта функция вообще не

// может быть вызвана (!)

void Transmogrify2(const B& obj) // Идиома для намерения в

{ // любом случае получить

В b( obj ); // параметр obj по значению

// ... // (с возможной срезкой)

}

B b; // Базовые классы не должны быть конкретными

D d; // (см. рекомендацию 35), но допустим это

Transmogrify(b); // Должна быть ошибка (см. примечание)

Transmogrify(d); // Должна быть ошибка (см. примечание)

Transmogrify2(d); // Все в порядке

Примечание: на момент написания данной рекомендации некоторые компиляторы ошибочно допускали один или оба приведенных вызова функции Transmogrify. Эта идиома вполне стандартна, но (пока что) не полностью переносима.

Имеется лучший способ предупреждения срезки, с более высокой степенью переносимости. Пусть, например, функция наподобие Transmogrifyв действительности хочет получить полную глубокую копию без информации о действительном производном типе переданного объекта. Более общее идиоматическое решение состоит в том, чтобы сделать копирующий конструктор базового класса защищенным (чтобы функция наподобие Transmogrifyне могла случайно его вызвать), а вместо него воспользоваться виртуальной функцией Clone:

// добавление функции Clone (уже лучше, но все еще требуется

// усовершенствование)

class B { // ...

public:

virtual B* Clone() const = 0;

protected:

B(const B&);

};

class D : public B { // ...

public:

virtual D* Clone() const { return new D(*this); }

protected:

D( const D& rhs ): B(rhs) {/*...*/ }

};

Теперь попытка срезки будет (переносимо) генерировать ошибку времени компиляции, а объявление функции Cloneкак чисто виртуальной заставляет непосредственный производный класс перекрыть ее. К сожалению, с данным решением все еще связаны две проблемы, которые компилятор не в состоянии обнаружить: в классе, производном от производного, функция Cloneможет оказаться неперекрытой, а перекрытие Cloneможет реализовать ее некорректно, так что копия будет не того же типа, что и оригинал. Функция Cloneдолжна следовать шаблону проектирования Nonvirtual Interface (NVI; см. рекомендацию 39), который разделяет открытую и виртуальную природы Cloneи позволяет вам использовать ряд важных проверок:

class В { // ...

publiс:

B* Clone() const { // Невиртуальная функция

B* р = DoClone();

assert(typeid(*p) == typeid(*this) &&

"DoClone incorrectly overridden");

return p; // проверка типа, возвращаемого DoClone

}

protected:

B(const B&);

private:

virtual B* DoClone() const = 0;

};

Функция Cloneтеперь является невиртуальным интерфейсом, используемым вызывающим кодом. Производные классы должны перекрыть функцию DoClone. Дополнительная проверка обнаружит все копии, которые имеют тип, отличный от оригинала, тем самым оповещая, что в некотором производном классе не перекрыта функция DoClone; в конце концов, задача assertсостоит именно в обнаружении и сообщении о таких программных ошибках (см. рекомендации 68 и 70).

Исключения

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

Ссылки

[Dewhurst03] §30, §76, §94 • [Meyers96] §13 • [Meyers97] §22 • [Stroustrup94] §11.4.4 • [Stroustrup00] §12.2.3

55. Предпочитайте канонический вид присваивания

Резюме

При реализации оператора operator=предпочитайте использовать канонический вид — невиртуальный с определенной сигнатурой.

Обсуждение

Предпочтительно объявлять копирующее присваивание для типа Tс одной из следующих сигнатур (см. [Stroustrup00] и [Alexandrescu03a]):

Читать дальше
Тёмная тема
Сбросить

Интервал:

Закладка:

Сделать

Похожие книги на «Стандарты программирования на С++. 101 правило и рекомендация»

Представляем Вашему вниманию похожие книги на «Стандарты программирования на С++. 101 правило и рекомендация» списком для выбора. Мы отобрали схожую по названию и смыслу литературу в надежде предоставить читателям больше вариантов отыскать новые, интересные, ещё непрочитанные произведения.


Отзывы о книге «Стандарты программирования на С++. 101 правило и рекомендация»

Обсуждение, отзывы о книге «Стандарты программирования на С++. 101 правило и рекомендация» и просто собственные мнения читателей. Оставьте ваши комментарии, напишите, что Вы думаете о произведении, его смысле или главных героях. Укажите что конкретно понравилось, а что нет, и почему Вы так считаете.

x