Rtti c что это

Также может быть полезным раздел RTTI с описанием dynamic_cast.

Потоки / Streams

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

Определение
Потоки являются стандартной абстракцией для ввода/вывода в C++, (см. стандартный заголовочный файл <iostream>). Они часто используются в коде в Google, особенно для отладочного логирования и диагностики.

За
Операторы << и >> реализуют форматированный ввод/вывод, они просты в понимании, портабельны, расширяемы и повторно используемы. Противоположность к ним — printf, который даже не поддерживает работу с std::string. Кроме того не работает с пользовательскими типа и с портабельностью там проблемы. Кроме того, printf вынуждает выбирать среди похожих версий одной функции и ориентироваться в десятках форматных символах.

Потоки обеспечивают хорошую поддержку консольного ввода/вывода через std::cin, std::cout, std::cerr и std::clog. Функции из C API тоже хорошо работают, однако могут требовать вручную буферизировать ввод.

• Форматирование потоков можно настроить через манипуляторы, изменяющие состояние потока. Учтите, применение манипуляторов сохраняется во времени и, как результат, поведение кода зависит от истории использования потока (или необходимо будет всё восстанавливать в известное состояние после каждого случая возможного применения манипуляторов). Кроме того, пользовательский код может (помимо модификации встроенных параметров) создавать собственные манипуляторы, добавлять переменные состояния и изменять поведение через функционал register_callback.
• Проблематично полностью контролировать вывод потока: смена настроек (см. выше), вывод мешанины из параметров и собственно данных, использование перегрузки операторов (и компилятор может выбрать не ту перегрузку, которая предполагалась) — всё это не добавляет управляемости.
• Формирование вывода посредством вызова цепочки операторов << затрудняет локализацию, т.к. при этом жёстко, прямо в коде, фиксируется порядок слов. И средства поддержки локализации лишаются ценности.
• Потоковый API может быть сложным, с тонкостями. И программисты должны уметь с ним работать, чтобы код был эффективным.
• Выбор правильной версии оператора << из большого количества аналогичных является для компилятора затратным. При частом их использовании в большой кодовой базе, время парсинга и анализа может отъедать до 20% времени.

Вердикт
Используйте потоки только если они являются наилучшим решением. Обычно это варианты ввода/вывода в человекочитаемый формат, предназначенный для разработчиков, а не для конечного пользователя. Также не забывайте, что в проекте уже могут быть устоявшиеся методы ввода/вывода — старайтесь использовать их. В частности, библиотеки для логирования и диагностического вывода обычно предпочтительнее нежели 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) стоит перед «действием» (++), как в английском предложении.

Вердикт
Для простых скалярных (не-объектов) типов нет особой разницы в использовании префиксной или постфиксной формы. Для итераторов и других шаблонных типов используйте префиксную форму.

Использование const

В API используйте const когда это имеет смысл. В ряде случаев constexpr будет лучшей альтернативой const.

Определение
При объявлении переменных или параметров вначале может быть указано const, чтобы показать что переменные не изменяются (например, const int foo). Функции класса могут быть с квалификатором const, чтобы показать, что эта функция не изменяет состояние членов класса (например, class Foo < int Bar(char c) const; >;).

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

Против
Использование const оно «заразное»: если передаётся const переменная в функцию, то она должна в прототипе иметь указание на const (или придётся делать const_cast). И это может быть проблемой при вызове библиотечных функций.

Вердикт
Настоятельно рекомендуется использовать const в API (параметры функций, методы, не-локальные переменные), где это имеет смысл. Такой подход даёт понятное (и верифицируемое компилятором) описание как можно модифицировать объекты. Чёткое разделение на модифицирующие (запись) и не-модифицирующие (только чтение) операции очень полезно, особенно для написания потокобезопасного кода. В частности:

• Если функция не меняет аргумент, переданный по ссылке или указателю, то он должен быть ссылкой на константу (const T&), либо указателем на константу (const T*).
• Если параметр передаётся по значению, то использование const не даёт никакого эффекта. Поэтому не рекомендуется объявлять константный параметр. См. также TotW #109.
• Старайтесь объявлять члены класса константными (const) если они не изменяют логическое состояние объекта (и не дают возможности другим что-то менять, например через возврат не-константной ссылки). В противном случае эти методы могут быть небезопасными в многопоточном окружении.

Использование const для локальных переменных отдаётся на усмотрение программиста: можно использовать, можно — нет.

Все const операции класса должны работать корректно при одновременном вызове нескольких функций. Если это не выполняется, то класс должен быть явно описан как «потоко-не-безопасный».

Местоположение const

Иногда используется форма int const *foo вместо const int* foo. Обосновывается это тем, что первая форма более логична: const следует за описываемым объектом. Однако, такая «логичность» имеет мало смысла (и обычно не применяется в коде с несколькими вложенными маркерами «указатель»), т.к. чаще всего есть только один const для базового значения. В таком случае нет необходимости специально заботиться о логичности. Размещение же const вначале делает код более читабельным и согласованным с английским языком: прилагательное (const) стоит перед существительным (int).

Так что расположение const вначале является предпочтительным. Однако, это не жёсткое условие и если остальной код в проекте использует другой порядок — следуйте за кодом!

Использование constexpr

Используйте 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-бит

Написанный код должен быть совместим как с 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).

Используйте инициализацию в фигурных скобках если требуется создать 64-битную константу. Например:

Макросы препроцессора

Избегайте определения макросов, особенно в заголовочных файлах. Вместо этого используйте встраиваемые функции, перечисления или переменные-константы. Если используете макросы, то в имени используйте префикс — название проекта. Не используйте макросы, чтобы переопределить или дополнить C++ API.

Использование макросов подразумевает, что программист видит один код, а компилятор — другой. Это может вызвать неожиданные последствия, особенно если макросы глобальные.

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

К счастью, в C++ зависимость от макросов поменьше, чем в C. Вместо макросов для высокопроизводительного кода можно использовать встраиваемые функции. Для хранения констант есть const переменные. Чтобы для удобства «укоротить» длинное имя переменной используйте ссылки. Вместо применения макросов для условной компиляции кода используйте… лучше не используйте условную компиляцию (конечно же это не касается защиты от повторного включения заголовочных файлов через #define). Тем более условная компиляция затрудняет тестирование кода.

С другой стороны, есть приёмы кодирования, которые делаются только через макросы. Обычно это можно увидеть в низко-уровневых библиотеках. Также есть приёмы (преобразование в строку, объединение строк и т.д.), которые нельзя сделать средствами самого языка напрямую. В любом случае, перед использованием макросов попробуйте найти способ реализации без макросов. Если же необходимо использовать макросы для определения интерфейса то предварительно обязательно проконсультируйтесь с руководством.

Следующие правила позволят избежать ряда проблем с макросами. По возможности следуйте им:

• Не определяйте макросы в заголовочных (.h) файлах.
• Определяйте (#define) макросы по возможности ближе к месту первого использования. И когда макросы уже не используются, то делайте #undef.
• Не делайте #undef существующих макросов с последующим их переопределением своей версией. Вместо этого лучше придумайте для своих макросов уникальное имя и используйте его.
• Постарайтесь не использовать макросы, которые раскрываются в большие и неустойчивые конструкции C++. По крайней мере, документируйте такое поведение.
• Старайтесь не использовать ## для генерации имени функции/класса/переменной.

Настоятельно не рекомендуется экспортировать макросы из заголовочных файлов (т.е. определять макрос и не делать #undef его в конце заголовочного файла). Если макрос экспортируется из заголовочного файла, то он должен иметь глобальное уникальное имя. Как вариант, добавьте префикс с именем пространства имён проекта (заглавными буквами).

0 и nullptr/NULL

Используйте nullptr для указателей и ‘\0’ для char-ов (не используйте 0 для этих целей).

Для указателей (адресов) используйте nullptr, это улучшает безопасность типов.

Для проектов C++03 лучше используйте NULL, а не 0. Хотя оба варианта эквивалентны, NULL обычно ассоциируется с указателями. Также некоторые C++ компиляторы могут определять NULL специальным образом и выдавать более адекватные предупреждения компиляции. Никогда не используйте NULL как числовое значение (целочисленное или с плавающей запятой).

Используйте ‘\0’ в качестве символа конца строки (пустого символа). Это улучшает читабельность кода.

sizeof

Рекомендуется использовать sizeof(переменная) вместоsizeof(тип).

Используйте sizeof(переменная) если необходим размер определённой переменной. sizeof(переменная) будет возвращать корректное значение даже если в дальнейшем изменится тип переменной. sizeof(тип) можно использовать, когда код не работает с конкретной переменной, например в случае форматирования/разбора данных, где соответствующий тип C++ не подходит.

Вывод типов

Используйте вывод типов только если это сделает код более читабельным или более безопасным. Не используйте его только из-за неудобства написания полного типа.

Определение
Есть ряд ситуаций, когда типы в C++ коде могут (или даже необходимо) быть выведены компилятором и это более предпочтительно, чем явно их прописывать:

• вывод типов аргументов шаблонной функции
  • Шаблонная функция может вызываться без указания явных шаблонных типов. Компилятор выводит эти типы из аргументов функции:
  • Декларация переменной может использовать auto вместо типа. Компилятор выводит тип из выражения инициализации, следуя правилам, аналогичным для шаблонной функции (во всяком случае, пока не используются фигурные скобки вместо круглых).
    auto может использоваться совместно с const, или в составе указателя или ссылки. Однако, auto не может использоваться как аргумент шаблона. Изредка можно увидеть использование decltype(auto) вместо auto и в этом случае выводимый тип является результатом применения decltype
    к переданному выражению инициализации (прим.: и, например, сохранить квалификаторы ссылки).
  • auto (и decltype(auto)) можно использовать для указания возвращаемого значения функции. Компилятор выводит тип возвращаемого значения из выражения return в теле функции, следуя тем же правилам, что и при объявлении переменной: Возвращаемый тип лямбды может быть выведен аналогичным способом (хотя это делается при отсутствии возвращаемого типа, а не в случае использования auto). Синтаксис указания возвращаемого типа в конце для функций также использует auto, но это не вывод типа, скорее альтернативный синтаксис для явно указанного возвращаемого типа.
  • В описании лямбды можно использовать auto в качестве одного или нескольких типов параметров. Как результат, оператор вызова лямбды будет шаблонной функцией вместо обычной, с отдельными параметрами шаблона по одному на каждый auto:
  • В лямбде в секции захвата можно явно прописать новые переменные, инициализированные значением: Синтаксис не позволяет указать тип новой переменной, он выводится аналогично auto переменным.
  • См. соответствующий раздел.
  • При объявлении кортежей, структур или массивов с использованием auto можно указать имена отдельных элементов вместо имени полного объекта. Эти имена называются «структурная привязка», а декларация — соответственно «декларация структурной привязки». Синтаксис не позволяет задать тип ни полного объекта, ни отдельных имён:
    auto можно использовать с квалификаторами const, & и &&. Отметим, что эти квалификаторы формально применяются к анонимному кортежу/структуре/массиву, а не к отдельным привязкам. Правила определения конечного типа привязок довольно запутанные, однако в большинстве случаев всё довольно логично. Можно только отметить, что тип привязки обычно не может быть ссылочным, даже если в декларации указана ссылка (хотя поведение всё равно может быть как у ссылки).

  В приведённом выше описании не указаны многие детали, для дополнительной информации используйте приведённые ссылки.

  • Название типов в C++ может быть длинным и громоздким, особенно при использовании шаблонов и пространств имён.
  • Когда название типа C++ повторяется несколько раз внутри небольшого куска кода или декларации, это повторение не улучшает читабельность.
  • В ряде случаев вывод типов безопаснее, т.к. позволяет избежать случайных копирований или преобразований типов.

  Против
  При явном указании типов код C++ становится более ясным и понятным, особенно если вывод типов опирается на информацию из совершенно другой части кода. В выражении наподобие:

  может быть неочевидно какие типы выводятся для переменных, особенно если y не является хорошо известным типом или объявлен намного раньше по коду.

  Необходимо разбираться, выдаётся ли ссылка при выводе типа, производится ли копирование (особенно если оно не предполагалось).

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

  Вердикт
  Основное правило: используйте вывод типов только если это сделает код более ясным и безопасным. Не используйте вывод типов только чтобы облегчить написание кода. Не забывайте, что читатели кода могут быть в другой команде и не знакомы с этим проектом. Поэтому, хотя явные типы могут считаться понятным, очевидным и избыточными для одних, они могут содержать полезную информацию для других. Например, можно полагать, что возвращаемый тип make_unique<Foo>() очевиден. Однако, в случае MyWidgetFactory() лучше считать по-другому.

  Эти принципы применяются для всех видов вывода типов. Однако, существуют тонкости, описанные ниже.

  Вывод аргументов шаблонной функции

  Вывод аргументов шаблонной функции это практически всегда хорошо. Это стандартный и ожидаемый способ работы с шаблонными функциями, т.к. вызов такой функции напоминает работу с обычной (но перегруженной для различных аргументов) функцией. И шаблонные функции желательно проектировать так, чтобы вывод аргументов был корректный и безопасный, или функция не должна компилироваться.

  Вывод типов локальных переменных

  В случае локальных переменных можно использовать вывод типов, чтобы сделать код более простым, убрав очевидную или нежелательную информацию о типах, и читатель может сконцентрироваться на важных частях кода. Сравните примеры кода:

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

  Если тип является шаблонным, у которого параметры неинформативны, но тип самого шаблона является важным, то можно использовать вывод аргументов шаблонного класса чтобы избавиться от формального (ненужного) кода. Отметим что случаи, когда это является полезным, довольно редки. Также учтите, что при использовании вывода аргументов шаблонного класса желательно следовать специальным рекомендациям.

  Не используйте decltype(auto) при наличии более простых альтернатив, т.к. результат использования не всегда легко предсказуем.

  Вывод типа возвращаемого значения

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

  Вывод типов параметров

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

  Инициализация переменных захвата ламбды

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

  Структурные привязки

  В отличие от других форм вывода типов, структурные привязки могут дать дополнительную информацию за счёт правильного именования элементов полного объекта. Т.е. декларация структурной привязки может улучшить читабельность кода по сравнению с использованием явного типа (даже если auto не рекомендуется). Структурные привязки хорошо подходят при работе с парами или кортежами (см. пример использования insert выше), потому что в последних нет «говорящих» названий полей. С другой стороны, в целом не рекомендуется использовать пары и кортежи, пока внешний API, наподобие insert, явно этого не потребует.

  Если объектом привязки является структура, иногда может быть полезно указать имена, лучше подходящие для данного кода. Однако учитывайте, что такие имена могут быть менее понятны читателям кода, чем штатные имена полей. Рекомендуется использовать комментарии для указания имён полей, если они отличаются от имён привязок. Используйте синтаксис, аналогичный комментариям к параметрам функций:

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

  Вывод аргументов шаблонного класса

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

  Определение

  Вывод аргументов шаблонного класса (CTAD) проявляется, когда переменная декларируется с типом шаблона, но без указания аргументов (даже без угловых скобок):

  Компилятор выводит аргументы из выражения инициализации, используя «гайд» для шаблонов, который может быть явный и неявный.

  Явный гайд походит на декларацию функции с возвращаемым типом в конце, только без auto вначале, и имя функции есть имя шаблона. Например, ранее приведённый пример опирается на следующий гайд для std::array:

  Конструкторы в основном определении шаблона (т.е. не в специализации) также неявно определяют «гайд».

  Когда объявляется переменная, использующая CTAD, компилятор выбирает «гайд» на основе правил выбора (разрешения) перегруженного конструктора, и возвращаемый гайдом тип становится типом переменной.

  За
  CTAD иногда может уменьшить количество формального кода.

  Против
  Неявные «гайды», получаемые из конструкторов, могут реализовывать нежелательное или даже неправильное поведение. Эта проблема может часто проявляться для конструкторов, написанных до появления CTAD в C++17, т.к. авторы кода просто не знали о тех проблемах, которые вызовет CTAD. И далее, добавление явных «гайдов» для исправления проблемы может поломать любой существующий код, который использует неявные гайды.

  У CTAD есть много недостатков, аналогичных недостаткам auto, т.к. оба механизма выводят (полный или частичный) тип переменной на основе инициализации. CTAD выдаёт больше информации, чем auto, однако всё равно не содержит явного указания, если информация была пропущена.

  Вердикт
  Не используйте CTAD на шаблонных классах, пока не будет поддержки механизма и обеспечен хотя бы один явный «гайд» (предполагается, что в пространстве имён std всё поддерживается). Желательно, чтобы недопустимое использование CTAD приводило к предупреждениями компилятора.

  В любом случае, использование CTAD должно следовать общим правилам при выводе типов.

  Лямбды

  Используйте лямбды в подходящих случаях. Желательно использовать явный захват переменных, если лямбда будет выполнена вне текущей области видимости.

  Определение
  Лямбды это лаконичный и удобный способ создания объектов — анонимных функций. Особенно они полезны, когда нужно передавать функцию как аргумент. Например:

  Лямбды также позволяют захватывать переменный из текущей области видимости либо (явно) по имени, либо (неявно) через захват по-умолчанию. Явный захват предписывает перечислить все требуемые переменные: либо как значения, либо как ссылки:

  Захват по-умолчанию применяется ко всем переменным, используемым в теле лямбды, в том числе и к this (если используются члены класса):

  Захват переменной может быть также с инициализатором, что можно использовать для перемещения (move) переменных по значению или для других случаев, не подпадающих под обычный захват по значению или ссылке:

  Такой тип захвата (часто называемый init или generalized) нужен скорее не для собственно «захвата» переменных (или даже имён) из текущей области видимости. Этот синтаксис нужен для определения членов объекта лямбды:

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

  • Лямбды это очень удобный и лаконичный способ определения объектов-функций (например, для передачи в алгоритмы STL), что может улучшить читабельность.
  • Правильное использование захвата по-умолчанию может устранить избыточность и выявить важные исключения при захвате.
  • Лямбды, std::function и std::bind можно использовать совместно как механизм обратного вызова общего назначения. Упрощается написание кода, принимающего/использующего функции как аргументы.
  • Захват переменных может быть источником ошибок с недействительными указателями, особенно если лямбда выходит за текущую область видимости.
  • Захват по умолчанию может вводить в заблуждение, т.к. он не защищает от ошибок недействительных указателей. Захват указателя на объект по значению не приводит к созданию копии самого объекта. При этом часто возникают те же особенности жизненного цикла, что и при захвате по ссылке. Учтите, что ‘this’ также захватывается по значению и это может привести к проблемам, т.к. он часто используется неявно.
  • Захват фактически объявляет новые переменные (вне зависимости от наличия инициализатора), хотя это отличается от обычного синтаксиса C++. В частности, нет указания типа переменной, даже в виде auto (хотя захват с инициализацией может сделать это неявно через приведение типов), и это отличается от типовой декларации.
  • Захват с инициализацией использует вывод типов, и подвержен тем же проблемам, что и auto, плюс сам синтаксис не содержит указания, что происходит вывод типов.
  • В ряде случаев использование лямбд может сильно затруднить понимание кода (очень длинные функции) или потребовать дополнительного контроля.
  • Используйте лямбды в подходящих случаях. Применяйте форматирование, описанное ниже.
  • Рекомендуется явно указывать захват переменных, если лямбда может выйти за текущую область видимости. Например, вместо:лучше написать:
  • Используйте захват по-умолчанию по ссылке ([&]), только если жизненный цикл лямбды явно короче чем у любой переменной.
  • Используйте захват по-умолчанию по значению ([=]), только как средство привязки нескольких переменных для короткой лямбды. Не рекомендуется писать лямбды с объёмным и сложным кодом вместе с захватом по-умолчанию по значению.
  • Используйте захват только существующих переменных из текущей области видимости. Не используйте захват с инициализаторами, чтобы ввести новые имена или подменить существующие. Вместо этого можно объявить обычную новую переменную и передать её в лямбду, или вместо лямбды определить отдельную полноценную функцию.
  • Вопросы по указанию параметров и возвращаемому типу рассмотрены в разделе Вывод типов.

  Метапрограммирование на шаблонах

  Не используйте сложные/запутанные шаблоны в коде.

  Определение
  Метапрограммирование на шаблонах это семейство техник, использующих возможности по инстанцированию шаблона в C++, которое Тьюринг-полное, для выполнения вычислений на этапе компиляции.

  За
  Метапрограммирование позволяет создавать очень гибкие интерфейсы, у которых высокая производительность и отличная типобезопасность. Например, Google Test, std::tuple, std::function и Boost.Spirit были бы невозможны без таких средств.

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

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

  Метапрограммирование усложняет проведение рефакторинга, затрудняя работу инструментов. Во-первых, код шаблона раскрывается в различных контекстах и трудно проверить, что в каждом из них код остаётся корректным. Во-вторых, ряд инструментов работает уже с AST (прим.: абстрактное синтаксическое дерево), которое описывает структуру кода только после раскрытия шаблонов. И в этом случае может быть тяжело обнаруженные проблемы отобразить на исходные конструкции в коде и определить, что требуется переписать.

  Вердикт
  Метапрограммирование в ряде случаев позволяет создать понятные и простые в использовании интерфейсы (которые были бы сложнее в ином случае), однако есть соблазн всё сделать чересчур заумным. Поэтому его лучше использовать в небольшом количестве низкоуровневых компонентов, чтобы сложность поддержки компенсировалась полезностью и широтой применения.

  Дважды подумайте перед тем, как использовать метапрограммирование или другие сложные техники на шаблонах: может ли средний программист в команде понять и поддерживать такой код (особенно после переключения с другого проекта); сможет ли не-C++ программист (или другой случайный читатель) понять сообщения об ошибках или отладить выполнение функции, которую он вызывает. Если используются рекурсивное инстанцирование шаблонов, список типов, метафункции, шаблоны выражений или используется SFINAE или трюк с sizeof для разрешения перегрузки функции — скорее всего вы зашли слишком далеко.

  Если используется метапрограммирование, то готовьтесь приложить усилия для минимизации сложности, а также её изоляции. По возможности скрывайте код с метапрограммированием внутри реализации, чтобы сделать пользовательские заголовочные файлы более читабельными. Код с метапрограммированием должен быть очень хорошо откомментирован: следует подробно задокументировать, как использовать код и на что будет похож «сгенерированный» результат. Обратите особое внимание на сообщения об ошибках, которые выдаёт компилятор, когда делается что-то ошибочное. Учтите, что сообщения об ошибках являются частью вашего пользовательского интерфейса и код следует доработать так, чтобы сообщения об ошибках были понятными для пользователя и объясняли, что нужно делать для их исправления.

  Boost

  Используйте только одобренные библиотеки из коллекции Boost.

  Определение

  Boost это популярная коллекция проверенных, бесплатных и открытых библиотек C++.

  За
  В целом код Boost является высококачественным, портируемым и во многом дополняется стандартную библиотеку C++, например, в таких областях как свойства типов или улучшенные связыватели (binder).

  Против
  Некоторые библиотеки Boost поощряют создание кода, который ухудшает читабельность: используется метапрограммирование или другие продвинутые техники на шаблонах, а также чрезмерно «функциональный» стиль.

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

  • Call Traits из boost/call_traits.hpp
  • Compressed Pair из boost/compressed_pair.hpp
  • Boost Graph Library (BGL) из boost/graph, за исключением сериализации (adj_list_serialize.hpp) и параллельных/распределённых алгоритмов и структур данных (boost/graph/parallel/* и boost/graph/distributed/*).
  • Property Map из boost/property_map, за исключением параллельных/распределённых (boost/property_map/parallel/*).
  • Iterator из boost/iterator
  • Часть Polygon, которая работает с построением диаграмм Вороного и не зависит от остальной части Polygon: boost/polygon/voronoi_builder.hpp, boost/polygon/voronoi_diagram.hpp, and boost/polygon/voronoi_geometry_type.hpp
  • Bimap из boost/bimap
  • Statistical Distributions and Functions из boost/math/distributions
  • Special Functions из boost/math/special_functions
  • Root Finding Functions из boost/math/tools
  • Multi-index из boost/multi_index
  • Heap из boost/heap
  • flat-контейнеры библиотеки Container: boost/container/flat_map и boost/container/flat_set
  • Intrusive из boost/intrusive
  • Библиотека boost/sort
  • Preprocessor из boost/preprocessor

  В настоящее время прорабатывается вопрос о добавлении других библиотек Boost в этот список, так что он может в будущем дополняться.

  std::hash

  Не определяйте специализации 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.

  Даже для экспертов создание хорошей специализации std::hash может представлять сложность, особенно для составных типов, т.к. хорошая реализация не может просто рекурсивно вызывать std::hash на всех членах данных. Высококачественные хэш-алгоритмы содержат большое количество внутренних состояний, и упаковка их в размер size_t (что функция std::hash и возвращает) обычно является самой медленной частью в вычислениях, так что это должно выполняться не более одного раза.

  Именно из-за этого std::hash не работает с std::pair и std::tuple, и в язык не добавлена их поддержка.

  Вердикт
  Можно использовать std::hash с типами, которые поддерживаются «из коробки», но не добавляйте специализации для своих типов. Если требуется хэш-таблица с ключом, который не поддерживается std::hash, то возможно следует воспользоваться другими (ранними) хэш-контейнерами (например, hash_map); в них используется другой хэш-алгоритм, на который этот запрет не влияет.

  Если всё равно требуется стандартный контейнер, то задаёте собственную хэш-функцию для ключа, например:

  Прежде всего узнайте у автора типа данных о наличии готовой хэш-функции (а вдруг?). В противном случае создавайте свою, в сотрудничестве с автором, или без него.

  Возможно, скоро появится хэш-функция, которая сможет работать с любым типом и использовать новый механизм подстройки, при этом у неё не будет недостатков std::hash.

  Остальные возможности C++
  

  Некоторые расширения современного C++, также как и Boost, содержат код с плохой читабельностью, с удалённой добавочной информацией о типах, с использованием метапрограммирования. Другие же расширения дублируют существующий функционал, что может привести к путанице и дополнительной конвертации кода.

  Вердикт
  Настоятельно не рекомендуется использовать следующие возможности C++:

  • Рациональные числа (относящиеся к времени компиляции) (<ratio>), т.к. за интерфейсом может стоять сложный шаблон.
  • Заголовочные файлы <cfenv> и <fenv.h>, т.к. многие компиляторы не поддерживают корректную работу этого функционала.
  • Заголовочный файл <filesystem>, который недостаточно протестирован, и подвержен уязвимостям в безопасности.

  Нестандартные расширения

  Нестандартные расширения C++ не рекомендуется использовать, пока явно не указано обратное.

  Определение
  Компиляторы поддерживают различные расширения, не являющиеся частью стандартного C++. Например, __attribute__, внутренние (intrinsic) функции (__builtin_prefetch), назначенные инициализаторы (Foo f = ), ассемблерные вставки, __COUNTER__, __PRETTY_FUNCTION__, составные выражения (foo = (< int x; Bar(&x); x >), массивы переменной длины, alloca() и «оператор Элвис» a?:b.

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

  Вердикт
  Не используйте нестандартные расширения. Можно использовать портируемые обёртки кода, которые реализованы с использованием нестандартных расширений и и (желательно) содержатся в одном заголовочном файле (portability header).

  Псевдонимы/Alias

  Публичные псевдонимы предназначены для использования с API и должны быть хорошо документированы.

  Определение
  Есть несколько способов для создания имён, являющихся псевдонимами для других сущностей:

  При написании нового кода рекомендуется использовать using, а не typedef. Это обеспечивает более согласованный синтаксис с остальным C++ кодом и поддерживает работу с шаблонами.

  Аналогично другим декларациям, псевдонимы, введённые в заголовочном файле, обычно являются частью публичного API этого файла. Исключения касаются случаев, когда псевдонимы объявлены внутри определения функции, private секции класса или явно отмеченном внутреннем пространстве имён. Такие псевдонимы, а также введённые в .cc файлах являются «деталями реализации» (т.к. клиентский код к ним не обращается) и не подпадают под действие этих правил.

  • Псевдонимы могут улучшить читабельность кода, сокращая длинные и сложные имена.
  • Псевдонимы могут уменьшить дублирование: например, сделав именование типа, часто использующегося в API, в дальнейшем это может облегчить изменение этого типа на другой.
  • Псевдонимы, размещённые в заголовочном файле (где клиентский код может обращаться к ним), увеличивают количество сущностей в этом файле API и его сложность.
  • Клиентский код может полагаться на особенности публичных псевдонимов, и это усложняет внесение изменений.
  • Есть соблазн создавать публичные псевдонимы, которые будут использоваться только во внутренней реализации. Такой подход может влиять на сам API и усложнит его поддержку.
  • Псевдонимы увеличивают риск создания дубликата для другого имени.
  • Псевдонимы могут ухудшить читабельность кода, если хорошо известным сущностям будут давать незнакомые имена.
  • Псевдонимы типов могут создать «ненадёжное» соглашение по API: то ли псевдоним всегда будет идентичным указанному типу (API не изменится, тип можно использовать любым способом); то ли тип у псевдонима может поменяться (тогда рекомендуется использовать только небольшую часть возможностей).

  Вердикт
  Не вводите псевдонимы в публичный API только для облегчения написания кода в реализации; псевдоним должен прежде всего быть полезен для клиентского кода.

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

  Не объявляйте публичные псевдонимы на пространства имён в своём API. (См. также Пространство имён).

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

  Приведённые ниже псевдонимы не документируют способы использования и часть из нихвообще не предназначения для использования в клиентском коде:

  Однако, локальные псевдонимы очень удобны внутри определения функций, private секций классов, внутренних пространств имён и в .cc файлах:

  Использование RTTI в приложениях на базе VCL

  В статье рассматриваются механизм работы и использование механизма динамической идентификации типов (RTTI — runtime type identification) в приложениях, использующих объектную библиотеку ф. Borland VCL — Visual Component Library.

  Почему не стоит читать эту статью?

  RTTI используется ,как правило, во всех приложениях, созданных компилятором C++. Если компилятору указано не включать в объектный файл RTTI информацию, то не возможна будет динамическая идентификация типов и динамическое приведение типов. Обычно в состав RTTI входит следующая информация: имя типа (для идентификации), указатель на базовый тип (для приведения типов), указатель на конструктор копий. В RTTI поддерживающую VCL входит дополнительная информация, используемая IDE Builder C++, в первую очередь инспектором объектов. Однако структура и содержание этих дополнительных данных не документирована и вероятно может меняться в зависимости от версии Builder. Поэтому использование расширенной RTTI в приложениях возможно только при соблюдении ограничения: исходный код не может переноситься на другие версии Builder C++. Тем не менее, думаю приведенная информация будет интересна программистам в Builder C++, особенно при написании компонент. Все данные, приведенные в этой статье получены для Builder C++ 3.0.

  Что можно узнать из RTTI?

  Поле	Размер	Описание
  TypeID	1 байт	Идентификатор типа,см табл.2
  NameLen	1 байт	Длина строки с именем типа
  Different	—	Различается для разных TypeID

  Значение TypeID	Описание
  0x01	Целые типы short, int
  0x02	Символный тип char
  0x03	Перечислимые типы
  0x04	Вещественные типы float, double, long double
  0x05, 0x06	Не выяснено, скорее всего структуры и объединения
  0x07	классы
  0x08	указатели на обработчики событий
  0х10	строковые классы

  Для классовпотомков TObject получить указатель на RTTI информацию можно посредством метода ClassInfo():

  Указатель rtti будет указывать на область памяти, с данными с информацией о типе объекта p_class.

  Несколько слов о том, как самостоятельно исследовать информацию о типе. Для этого нужен какой-нибудь отладчик. В данном случае достаточно удобно пользоваться встроенным отладчиком (View|CPU). Получив значение указателя на RTTI класса, его содержимое просматривается в дампе памяти отладчика и имея описание класса (т.е. фактически зная информацию о его типе) можно делать логические заключения о структуре RTTI.

  Работа со свойствами

  1. Доступ к значению свойства может быть напрямую или посредством функции:

  к значению свойства напрямую

  посредством функции метода GetParamB. В первом случае в RTTI будет приведено значение смещения переменной param_a в экземпляре класса, во втором — адрес функции, возвращающей значение свойства

  2. Свойства бывают индексируемыми

  К индексированному свойству доступ возможен только через функцию, которая принимает параметр index. Самое интересное — из RTTI нельзя узнать, индексируется свойство или нет.

  3. Если несколько свойств обслуживаются одним методом, в описании свойства указывается целый индекс, передаваемый в метод:

  Значение этого индекса можно узнать из RTTI.

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

  предикат StoredC. Значение параметра stored можно узнать из RTTI.

  5.Свойство может иметь значение по умолчанию (см. п 4)

  Отметим, что значение default не устанавливает начальное значение свойства — это работа конструктора.

  Значение параметра default можно посмотреть в RTTI. Кстати, хотя везде написано, что параметру default должно присваиваться константное выражение, на самом деле можно присвоить только целое константное выражение из-за того, что как мы увидим далее для значения default отводится только 4 байта, а вещественные константы могут занимать 4,8 и 10 байт.

  Получение информации о классе объекта

  Как уже говорилось выше, информация об классе находится по адресу, возвращаемому методом ClassInfo. По этому адресу находится следующая информация:

  1. Идентификатор типа, равный для классов 7 (1 байт)
  2. Длина имени класса (1 байт)
  3. Строка с именем класса
  4. Указатель на метод (предположительно конструктор копий) (4 байта)
  5. Указатель на указатель на базовый тип (вот так вот сложно!) (4 байта)
  6. Количество опубликованных свойств, в том числе и в базовых классах (2 байта)
  7. Длина имени модуля, где объявлен класс (1 байт)
  8. Имя модуля, где объявлен класс
  9. Число свойств, опубликованных в самом классе (2 байта)
  10. Список свойств, опубликованных в классе (каждое 26 байт + имя свойства)

  Заголовок класса: 07 — идентификатор описания класса, имя класса, указатель на конструктор копий, указатель на базовый класс, количество опубликованных свойств, имя модуля, количество опубликованных в класск свойств. Перечисления свойств: Смещение переменной — прямой доступ для чтения, адрес метода установки значения, stored = true, index = -1 (нет индекса), default = 0, порядковый номер свойства, имя свойства (Align)

  Формат RTTI для опубликованных свойств

  Из выше приведенного дампа памяти можно уяснить себе, в каком формате храниться описание опубликованного свойства. Тем не менее приведем этот формат в явном виде:

  1. Указатель на указатель с информацией о типе свойства
  2. Доступ к значению свойства (чтение): адрес метода или смещение в объекта. Если указано смещение от начала класса, то в самом старшем байте записано 0xFF — чтобы отличить от метода.
  3. Доступ к значению свойства (запись): адрес метода или смещение в объекте
  4. Значение параметра stored: 0, 1, или адрес предиката.
  5. Значение параметра index: 4 байтное целое
  6. Значение параметра default: 4 байтное целое
  7. Порядковый номер свойства: 2 байтное целое, из чего ясно, что больше чем 65535 свойств не опубликовать, ди наверное и не надо.
  8. Имя свойства.

  Для того чтобы прочитать значение свойства следует выполнить следующие действия:

  1. Получить RTTI для класса, содержащего желаемое свойство
  2. Получить указатель на описание желаемого свойства
  3. Выяснить его тип
  4. Если чтение осуществляется напрямую, вычислить адрес переменной — указатель на объект + смещение
  5. Если чтение выполняется через метод, следует привести указатель к указателю на метод и вызвать его

  Установка значения свойства выполняется аналогично.

  Как видно из выше сказанного, установка и чтение свойства невозможны без знания типа свойства. Рассмотрим кратко возможные форматы описания типов:

  Формат целых типов:

  1. Идентификатор типа 0х01 (1 байт)
  2. Имя типа
  3. Варианты (1 байт) 2 — short, 3 — unsigned short, 4 — int, long

  Формат символьного типа

  1. Идентификатор типа 0х02 (1 байт)
  2. Имя типа
  3. Варианты (1 байт) 0 — char, 1- unsigned char

  Формат перечислений

  1. Идентификатор типа 0х03 (1 байт)
  2. Имя типа
  3. 9 байт
  4. Указатель либо на начало собственного описания, либо на указатель на описания типа, где фактически и описано содержимое перечисления (такая ситуация характерна для многих типов, пришедших из Pascalи видимо связана с особенностями компилятора этого языка) (4 байта)
  5. Если указатель (4) содержит адрес начала собственного описания, то вслед за ним идет список символьных констант, входящих в перечисление).
  6. Формат данных в перечислении 1,2 или 4 байта (1 байт)

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

  то в RTTI такой тип трактуется как целый и вся символьная информация не включается в RTTI.

  Формат вещественного типа

  1. Идентификатор типа 0х04 (1 байт)
  2. Имя типа
  3. Варианты (1 байт) 0 — float, 1 — double, 2 — long double

  К вещественным типам относятся также типы для представления времени TDateTime (он объявлен тождественным типу double).

  Формат классов

  Формат описания классов рассмотрен выше

  Формат обработчиков событий

  1. Идентификатор типа 0х08 (1 байт)
  2. Имя типа
  3. Количество параметров у метода-обработчика (1 байт)
  4. Описание параметров в формате: Имя параметра, Имя типа параметра (порядок, свойственный для Pascal).

  Формат строковых типов

  1. Идентификатор 0х10 (1 байт)
  2. Имя типа

  В Pascal для хранения строк существует специальный класс — String. В «чистом» С нет специальных типов для представления строковых данных, с ними работают как с массивами байтовых (или двухбайтовых) целых чисел. Для поддержки строк в формате String в Builder C++ объявлен специальный класс AnsiString.

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

  Работу со свойствами рассмотри на примере доступа к свойству целого типа:

  Следует обратить внимание на две вещи: 1) соглашение о вызове функции должно совпадать с описанным в классе для доступа к значению функции; 2) поскольку метод- член класса неявно первым параметром получает указатель на экземпляр класса его вызвавший, следует описать этот параметр

  Похожие публикации:

  1. Mem trojan win32 sepeh gen что это
  2. Mini tools partition wizard как добавить место на диск с
  3. Как закрепить приложение на панели задач windows 10
  4. Как настроить размеры в автокаде 2022