Эффективный и современный С++. 42 рекомендации по использованию С++11 и С++14 - [39]

и end, но не были добавлены cbegin, cend, rbegin, rend, crbegin и crend. С++ 14 исправляет это упущение.

Если вы используете С++11, хотите написать максимально обобщенный код и ни одна из используемых вами библиотек не предоставляет отсутствующие шаблоны для cbegin и подобных функций, не являющихся шаблонами, можете легко написать собственные реализации. Например, вот как выглядит реализация функции cbegin, не являющейся членом:

template
auto cbegin(const С& container)->decltype(std::begin(container)) {
 return std::begin(container); // См. пояснения ниже
}

Вы удивлены тем, что эта функция cbegin не вызывает функцию-член cbegin, не так ли? Я тоже был удивлен. Но давайте подумаем логически. Этот шаблон cbegin принимает аргументы любого типа, представляющего контейнерообразную структуру данных С, и обращается к этому аргументу через ссылку на константный объект container. Если С — обычный тип контейнера (например, std::vector), то container будет ссылкой на const-версию этого контейнера (например, const std::vector&). Вызов функции begin, не являющейся членом (и предоставленной С++11), для константного контейнера дает константный итератор const_iterator, и именно этот итератор и возвращает наш шаблон. Преимущества такой реализации в том, что она работает даже для контейнеров, которые предоставляют функцию-член begin (которую функция С++11 begin, не являющаяся членом, вызывает для контейнеров), но не имеют функции-члена cbegin. Таким образом, вы можете использовать эту свободную функцию cbegin с контейнерами, поддерживающими единственную функцию-член begin.

Этот шаблон работает и в случае, когда С представляет собой встроенный массив. При этом container становится ссылкой на константный массив. C++11 предоставляет для массивов специализированную версию функции begin, не являющейся членом, которая возвращает указатель на первый элемент массива. Элементы константного массива являются константами, так что указатель, который возвращает свободная функция begin, возвращает для константного массива указатель на константу, который фактически и является const_iterator для массива. (Для понимания, как специализировать шаблон для встроенных массивов, обратитесь к обсуждению в разделе 1.1 вывода типов в шаблонах, которые получают в качестве параметров ссылки на массивы.)

Но вернемся к основам. Суть этого раздела заключается в том, чтобы призвать вас использовать const_iterator везде, где возможно. Фундаментальный мотив для этого — применение const всегда, когда это имеет смысл — существовал и до С++11, но в С++98 этот принцип при работе с итераторами был непрактичным. В С++11 это сугубо практический совет, а в С++14 к тому же “доведены до ума” некоторые мелочи, остававшиеся незавершенными в С++11.

Следует запомнить

• Предпочитайте использовать const_iterator вместо iterator там, где это можно.

• В максимально обобщенном коде предпочтительно использовать версии функций begin, end, rbegin и прочих, не являющиеся членами.

3.8. Если функции не генерируют исключений, объявляйте их как >noexcept

В С++98 спецификации исключений были довольно темпераментными созданиями. От вас требовалось собрать информацию обо всех типах исключений, которые могла генерировать функция, так что при изменении реализации функции могла потребовать изменения и спецификация исключений. Изменение спецификации исключения могло нарушить клиентский код, так как вызывающий код мог зависеть от исходной спецификации исключений. Компиляторы обычно не предлагали никакой помощи в поддержании согласованности между реализациями функций, спецификациями исключений и клиентским кодом. Большинство программистов в конечном итоге сочло, что спецификации исключений в С++98 не стоят затрачиваемых на них усилий и ими лучше не пользоваться вовсе. Во время работы над С++11 было достигнуто согласие, что действительно важная информация о поведении функций в смысле исключений — это информация, может ли вообще такое исключение быть сгенерировано. Либо функция может генерировать исключение, либо гарантируется, что это невозможно. Именно эта дихотомия лежит в основе спецификаций исключений С++11, которые, по сути, заменили спецификации исключений С++98. (Спецификации исключений в стиле С++98 остаются корректными, но не рекомендуются к употреблению.) В С++11 безусловный модификатор noexcept применяется к функциям, которые гарантированно не могут генерировать исключения.

Должна ли функция быть объявлена таким образом — вопрос проектирования интерфейса. Поведение генерирующих исключения функций представляет большой интерес для клиентов. Вызывающий код может запросить статус noexcept функции, и результат этого запроса может повлиять на безопасность в смысле исключений или эффективность вызывающего кода. Таким образом, является ли функция объявленной как noexcept, представляет собой столь же важную часть информации, как и является ли функция-член объявленной как const. Отсутствие объявления функции как noexcept, когда вы точно знаете, что она не в состоянии генерировать исключения, — не более чем просто плохая спецификация интерфейса.