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

Тут можно читать онлайн Герб Саттер - Стандарты программирования на С++. 101 правило и рекомендация - бесплатно полную версию книги (целиком) без сокращений. Жанр: comp-programming, издательство Издательский дом Вильямс, год 2005. Здесь Вы можете читать полную версию (весь текст) онлайн без регистрации и SMS на сайте лучшей интернет библиотеки ЛибКинг или прочесть краткое содержание (суть), предисловие и аннотацию. Так же сможете купить и скачать торрент в электронном формате fb2, найти и слушать аудиокнигу на русском языке или узнать сколько частей в серии и всего страниц в публикации. Читателям доступно смотреть обложку, картинки, описание и отзывы (комментарии) о произведении.
  • Название:
    Стандарты программирования на С++. 101 правило и рекомендация
  • Автор:
  • Жанр:
  • Издательство:
    Издательский дом Вильямс
  • Год:
    2005
  • Город:
    Москва
  • ISBN:
    5-8459-0859-0
  • Рейтинг:
    3.3/5. Голосов: 101
  • Избранное:
    Добавить в избранное
  • Отзывы:
  • Ваша оценка:
    • 60
    • 1
    • 2
    • 3
    • 4
    • 5

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

Стандарты программирования на С++. 101 правило и рекомендация - описание и краткое содержание, автор Герб Саттер, читайте бесплатно онлайн на сайте электронной библиотеки LibKing.Ru

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

Начинающий программист найдет в ней простые и понятные рекомендации для ежедневного использования, подкрепленные примерами их конкретного применения на практике.

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

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

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

Стандарты программирования на С++. 101 правило и рекомендация - читать книгу онлайн бесплатно, автор Герб Саттер
Тёмная тема
Сбросить

Интервал:

Закладка:

Сделать

// противном случае - принимаем внесенные изменения:

pimpl_ = temp;

return *this;

}

Исключения

В то время как вы получаете все преимущества дополнительного уровня косвенности, проблема состоит только в увеличении сложности кода (см. рекомендации 6 и 8).

Ссылки

[Coplien92] §5.5 • [Dewhurst03] §8 • [Lakos96] §6.4.2 • [Meyers97] §34 • [Murray93] §3.3 • [Stroustrup94] §2.10, §24.4.2 • [Sutter00] §23, §26-30 • [Sutter02] §18, §22 • [Sutter04] §16-17

44. Предпочитайте функции, которые не являются ни членами, ни друзьями

Резюме

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

Обсуждение

Функции, не являющиеся членами или друзьями классов, повышают степень инкапсуляции путем снижения зависимостей: тело такой функции не может зависеть от закрытых и защищенных членов класса (см. рекомендацию 11). Они также разрушают монолитность классов, снижая связность (см. рекомендацию 33), и повышают степень обобщенности, так как сложно писать шаблоны, которые не знают, является ли интересующая нас операция членом данного типа или нет (см. рекомендацию 67).

Для определения того, должна ли функция быть реализована как член и/или друг класса, можно воспользоваться следующим алгоритмом:

// Если у вас нет выбора - делайте функцию членом.

Если функция представляет собой один из операторов =, ->,

[] или (), которые должны быть членами,

то

делайте данную функцию членом класса.

// Если функция может быть не членом и не другом либо

// имеются определенные преимущества от того, чтобы сделать

// ее не членом и другом

иначе если 1. функция требует левый аргумент иного типа

(как, например, в случае операторов >> или <<)

или 2. требует преобразования типов для левого аргумента,

или 3. может быть реализована с использованием только

открытого интерфейса класса

то

сделайте ее не членом класса (и, при необходимости,

в случаях 1 и 2 - другом)

Если функция требует виртуального поведения,

то

добавьте виртуальную функцию-член для обеспечения

виртуального поведения, и реализуйте функцию-не член

с использованием этой виртуальной функции.

иначе

сделайте ее функцией-членом.

Примеры

Пример. basic_string . Стандартный класс basic_stringчересчур монолитен и имеет 103 функции-члена, из которых 71 без потери эффективности можно сделать функциями, не являющимися ни членами, ни друзьями класса. Многие из них дублируют функциональность, уже имеющуюся в качестве алгоритма стандартной библиотеки, либо представляют собой алгоритмы, которые могли бы использоваться более широко, если бы не были спрятаны в классе basic_string. (См. рекомендации 5 и 32, а также [Sutter04].)

Ссылки

[Lakos96] §3.6.1, §9.1.2 • [McConnell93] §5.1-4 • [Murray93] §2.6 • [Meyers00] • [Stroustrup00] §10.3.2, §11.3.2, §11.3.5, §11.5.2, §21.2.3.1 • [Sutter00] §20 • [Sutter04] §37-40

45. newи deleteвсегда должны разрабатываться вместе

Резюме

Каждая перегрузка void* operator new(parms)в классе должна сопровождаться соответствующей перегрузкой оператора void operator delete(void* , parms), где parms— список типов дополнительных параметров (первый из которых всегда std::size_t). То же относится и к операторам для массивов new[]и delete[].

Обсуждение

Обычно редко требуется обеспечить наличие пользовательских операторов newили delete, но если все же требуется один из них — то обычно требуются они оба. Если вы определяете специфичный для данного класса оператор T::operator new, который выполняет некоторое специальное выделение памяти, то, вероятнее всего, вы должны определить и специфичный для данного класса оператор T::operator delete, который выполняет соответствующее освобождение выделенной памяти.

Появление данной рекомендации связано с одной тонкой проблемой: дело в том, что компилятор может вызвать перегруженный оператор T::operator deleteдаже если вы никогда явно его не вызываете. Вот почему вы всегда должны предоставлять операторы newи delete(а также операторы new[]и delete[]) парами.

Пусть вы определили класс с пользовательским выделением памяти:

class T {

// ...

static void* operator new(std::size_t);

static void* operator new(std::size_t, CustomAllocator&);

static void operator delete(void*, std::size_t);

};

Вы вводите простой протокол для выделения и освобождения памяти.

• Вызывающий код может выделять объекты типа Tлибо при помощи распределителя по умолчанию (используя вызов new T), либо при помощи пользовательского распределителя (вызов new(allос) T, где allос— объект типа CustomAllocator).

• Единственный оператор delete, который может быть использован вызывающим кодом — оператор по умолчанию operator delete(size_t), так что, конечно, вы должны реализовать его так, чтобы он корректно освобождал память, выделенную любым способом.

Пока все в порядке.

Однако компилятор может скрыто вызвать другую перегрузку оператора delete, а именно T::operator delete(size_t, CustomAllocator&). Это связано с тем, что инструкция

T* р = new(alloc) T;

на самом деле разворачивается в нечто наподобие

// Сгенерированный компилятором код для

// инструкции T* p = new(alloc)T;

//

void* __compilerTemp = T::operator new(sizeof(T), alloc);

T* p;

try {

p = new (__compilerTemp) T; // Создание объекта T по

// адресу __compilerTemp

} catch(...) { // Сбой в конструкторе...

T::operator delete(__compilerTemp, sizeof(T), alloc);

throw;

}

Итак, компилятор автоматически вставляет код вызова соответствующего оператора T::operator deleteдля перегруженного оператора T::operator new, что совершенно логично, если выделение памяти прошло успешно, но произошел сбой в конструкторе. "Соответствующая" сигнатура оператора deleteимеет вид void operator delete(void*, параметры_оператора_new).

Теперь перейдем к самому интересному. Стандарт С++ ([C++03] §5.3.4(17)) гласит, что приведенный выше код будет генерироваться тогда и только тогда, когда реально существует соответствующая перегрузка оператора delete. В противном случае код вообще не будет вызывать никакого оператора deleteпри сбое в конструкторе. Другими словами, при сбоях в конструкторе мы получим утечку памяти. Из шести проверенных нами распространенных компиляторов только два выводили предупреждение в такой ситуации. Вот почему каждый перегруженный оператор void* operator new(parms)должен сопровождаться соответствующей перегрузкой void operator delete(void*, parms).

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

Интервал:

Закладка:

Сделать


Герб Саттер читать все книги автора по порядку

Герб Саттер - все книги автора в одном месте читать по порядку полные версии на сайте онлайн библиотеки LibKing.




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


Отзывы читателей о книге Стандарты программирования на С++. 101 правило и рекомендация, автор: Герб Саттер. Читайте комментарии и мнения людей о произведении.


Понравилась книга? Поделитесь впечатлениями - оставьте Ваш отзыв или расскажите друзьям

Напишите свой комментарий
x