- PVSM.RU - https://www.pvsm.ru -
Используйте rvalue-ссылки:
Определение
Rvalue-ссылка является ссылочным типом, привязанным к временному объекту. По синтаксису похожа на обычную ссылку. Например, void f(std::string&& s); объявляет функцию с аргументом rvalue-ссылка на std::string.
Когда суффикс '&&' (без дополнительных квалификаторов) используется с шаблонным аргументом функции, то применяются специальные правила определения типа аргумента. И такая ссылка имеет название forwarding reference.
За
Против
Вердикт
Вы можете использовать rvalue-ссылки чтобы объявить конструктор перемещения и перемещающий оператор присваивания (как описано в Копируемые и перемещаемые типы [8]). См. также C++ Primer [9] для более подробной информации о семантике перемещения и, также, std::move.
Вы можете использовать rvalue-ссылки чтобы объявить пары перегружаемых функций, одна с Foo&&, другая с const Foo&. Обычно программисты предпочитают передавать аргументы по значению. Однако использование пары функций может дать лучшую производительность, или позволит в обобщённом коде поддержать большое количество типов. И не забывайте: если ради производительности пишется более сложный код, проверьте и убедитесь, что это действительно помогает.
Вы можете использовать 'forwarding references' вместе с std::forward [10]
, чтобы реализовать 'perfect forwarding'.
В ряде случаев допустимо использовать классы и функции как friend.
Дружественные типы обычно определяются в том же файле, поэтому нет необходимости открывать другой файл, чтобы разобраться с использованием закрытых членов класса. Обычное использование friend: когда класс FooBuilder объявляется дружественным (friend) классу Foo, так что FooBuilder может корректно настроить внутреннее состояние Foo без необходимости открывать это состояние всем остальным. В ряде случаев удобно сделать класс unit-тестов дружественным исходному классу.
Дружественность расширяет (но не ломает) инкапсуляцию класса. В ряде случаев, когда требуется дать доступ к внутреннему состоянию только одному классу, лучше объявить его как friend, чем делать дополнительные открытые члены класса. Однако, в остальном классы должны взаимодействовать только через открытые функции.
Мы НЕ используем исключения C++.
За
Против
Вердикт
Для новых проектов преимуществ от использования исключений обычнобольше, чем недостатков. Однако, для уже существующего кодавведение исключений может повлиять на весь код. Также могут возникнутьпроблемы стыка нового кода и старого (без исключений) кода.
Т.к. большинство C++ кода в Google не использует исключений, то очень проблематично будет внедрять новый код, который будетгенерировать исключения. Существующий код в Google не может корректно работать с исключениями, поэтому цена внедрения исключений намного выше, чем реализация любого нового проекта. Переписывание существующего кодапод обработку исключений — это будет очень медленный процесс, с большим количеством ошибок. Поэтому лучше использовать альтернативу в виде возврата кода ошибки и assert-ов: это не так сложно.
Этот запрет также распространяется на добавленные в C++11 возможности, такие как std::exception_ptr и std::nested_exception.
Однако, для кода под Windows [11] есть послабления.
Указывайте noexcept, если это корректно и будет полезно.
Определение
Спецификатор noexcept используется для указания, что функция не будет выбрасывать исключения. Если же функция с таким спецификаторомвсё же выбросит исключение, то произойдёт крэш программы через std::terminate.
Также есть оператор noexcept. Он выполняет проверку: объявлено ли выражениекак «не выбрасывающее исключений». Проверка проводится на этапе компиляции.
За
Против
Вердикт
Используйте noexcept, когда это может улучшить производительность и точно отражает семантику функции (если из функции вылетело исключение, то это явная, фатальная ошибка).Считается, что noexcept на конструкторе перемещения может существенно улучшить производительность, учитывайте это.Если вы рассчитывайте на значительный прирост производительностиот применения noexcept для других функций, пожалуйста, сначала проконсультируйтесь с руководителем проекта.
Используйте безусловный noexcept, если исключения полностью запрещены (т.е. в типовом проекте C++ в Google).В ином случае, используйте спецификатор noexcept сусловиями (желательно простыми), которые становятся false в тех редких случаях, когда функция может всё-таки выбросить исключение.Эти тесты могут пользоваться проверками на характеристики типов(например, std::is_nothrow_move_constructible дляобъектов создаваемых через конструктор перемещения) или аллокаторов(например, absl::default_allocator_is_nothrow). Отметим, что наиболее частая причина исключений — невозможностьвыделения памяти (и да, мы верим, что это не относится к конструкторамперемещения — они не должны выбрасывать исключений из-за ошибок выделения памяти) и есть много приложений, для которых эта ситуацияозначает фатальную ошибку, которую даже не имеет смысла обрабатывать.И даже в других, потенциально ошибочных, ситуациях рекомендуетсяделать упор на простоту интерфейса, нежели на поддержку всех сценариевобработки ошибок: например, вместо написания накрученного noexceptс зависимостью от внешней хэш-функции (выбрасывает она исключения или нет), можно просто задокументировать, что разрабатываемый компонент не поддерживает хэш-функции, которые выбрасывают исключения. И, после этого, использовать noexcept без всяких дополнительных условий.
Не используйте информацию о типе во время выполнения (RTTI).
Определение
RTTI позволяет запросить информацию о C++ классе объектаво время выполнения. Делается через typeid илиdynamic_cast.
За
Типовые альтернативы вместо RTTI (описано ниже)требуют модификации или редизайна иерархии классов, участвующих в запросах. Иногда такую модификацию очень тяжело сделать, или она нежелательна, особенно в коде, который уже используется в других проектах.
RTTI может быть полезен для юнит-тестов. Например, можнотестировать классы-фабрики на правильность сгенерированного типа.Также это полезно в выстраивании связей между объектами и ихмакетами (mock).
RTTI бывает полезно при работе с абстрактными объектами. Например:
bool Base::Equal(Base* other) = 0;
bool Derived::Equal(Base* other) {
Derived* that = dynamic_cast<Derived*>(other);
if (that == nullptr)
return false;
...
}
Против
Часто сам запрос типа объекта в процессе выполнения означает проблемы с дизайном приложения, показывает наличие изъянов виерархии классов.
Бесконтрольное использование RTTI усложняет поддержку кода.Это может привести в развесистым условиям, которые зависят от типа объекта, которые рассыпаны по всему коду. И которые придётся досконально изучать если будет необходимость что-то изменить в этом коде.
Вердикт
Использование RTTI может легко привести к злоупотреблениям, поэтому будьте аккуратны. Старайтесь ограничить использование RTTI только юнит-тестами. Рекомендуется отказаться от RTTIв новом коде. Если же требуется написать код, которыйведёт себя по разному в зависимости от типа объекта, возможно следующие альтернативы будут более подходящими:
Когда логика программы гарантирует, чтополученный указатель на базовый класс фактически есть указательна определённый производный класс, тогда можно свободно использоватьdynamic_cast. Правда, в этом случае лучше использоватьstatic_cast.
Большое количество условий, основанных на типе объекта, естьпоказатель явных проблем в коде.
if (typeid(*data) == typeid(D1)) {
...
} else if (typeid(*data) == typeid(D2)) {
...
} else if (typeid(*data) == typeid(D3)) {
...
Подобный код может рассыпаться, когда добавляется новый дочерний класс в иерархию. И вообще, очень тяжело модифицироватьбольшое количество разрозненных кусков кода в случаенебольших изменений в свойствах или методах дочерних классов.
И пожалуйста, не изобретайте собственный велосипед на замену RTTI. Аргументы против собственного решения будут такие же (см. выше), да и разбираться в чужих велосипедах обычно сложнее.
Рекомендуется использовать приведение типов в C++-стиле: static_cast<float>(double_value). Также можно использовать инициализацию значением в скобках для преобразования арифметических типов: int64 y = int64{1} << 42. Избегайте конструкций вида int y = (int)x или int y = int(x) (хотя последний вариант допустим при вызове конструктора класса).
Определение
В C++ приведение типов расширяется по сравнению с чистым C путём добавления операций приведения.
За
Основная проблема с приведением типов в чистом C — неоднозначность операции. Например, одинаково записанная операция: (int)3.5 и (int)«hello» сильно отличается по смыслу. Инициализация в скобках и операции в стиле C++ часто помогают избежать такой неоднозначности. Дополнительная плюшка: операции приведения в стиле С++ легче искать по коду.
Против
C++-стиль довольно громоздкий.
Вердикт
Избегайте использования приведения типов в стиле чистого C. Вместо этого используйте стиль C++ когда требуется явное преобразование типов.
Также может быть полезным раздел RTTI [13] с описанием dynamic_cast.
Используйте потоки в подходящих случаях, особенно если их использование упрощает код. Перегружайте операцию << только для типов-значений и выводите в поток собственно данные (доступные пользователю). Не выводите в поток внутренние переменные (инварианты и т.д.) и другие детали реализации.
Определение
Потоки являются стандартной абстракцией для ввода/вывода в C++, (см. стандартный заголовочный файл <iostream>). Они часто используются в коде в Google, особенно для отладочного логирования и диагностики.
За
Операторы << и >> реализуют форматированный ввод/вывод, они просты в понимании, портабельны, расширяемы и повторно используемы. Противоположность к ним — printf, который даже не поддерживает работу с std::string. Кроме того не работает с пользовательскими типа и с портабельностью там проблемы. Кроме того, printf вынуждает выбирать среди похожих версий одной функции и ориентироваться в десятках форматных символах.
Потоки обеспечивают хорошую поддержку консольного ввода/вывода через std::cin, std::cout, std::cerr и std::clog. Функции из C API тоже хорошо работают, однако могут требовать вручную буферизировать ввод.
Против
Вердикт
Используйте потоки только если они являются наилучшим решением. Обычно это варианты ввода/вывода в человекочитаемый формат, предназначенный для разработчиков, а не для конечного пользователя. Также не забывайте, что в проекте уже могут быть устоявшиеся методы ввода/вывода — старайтесь использовать их. В частности, библиотеки для логирования и диагностического вывода обычно предпочтительнее нежели std::cerr или std::clog. И вместо std::stringstream лучше использовать absl/strings или их эквивалент.
Не рекомендуется использовать потоки для ввода/вывода в случае обмена данными с конечными пользователями или где возможно нарушение формата или валидности данных. В таких случаях используйте подходящие (шаблонные) библиотеки, которые корректно обрабатывают интернационализацию, локализацию, проверяют корректность данных и формата.
Если потоки всё же используются, старайтесь избегать API работы с состояниями, кроме состояния ошибки. Т.е. не используйте imbue(), xalloc() и register_callback(). Рекомендуется использовать явные функции форматирования (см. absl/strings) вместо манипуляторов или флагов форматирования для таких вещей как смена основания системы счисления, точности или набивка нулями до нужного размера чисел.
Перегружайте оператор << только для типа-значения с тем, чтобы оператор выводил человеко-читаемое представление. Не выводите в поток детали реализации или внутренние переменные. Если же требуется отладочная печать внутреннего состояния, то используйте обычные функции-методы (например, метод класса DebugString() — подходящий вариант).
Используйте префиксные формы (++i) инкремента и декремента над итераторами и другими шаблонными объектами.
Определение
Когда переменная инкрементируется (++i, i++) или декрементируется (--i, i--), а возвращаемое значение не используется, то необходимо чётко понимать: использовать префиксную форму (++i, --i) или постфиксную (i++, i--).
За
Когда возвращаемое значение игнорируется, то префиксная форма не менее эффективна постфиксной (чаще префиксная более эффективна). Связано это с тем, что постфиксная реализация должна сделать копию переменной с исходным значением для возврата результата. Если переменная является итератором или другим сложным типом, то копирование её может быть затратным по ресурсам. Поэтому, если обе формы ведут себя одинаково (возвращаемое значение игнорируется), почему бы не использовать всегда префиксную форму?
Против
Традиционно раньше в разработке (особенно на языке C) использовалась постфиксная форма, особенно для циклов for. Иногда программистам легче читать код с постинкрементом, т.к. «субъект» (i) стоит перед «действием» (++), как в английском предложении.
Вердикт
Для простых скалярных (не-объектов) типов нет особой разницы в использовании префиксной или постфиксной формы. Для итераторов и других шаблонных типов используйте префиксную форму.
В API используйте const когда это имеет смысл. В ряде случаев constexpr будет лучшей альтернативой const.
Определение
При объявлении переменных или параметров вначале может быть указано const, чтобы показать что переменные не изменяются (например, const int foo). Функции класса могут быть с квалификатором const, чтобы показать, что эта функция не изменяет состояние членов класса (например, class Foo { int Bar(char c) const; };).
За
Позволяет легко понять, как использовать переменные. Компиляторам даёт возможность полнее контролировать типы и, теоретически, генерировать лучший код. Использование констант даёт дополнительную защиту (уверенность) в корректности кода: функции не могут модифицировать переменные, изменять состояние класса и, как результат, можно безопасно работать без локов в многопоточном окружении.
Против
Использование const оно «заразное»: если передаётся const переменная в функцию, то она должна в прототипе иметь указание на const (или придётся делать const_cast). И это может быть проблемой при вызове библиотечных функций.
Вердикт
Настоятельно рекомендуется использовать const в API (параметры функций, методы, не-локальные переменные), где это имеет смысл. Такой подход даёт понятное (и верифицируемое компилятором) описание как можно модифицировать объекты. Чёткое разделение на модифицирующие (запись) и не-модифицирующие (только чтение) операции очень полезно, особенно для написания потокобезопасного кода. В частности:
Использование const для локальных переменных отдаётся на усмотрение программиста: можно использовать, можно — нет.
Все const операции класса должны работать корректно при одновременном вызове нескольких функций. Если это не выполняется, то класс должен быть явно описан как «потоко-не-безопасный».
Иногда используется форма int const *foo вместо const int* foo. Обосновывается это тем, что первая форма более логична: const следует за описываемым объектом. Однако, такая «логичность» имеет мало смысла (и обычно не применяется в коде с несколькими вложенными маркерами «указатель»), т.к. чаще всего есть только один const для базового значения. В таком случае нет необходимости специально заботиться о логичности. Размещение же const вначале делает код более читабельным и согласованным с английским языком: прилагательное (const) стоит перед существительным (int).
Так что расположение const вначале является предпочтительным. Однако, это не жёсткое условие и если остальной код в проекте использует другой порядок — следуйте за кодом!
Используйте constexpr для определения констант или чтобы сделать константную инициализацию.
Определение
Переменные можно объявлять как constexpr для указания на константу, значение которой определяется во время компиляции или линковки. Также можно объявлять функции и конструкторы как constexpr, чтобы их можно было использовать для определения переменной с constexpr.
За
constexpr позволяет определять выражения с плавающей запятой (помимо литералов), использовать константы для пользовательских типов и вызовов функций.
Против
Использование constexpr может вызвать проблемы с поддержкой кода (или миграцией), если константность нужно будет позже убрать. Текущие ограничения для константных функций или конструкторов могут потребовать реализации дополнительных обходных путей в коде.
Вердикт
constexpr позволяет определить неизменяемые части интерфейса. Используйте constexpr чтобы определить константы и функции для задания им значений. Не используйте constexpr, если это потребует усложнения кода. Не используйте constexpr, чтобы сделать код «встраиваемым» (inlining).
Среди встроенных целочисленных типов C++ необходимо использовать int. Если в программе требуется переменная другого размера, то используйте целочисленные типы фиксированной длины из <stdint.h>, такие как int16_t. Если переменной нужно хранить значения, равные или превышающие 2^31 (2GiB), используйте 64-битный тип int64_t. При оценке размера не забудьте, что в int должен укладываться не только результат, но и промежуточные значения при вычислениях. И, если сомневаетесь, используйте тип подлиннее.
Определение
C++ не уточняет размер целочисленных типов, таких как int. Обычно считается, что short содержит 16 битов, int — 32, long — 32 и long long содержит 64 бита.
За
Унификация в коде.
Против
Размеры целочисленных типов в C++ могут изменяться в зависимости от компилятора и архитектуры.
Вердикт
В <cstdint> определяются различные типы: int16_t, uint32_t, int64_t и т.д. Если требуются типы фиксированного размера, то не используйте short, unsigned long long и им подобные. Из целочисленных типов языка C можно использовать только int. Также, в соответствующих случаях, используйте size_t и ptrdiff_t.
Тип int используется очень часто, особенно для небольших значений, например как счётчики в циклах. Можете считать, что int содержит минимум 32 бита (но не больше). Если требуется 64 битный целочисленный тип, то используйте int64_t или uint64_t.
Для типа который может хранить «большие значения» используйте int64_t.
Старайтесь не использовать беззнаковые числа (например, uint32_t). Допустимое применение беззнаковых чисел это использование битовых представлений или использование переполнения (по модулю 2^N) в расчётах. Отметим, что также не рекомендуется использовать беззнаковый тип чтобы указать на отсутствие отрицательных значений: в этом случае используйте assert-ы.
Если код возвращает размер контейнера, то убедитесь, что его тип (размера) является достаточным для любого возможного использования. И если сомневаетесь, используйте тип подлиннее.
Будьте внимательны при конвертировании целочисленных типов. Может появится неопределённое поведение (UB), ведущее к багам безопасности и другим проблемам.
Беззнаковые целые числа отлично подходят для работы с битовыми полями и модульной арифметики. Так сложилось, что стандарт C++ использует беззнаковые числа и для возврата размера контейнеров (хотя многие члены организации по стандартизации и считают это ошибкой; в любом случае, сейчас это уже не изменить). Ситуация, что беззнаковая арифметика по поведению является модульной (заворачивание значений при переполнении) и отличается от обычной (знаковой), не позволяет компилятору диагностировать большое количество ошибок. Фактически, такое поведение затрудняет оптимизацию.
С другой стороны, совместное использование беззнаковых и знаковых целых чисел создаёт ещё больше проблем. Лучшее решение: старайтесь использовать итераторы вместо указателей и явных размеров; не мешайте беззнаковые числа вместе со знаковыми; избегайте беззнаковых чисел (кроме работы с битовыми полями и для модульной арифметики); не используйте беззнаковые числа только чтобы показать, что переменная неотрицательная.
Написанный код должен быть совместим как с 64-битной, так и с 32-битной архитектурой. Особое внимание обращайте на печать в консоль, операции сравнения и выравнивание структур.
Форматные символы printf() для некоторых целочисленных типов основываются на макроопределениях (например, PRI из <cinttypes>). И такой подход является непрактичным, нежелательным и т.д. Поэтому очень желательно не использовать функцию printf (и подобные) в своём коде, или даже переписать существующий код. Вместо неё можно использовать библиотеки, поддерживающие безопасное форматирование числовых значений, такие как StrCat
или Substitute
для простых преобразований, или std::ostream
.
К сожалению, макросы PRI являются единственным переносимым способом указать формат для типов данных с задаваемым размером (int64_t, uint64_t, int32_t, uint32_t и т.д.). По возможности не передавайте аргументы таких типов в функции, основанные на printf. Исключение составляют типы, для которых есть свой выделенный модификатор длины, например size_t (z), ptrdiff_t (t) и maxint_t (j).
Используйте инициализацию в фигурных скобках [16] если требуется создать 64-битную константу. Например:
int64_t my_value{0x123456789};
uint64_t my_mask{3ULL << 48};
Избегайте определения макросов, особенно в заголовочных файлах. Вместо этого используйте встраиваемые функции, перечисления или переменные-константы. Если используете макросы, то в имени используйте префикс — название проекта. Не используйте макросы, чтобы переопределить или дополнить C++ API.
Использование макросов подразумевает, что программист видит один код, а компилятор — другой. Это может вызвать неожиданные последствия, особенно если макросы глобальные.
Ситуация может усугубиться, когда макросы используются для переопределения С++ или другого публичного API. При любых ошибках в использовании API потребуется разбираться в логике макросов; увеличивается время разбора кода инструментами рефакторинга или анализаторами. Как результат, использование макросов в таких случаях запрещено. Например, откажитесь от подобного кода:
class WOMBAT_TYPE(Foo) {
// ...
public:
EXPAND_PUBLIC_WOMBAT_API(Foo)
EXPAND_WOMBAT_COMPARISONS(Foo, ==, <)
};
К счастью, в C++ зависимость от макросов поменьше, чем в C. Вместо макросов для высокопроизводительного кода можно использовать встраиваемые функции. Для хранения констант есть const переменные. Чтобы для удобства «укоротить» длинное имя переменной используйте ссылки. Вместо применения макросов для условной компиляции кода используйте… лучше не используйте условную компиляцию (конечно же это не касается защиты от повторного включения заголовочных файлов через #define). Тем более условная компиляция затрудняет тестирование кода.
С другой стороны, есть приёмы кодирования, которые делаются только через макросы. Обычно это можно увидеть в низко-уровневых библиотеках. Также есть приёмы (преобразование в строку, объединение строк и т.д.), которые нельзя сделать средствами самого языка напрямую. В любом случае, перед использованием макросов попробуйте найти способ реализации без макросов. Если же необходимо использовать макросы для определения интерфейса то предварительно обязательно проконсультируйтесь с руководством.
Следующие правила позволят избежать ряда проблем с макросами. По возможности следуйте им:
Настоятельно не рекомендуется экспортировать макросы из заголовочных файлов (т.е. определять макрос и не делать #undef его в конце заголовочного файла). Если макрос экспортируется из заголовочного файла, то он должен иметь глобальное уникальное имя. Как вариант, добавьте префикс с именем пространства имён проекта (заглавными буквами).
Используйте nullptr для указателей и '' для char-ов (не используйте 0 для этих целей).
Для указателей (адресов) используйте nullptr, это улучшает безопасность типов.
Для проектов C++03 лучше используйте NULL, а не 0. Хотя оба варианта эквивалентны, NULL обычно ассоциируется с указателями. Также некоторые C++ компиляторы могут определять NULL специальным образом и выдавать более адекватные предупреждения компиляции. Никогда не используйте NULL как числовое значение (целочисленное или с плавающей запятой).
Используйте '' в качестве символа конца строки (пустого символа). Это улучшает читабельность кода.
Рекомендуется использовать sizeof(переменная) вместоsizeof(тип).
Используйте sizeof(переменная) если необходим размер определённой переменной. sizeof(переменная) будет возвращать корректное значение даже если в дальнейшем изменится тип переменной. sizeof(тип) можно использовать, когда код не работает с конкретной переменной, например в случае форматирования/разбора данных, где соответствующий тип C++ не подходит.
struct data;
memset(&data, 0, sizeof(data));
memset(&data, 0, sizeof(Struct)); // Плохо
if (raw_size < sizeof(int)) {
LOG(ERROR) << "compressed record not big enough for count: " << raw_size;
return false;
}
Используйте вывод типов только если это сделает код более читабельным или более безопасным. Не используйте его только из-за неудобства написания полного типа.
Определение
Есть ряд ситуаций, когда типы в C++ коде могут (или даже необходимо) быть выведены компилятором и это более предпочтительно, чем явно их прописывать:
template <typename T>
void f(T t);
f(0); // Вызывается f<int>(0)
auto a = 42; // a типа int
auto& b = a; // b типа int&
auto c = b; // c типа int
auto d{42}; // d типа int, а не std::initializer_list<int>
auto может использоваться совместно с const, или в составе указателя или ссылки. Однако, auto не может использоваться как аргумент шаблона. Изредка можно увидеть использование decltype(auto) вместо auto и в этом случае выводимый тип является результатом применения decltype
к переданному выражению инициализации (прим.: и, например, сохранить квалификаторы ссылки).
auto f() { return 0; } // Возвращаемый f тип - int
Возвращаемый тип лямбды [20] может быть выведен аналогичным способом (хотя это делается при отсутствии возвращаемого типа, а не в случае использования auto). Синтаксис указания возвращаемого типа в конце [21] для функций также использует auto, но это не вывод типа, скорее альтернативный синтаксис для явно указанного возвращаемого типа.
// Сортируем `vec` по возрастанию
std::sort(vec.begin(), vec.end(), [](auto lhs, auto rhs) { return lhs > rhs; });
[x = 42, y = "foo"] { ... } // тип x - int, y - const char*
Синтаксис не позволяет указать тип новой переменной, он выводится аналогично auto переменным.
auto [iter, success] = my_map.insert({key, value});
if (!success) {
iter->second = value;
}
auto можно использовать с квалификаторами const, & и &&. Отметим, что эти квалификаторы формально применяются к анонимному кортежу/структуре/массиву, а не к отдельным привязкам. Правила определения конечного типа привязок довольно запутанные, однако в большинстве случаев всё довольно логично. Можно только отметить, что тип привязки обычно не может быть ссылочным, даже если в декларации указана ссылка (хотя поведение всё равно может быть как у ссылки).
В приведённом выше описании не указаны многие детали, для дополнительной информации используйте приведённые ссылки.
За
Против
При явном указании типов код C++ становится более ясным и понятным, особенно если вывод типов опирается на информацию из совершенно другой части кода. В выражении наподобие:
auto foo = x.add_foo(); // Плохо. Что есть foo?
auto i = y.Find(key);
может быть неочевидно какие типы выводятся для переменных, особенно если y не является хорошо известным типом или объявлен намного раньше по коду.
Необходимо разбираться, выдаётся ли ссылка при выводе типа, производится ли копирование (особенно если оно не предполагалось).
Если выводимые типы используется как часть интерфейса, то любые незначительные изменения в выражениях могут привести к радикальным изменениям API.
Вердикт
Основное правило: используйте вывод типов только если это сделает код более ясным и безопасным. Не используйте вывод типов только чтобы облегчить написание кода. Не забывайте, что читатели кода могут быть в другой команде и не знакомы с этим проектом. Поэтому, хотя явные типы могут считаться понятным, очевидным и избыточными для одних, они могут содержать полезную информацию для других. Например, можно полагать, что возвращаемый тип make_unique<Foo>() очевиден. Однако, в случае MyWidgetFactory() лучше считать по-другому.
Эти принципы применяются для всех видов вывода типов. Однако, существуют тонкости, описанные ниже.
Вывод аргументов шаблонной функции это практически всегда хорошо. Это стандартный и ожидаемый способ работы с шаблонными функциями, т.к. вызов такой функции напоминает работу с обычной (но перегруженной для различных аргументов) функцией. И шаблонные функции желательно проектировать так, чтобы вывод аргументов был корректный и безопасный, или функция не должна компилироваться.
В случае локальных переменных можно использовать вывод типов, чтобы сделать код более простым, убрав очевидную или нежелательную информацию о типах, и читатель может сконцентрироваться на важных частях кода. Сравните примеры кода:
std::unique_ptr<WidgetWithBellsAndWhistles> widget_ptr =
absl::make_unique<WidgetWithBellsAndWhistles>(arg1, arg2);
absl::flat_hash_map<std::string,
std::unique_ptr<WidgetWithBellsAndWhistles>>::const_iterator
it = my_map_.find(key);
std::array<int, 0> numbers = {4, 8, 15, 16, 23, 42};
auto widget_ptr = absl::make_unique<WidgetWithBellsAndWhistles>(arg1, arg2);
auto it = my_map_.find(key);
std::array numbers = {4, 8, 15, 16, 23, 42};
Типы иногда содержат смесь как полезной, так и формальной информации. Например в примере выше очевидно, что it это итератор. Вообще в большинстве аналогичных случаев информация о контейнере и даже типе ключа не особо полезна, однако тип значения обычно важен. В этом случае можно определить локальную переменную с явно указанным (полезным для читателя) типом:
auto it = my_map_.find(key);
if (it != my_map_.end()) {
WidgetWithBellsAndWhistles& widget = *it->second;
// Do stuff with `widget`
}
Если тип является шаблонным, у которого параметры неинформативны, но тип самого шаблона является важным, то можно использовать вывод аргументов шаблонного класса чтобы избавиться от формального (ненужного) кода. Отметим что случаи, когда это является полезным, довольно редки. Также учтите, что при использовании вывода аргументов шаблонного класса желательно следовать специальным рекомендациям [25].
Не используйте decltype(auto) при наличии более простых альтернатив, т.к. результат использования не всегда легко предсказуем.
Используйте вывод типа возвращаемого значения (как для функция, так и для лямбд), только если тело функции содержит небольшое количество return и сам код небольшой. В противном случае читатель не сможет понять возвращаемый тип без его исследования. Также применяйте такой вывод типов только для функций или лямбд с очень маленькой областью видимости, т.к. функции не могут установить границы абстракции: сама реализация формирует интерфейс. В частности, публичные функции в заголовочных файлах никогда не должны использовать вывод типа возвращаемого значения.
Параметры с auto в ламбдах должны использовать с осторожностью, т.к. реальный тип определяется кодом лямбды, а не её объявлением. И, конечно, явное указание типа обычно более понятно, за исключением случаев, когда лямбда определяется рядом с местом её использования (можно одновременно видеть и определение лямбды и её вызов) или лямбда передаётся в настолько известный интерфейс, что используемые аргументы очевидны (например, см. вызов std::sort выше).
При инициализации переменных захвата предпочтительны специальные рекомендации [20], которые в целом подменяют общие правила для использования вывода типов.
В отличие от других форм вывода типов, структурные привязки могут дать дополнительную информацию за счёт правильного именования элементов полного объекта. Т.е. декларация структурной привязки может улучшить читабельность кода по сравнению с использованием явного типа (даже если auto не рекомендуется). Структурные привязки хорошо подходят при работе с парами или кортежами (см. пример использования insert выше), потому что в последних нет «говорящих» названий полей. С другой стороны, в целом не рекомендуется использовать пары и кортежи [27], пока внешний API, наподобие insert, явно этого не потребует.
Если объектом привязки является структура, иногда может быть полезно указать имена, лучше подходящие для данного кода. Однако учитывайте, что такие имена могут быть менее понятны читателям кода, чем штатные имена полей. Рекомендуется использовать комментарии для указания имён полей, если они отличаются от имён привязок. Используйте синтаксис, аналогичный комментариям к параметрам функций:
auto [/*field_name1=*/ bound_name1, /*field_name2=*/ bound_name2] = ...
Также, как и с параметрами функций, комментарии могут помочь внешним инструментам определить ошибки в порядке указания полей.
Используйте вывод аргументов только для тех шаблонных классов, что явно поддерживают это.
Определение
Вывод аргументов шаблонного класса [24] (CTAD) проявляется, когда переменная декларируется с типом шаблона, но без указания аргументов (даже без угловых скобок):
std::array a = {1, 2, 3}; // Тип `a`: std::array<int, 3>
Компилятор выводит аргументы из выражения инициализации, используя «гайд» для шаблонов, который может быть явный и неявный.
Явный гайд походит на декларацию функции с возвращаемым типом в конце, только без auto вначале, и имя функции есть имя шаблона. Например, ранее приведённый пример опирается на следующий гайд для std::array:
namespace std {
template <class T, class... U>
array(T, U...) -> std::array<T, 1 + sizeof...(U)>;
}
Конструкторы в основном определении шаблона (т.е. не в специализации) также неявно определяют «гайд».
Когда объявляется переменная, использующая CTAD, компилятор выбирает «гайд» на основе правил выбора (разрешения) перегруженного конструктора, и возвращаемый гайдом тип становится типом переменной.
За
CTAD иногда может уменьшить количество формального кода.
Против
Неявные «гайды», получаемые из конструкторов, могут реализовывать нежелательное или даже неправильное поведение. Эта проблема может часто проявляться для конструкторов, написанных до появления CTAD в C++17, т.к. авторы кода просто не знали о тех проблемах, которые вызовет CTAD. И далее, добавление явных «гайдов» для исправления проблемы может поломать любой существующий код, который использует неявные гайды.
У CTAD есть много недостатков, аналогичных недостаткам auto, т.к. оба механизма выводят (полный или частичный) тип переменной на основе инициализации. CTAD выдаёт больше информации, чем auto, однако всё равно не содержит явного указания, если информация была пропущена.
Вердикт
Не используйте CTAD на шаблонных классах, пока не будет поддержки механизма и обеспечен хотя бы один явный «гайд» (предполагается, что в пространстве имён std всё поддерживается). Желательно, чтобы недопустимое использование CTAD приводило к предупреждениями компилятора.
В любом случае, использование CTAD должно следовать общим правилам при выводе типов [28].
Используйте лямбды в подходящих случаях. Желательно использовать явный захват переменных, если лямбда будет выполнена вне текущей области видимости.
Определение
Лямбды это лаконичный и удобный способ создания объектов — анонимных функций. Особенно они полезны, когда нужно передавать функцию как аргумент. Например:
std::sort(v.begin(), v.end(), [](int x, int y) {
return Weight(x) < Weight(y);
});
Лямбды также позволяют захватывать переменный из текущей области видимости либо (явно) по имени, либо (неявно) через захват по-умолчанию. Явный захват предписывает перечислить все требуемые переменные: либо как значения, либо как ссылки:
int weight = 3;
int sum = 0;
// Захват `weight` по значению и `sum` по ссылке.
std::for_each(v.begin(), v.end(), [weight, &sum](int x) {
sum += weight * x;
});
Захват по-умолчанию применяется ко всем переменным, используемым в теле лямбды, в том числе и к this (если используются члены класса):
const std::vector<int> lookup_table = ...;
std::vector<int> indices = ...;
// Захват `lookup_table` по ссылке, сортировка `indices` по значению
// ассоциированных элементов из `lookup_table`.
std::sort(indices.begin(), indices.end(), [&](int a, int b) {
return lookup_table[a] < lookup_table[b];
});
Захват переменной может быть также с инициализатором, что можно использовать для перемещения (move) переменных по значению или для других случаев, не подпадающих под обычный захват по значению или ссылке:
std::unique_ptr<Foo> foo = ...;
[foo = std::move(foo)] () {
...
}
Такой тип захвата (часто называемый init или generalized) нужен скорее не для собственно «захвата» переменных (или даже имён) из текущей области видимости. Этот синтаксис нужен для определения членов объекта лямбды:
[foo = std::vector<int>({1, 2, 3})] () {
...
}
И тип такой переменной с инициализатором выводится согласно правилам, аналогичным использованию auto.
За
Против
Вердикт
{
Foo foo;
...
executor->Schedule([&] { Frobnicate(foo); })
...
}
// ПЛОХО! При беглом просмотре можно упустить, что лямбда использует
// ссылку на foo и this (если Frobnicate является членом класса).
// Если лямбда вызывается после возврата из текущей функции, то
// это приведёт к проблемам, т.к. foo и другие объекты могут быть
// уже разрушены.
лучше написать:
{
Foo foo;
...
executor->Schedule([&foo] { Frobnicate(foo); })
...
}
// ЛУЧШЕ - Компилятор выдаст ошибку, если Frobnicate является методом класса.
// Также явно указано, что foo захватывается по ссылке.
Не используйте сложные/запутанные шаблоны в коде.
Определение
Метапрограммирование на шаблонах это семейство техник, использующих возможности по инстанцированию шаблона в C++, которое Тьюринг-полное, для выполнения вычислений на этапе компиляции.
За
Метапрограммирование позволяет создавать очень гибкие интерфейсы, у которых высокая производительность и отличная типобезопасность. Например, Google Test [30], std::tuple, std::function и Boost.Spirit были бы невозможны без таких средств.
Против
Техники метапрограммирования часто непонятны всем, кроме экспертов языка. Код, использующий шаблоны запутанными/сложными способами, часто нечитабелен, его сложно отлаживать и поддерживать.
Метапрограммирование часто приводит к появлению очень скудной и непонятной информации об ошибках компиляции: даже если сам интерфейс простой, то его сложная реализация всё равно проявляется, когда пользователь делает что-то неправильно.
Метапрограммирование усложняет проведение рефакторинга, затрудняя работу инструментов. Во-первых, код шаблона раскрывается в различных контекстах и трудно проверить, что в каждом из них код остаётся корректным. Во-вторых, ряд инструментов работает уже с AST (прим.: абстрактное синтаксическое дерево), которое описывает структуру кода только после раскрытия шаблонов. И в этом случае может быть тяжело обнаруженные проблемы отобразить на исходные конструкции в коде и определить, что требуется переписать.
Вердикт
Метапрограммирование в ряде случаев позволяет создать понятные и простые в использовании интерфейсы (которые были бы сложнее в ином случае), однако есть соблазн всё сделать чересчур заумным. Поэтому его лучше использовать в небольшом количестве низкоуровневых компонентов, чтобы сложность поддержки компенсировалась полезностью и широтой применения.
Дважды подумайте перед тем, как использовать метапрограммирование или другие сложные техники на шаблонах: может ли средний программист в команде понять и поддерживать такой код (особенно после переключения с другого проекта); сможет ли не-C++ программист (или другой случайный читатель) понять сообщения об ошибках или отладить выполнение функции, которую он вызывает. Если используются рекурсивное инстанцирование шаблонов, список типов, метафункции, шаблоны выражений или используется SFINAE или трюк с sizeof для разрешения перегрузки функции — скорее всего вы зашли слишком далеко.
Если используется метапрограммирование, то готовьтесь приложить усилия для минимизации сложности, а также её изоляции. По возможности скрывайте код с метапрограммированием внутри реализации, чтобы сделать пользовательские заголовочные файлы более читабельными. Код с метапрограммированием должен быть очень хорошо откомментирован: следует подробно задокументировать, как использовать код и на что будет похож «сгенерированный» результат. Обратите особое внимание на сообщения об ошибках, которые выдаёт компилятор, когда делается что-то ошибочное. Учтите, что сообщения об ошибках являются частью вашего пользовательского интерфейса и код следует доработать так, чтобы сообщения об ошибках были понятными для пользователя и объясняли, что нужно делать для их исправления.
Используйте только одобренные библиотеки из коллекции Boost.
Определение
Boost [31] это популярная коллекция проверенных, бесплатных и открытых библиотек C++.
За
В целом код Boost является высококачественным, портируемым и во многом дополняется стандартную библиотеку C++, например, в таких областях как свойства типов или улучшенные связыватели (binder).
Против
Некоторые библиотеки Boost поощряют создание кода, который ухудшает читабельность: используется метапрограммирование или другие продвинутые техники на шаблонах, а также чрезмерно «функциональный» стиль.
Вердикт
Чтобы читабельность кода оставалась высокой для всех, кто осуществляет его поддержку, разрешены к использованию только некоторые библиотеки из коллекции Boost. В настоящее время это:
В настоящее время прорабатывается вопрос о добавлении других библиотек Boost в этот список, так что он может в будущем дополняться.
Не определяйте специализации std::hash.
Определение
std::hash<T> это объект-функция, который hash контейнеры C++11 используют для получения хэш-ключа от типа T, если явно не указана другая хэш-функция. Например, std::unordered_map<int, std::string> это hash map, используюущая std::hash<int> для расчёта хэша ключа, тогда как std::unordered_map<int, std::string, MyIntHash> использует для расчёта MyIntHash.
std::hash определена для всех целочисленных чисел и с плавающей запятой, указателей, enum-ов, некоторых типов стандартной библиотеки (например, string и unique_ptr). Также допустимо определить специализацию для своих собственных типов.
За
std::hash легко использовать, она упрощает код, т.к. нет необходимости вводить свои именования. Специализация std::hash это стандартный способ определения хэша, удобный и понятный и новичкам и внешним командам.
Против
Хорошую специализацию std::hash может быть сложно написать: она может содержать большое количество формального и одинакового кода. Также это может потребовать усилий и по идентификации входных данных и по созданию самого алгоритма. Автор типа данных обычно ответственен за первое, а со вторым чаще всего возникают проблемы, т.к. это требует определённой экспертизы, которой у автора обычно нет (да она и не нужна). При этом плохая реализация алгоритма может внести уязвимости в безопасность кода, например от атак hash flooding [47].
Даже для экспертов создание хорошей специализации std::hash может представлять сложность, особенно для составных типов, т.к. хорошая реализация не может просто рекурсивно вызывать std::hash на всех членах данных. Высококачественные хэш-алгоритмы содержат большое количество внутренних состояний, и упаковка их в размер size_t (что функция std::hash и возвращает) обычно является самой медленной частью в вычислениях, так что это должно выполняться не более одного раза.
Именно из-за этого std::hash не работает с std::pair и std::tuple, и в язык не добавлена их поддержка.
Вердикт
Можно использовать std::hash с типами, которые поддерживаются «из коробки», но не добавляйте специализации для своих типов. Если требуется хэш-таблица с ключом, который не поддерживается std::hash, то возможно следует воспользоваться другими (ранними) хэш-контейнерами (например, hash_map); в них используется другой хэш-алгоритм, на который этот запрет не влияет.
Если всё равно требуется стандартный контейнер, то задаёте собственную хэш-функцию для ключа, например:
std::unordered_map<MyKeyType, Value, MyKeyTypeHasher> my_map;
Прежде всего узнайте у автора типа данных о наличии готовой хэш-функции (а вдруг?). В противном случае создавайте свою, в сотрудничестве с автором, или без него.
Возможно, скоро появится хэш-функция, которая сможет работать с любым типом и использовать новый механизм подстройки, при этом у неё не будет недостатков std::hash.
Некоторые расширения современного C++, также как и Boost [48], содержат код с плохой читабельностью, с удалённой добавочной информацией о типах, с использованием метапрограммирования. Другие же расширения дублируют существующий функционал, что может привести к путанице и дополнительной конвертации кода.
Вердикт
Настоятельно не рекомендуется использовать следующие возможности C++:
Нестандартные расширения C++ не рекомендуется использовать, пока явно не указано обратное.
Определение
Компиляторы поддерживают различные расширения, не являющиеся частью стандартного C++. Например, __attribute__, внутренние (intrinsic) функции (__builtin_prefetch), назначенные инициализаторы (Foo f = {.field = 3}), ассемблерные вставки, __COUNTER__, __PRETTY_FUNCTION__, составные выражения (foo = ({ int x; Bar(&x); x }), массивы переменной длины, alloca() и "оператор Элвис [49]" a?:b.
За
Против
Вердикт
Не используйте нестандартные расширения. Можно использовать портируемые обёртки кода, которые реализованы с использованием нестандартных расширений и и (желательно) содержатся в одном заголовочном файле (portability header).
Публичные псевдонимы предназначены для использования с API и должны быть хорошо документированы.
Определение
Есть несколько способов для создания имён, являющихся псевдонимами для других сущностей:
typedef Foo Bar;
using Bar = Foo;
using other_namespace::Foo;
При написании нового кода рекомендуется использовать using, а не typedef. Это обеспечивает более согласованный синтаксис с остальным C++ кодом и поддерживает работу с шаблонами.
Аналогично другим декларациям, псевдонимы, введённые в заголовочном файле, обычно являются частью публичного API этого файла. Исключения касаются случаев, когда псевдонимы объявлены внутри определения функции, private секции класса или явно отмеченном внутреннем пространстве имён. Такие псевдонимы, а также введённые в .cc файлах являются «деталями реализации» (т.к. клиентский код к ним не обращается) и не подпадают под действие этих правил.
За
Против
Вердикт
Не вводите псевдонимы в публичный API только для облегчения написания кода в реализации; псевдоним должен прежде всего быть полезен для клиентского кода.
Определяя публичный псевдоним, обязательно опишите назначение нового имени, будет ли псевдоним всегда соответствовать текущему типу или будет более ограниченная совместимость. С одной стороны, это позволит узнать, является ли псевдоним заменителем типа или необходимо следовать более специфическим правилам. С другой стороны, это может дать определённую свободу при изменении псевдонима в дальнейшем.
Не объявляйте публичные псевдонимы на пространства имён в своём API. (См. также Пространство имён [50]).
Например, следующие псевдонимы описывают способ их использования в клиентском коде:
namespace mynamespace {
// Используется для хранения измерений. DataPoint может меняться с Bar* на другой
// внутренний тип, его следует трактовать как абстрактный указатель.
using DataPoint = foo::Bar*;
// Набор измерений. Добавлен для удобства пользователя.
using TimeSeries = std::unordered_set<DataPoint, std::hash<DataPoint>, DataPointComparator>;
} // namespace mynamespace
Приведённые ниже псевдонимы не документируют способы использования и часть из нихвообще не предназначения для использования в клиентском коде:
namespace mynamespace {
// Плохо: непонятно, как это использовать.
using DataPoint = foo::Bar*;
using std::unordered_set; // Плохо: это для внутреннего удобства
using std::hash; // Плохо: это для внутреннего удобства
typedef unordered_set<DataPoint, hash<DataPoint>, DataPointComparator> TimeSeries;
} // namespace mynamespace
Однако, локальные псевдонимы очень удобны внутри определения функций, private секций классов, внутренних пространств имён и в .cc файлах:
// В .cc файле
using foo::Bar;
Автор:
Apoheliy
Источник [52]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/c-3/369316
Ссылки в тексте:
[1] Часть 1. Вступление: https://habr.com/ru/post/480422/
[2] Часть 6. Специфика Google: https://habr.com/ru/post/584642/
[3] Часть 8. Именование: https://habr.com/ru/post/477722/
[4] Исходная статья: https://github.com/evgenykislov/styleguide/blob/gh-pages/cppguide.html
[5] обновляемый перевод: https://evgenykislov.com/wp-content/custom/cpp_codestyle/cppguide_ru.html
[6] перегружаемых функций: #Function_Overloading
[7] Forwarding references: #Forwarding_references
[8] Копируемые и перемещаемые типы: #Copyable_Movable_Types
[9] C++ Primer: http://primer#copying_moving
[10] std::forward: http://en.cppreference.com/w/cpp/utility/forward
[11] кода под Windows: #Windows_Code
[12] const: #Use_of_const
[13] RTTI: #Run-Time_Type_Information__RTTI_
[14] средства поддержки локализации: http://www.boost.org/doc/libs/1_48_0/libs/locale/doc/html/rationale.html#rationale_why
[15] TotW #109: https://abseil.io/tips/109
[16] инициализацию в фигурных скобках: #Casting
[17] вывод типов аргументов шаблонной функции: https://en.cppreference.com/w/cpp/language/template_argument_deduction
[18] переменная с auto типом: https://en.cppreference.com/w/cpp/language/auto
[19] вывод типа возвращаемого значения функции: https://en.cppreference.com/w/cpp/language/function#Return_type_deduction
[20] лямбды: #Lambda_expressions
[21] возвращаемого типа в конце: http://trailing_return
[22] общие (generic) лямбды: https://isocpp.org/wiki/faq/cpp14-language#generic-lambdas
[23] инициализация захватываемых переменных лямбды: https://isocpp.org/wiki/faq/cpp14-language#lambda-captures
[24] вывод аргументов шаблонного класса: https://en.cppreference.com/w/cpp/language/class_template_argument_deduction
[25] соответствующий раздел: #CTAD
[26] структурная привязка: https://en.cppreference.com/w/cpp/language/structured_binding
[27] не рекомендуется использовать пары и кортежи: #Structs_vs._Tuples
[28] выводе типов: #Type_deduction
[29] ниже: #Formatting_Lambda_Expressions
[30] Google Test: https://code.google.com/p/googletest/
[31] Boost: https://www.boost.org/
[32] Call Traits: https://www.boost.org/libs/utility/call_traits.htm
[33] Compressed Pair: https://www.boost.org/libs/utility/compressed_pair.htm
[34] Boost Graph Library (BGL): https://www.boost.org/libs/graph/
[35] Property Map: https://www.boost.org/libs/property_map/
[36] Iterator: https://www.boost.org/libs/iterator/
[37] Polygon: https://www.boost.org/libs/polygon/
[38] Bimap: https://www.boost.org/libs/bimap/
[39] Statistical Distributions and Functions: https://www.boost.org/libs/math/doc/html/dist.html
[40] Special Functions: https://www.boost.org/libs/math/doc/html/special.html
[41] Root Finding Functions: https://www.boost.org/libs/math/doc/html/root_finding.html
[42] Multi-index: https://www.boost.org/libs/multi_index/
[43] Heap: https://www.boost.org/libs/heap/
[44] Container: https://www.boost.org/libs/container/
[45] Intrusive: https://www.boost.org/libs/intrusive/
[46] Preprocessor: https://www.boost.org/libs/preprocessor/
[47] hash flooding: https://emboss.github.io/blog/2012/12/14/breaking-murmur-hash-flooding-dos-reloaded/
[48] Boost: #Boost
[49] оператор Элвис: https://en.wikipedia.org/wiki/Elvis_operator
[50] Пространство имён: #Namespaces
[51] открытого источника: https://www.pexels.com/photo/toddler-girl-wearing-long-sleeved-top-reading-book-while-sitting-on-bed-860536/
[52] Источник: https://habr.com/ru/post/586550/?utm_source=habrahabr&utm_medium=rss&utm_campaign=586550
Нажмите здесь для печати.