7.3 Неявная ссылка

В C++ существует несколько конструкций, требующих места в объектных файлах, но не имеющих чёткой связи с единой единицей трансляции. Мы говорим, что эти конструкции имеют «неявную ссылку». Обычно такие конструкции генерируются там, где они необходимы, хотя иногда мы можем действовать более разумно.

Встроенные функции

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

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

VTable

Виртуальные функции C++ в большинстве компиляторов реализуются с помощью таблицы поиска, известной как vtable. Vtable содержит указатели на виртуальные функции, предоставляемые классом, и каждый объект класса содержит указатель на свой vtable (или vtables в некоторых ситуациях множественного наследования). Если класс объявляет любые не встроенные, не чистые виртуальные функции, первая из них выбирается в качестве «ключевого метода» для класса, и vtable генерируется только в единице трансляции, где определен ключевой метод.

Примечание: Если выбранный ключевой метод позже определен как встроенный, vtable все равно генерируется в каждой единице трансляции, которая его определяет. Убедитесь, что все встроенные виртуальные функции объявлены встроенными в теле класса, даже если они не определены там.

type_info объекты

C++ требует, чтобы информация о типах была записана для реализации ‘dynamic_cast’, ‘typeid’ и обработки исключений. Для полиморфных классов (классов с виртуальными функциями) объект ‘type_info’ записывается вместе с vtable, чтобы ‘dynamic_cast’ мог определить динамический тип объекта класса во время выполнения. Для всех остальных типов мы записываем объект ‘type_info’, когда он используется: при применении ‘typeid’ к выражению, броске объекта или ссылке на тип в блоке catch или спецификации исключения.

Шаблонные инстанциации

Почти всё в этом разделе также относится к шаблонам инстанциаций, но есть и другие варианты. См. Где Шаблон?.

При использовании с GNU ld версии 2.8 или новее на ELF-системе, такой как GNU/Linux или Solaris 2, или на Microsoft Windows, дублированные копии этих конструкций будут удалены во время компоновки. Это известно как поддержка COMDAT.

На целевых платформах, которые не поддерживают COMDAT, но поддерживают слабые символы, GCC использует их. Таким образом, одна копия переопределяет все остальные, но неиспользуемые копии всё ещё занимают место в исполняемом файле.

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

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