Что вызывает включение TU в компиляцию?

Question

Я немного не в себе, честно говоря.

Я провожу довольно любопытные эксперименты, заставляя pre-main функции регистрировать мои классы на фабрике через анонимные пространства имен.До недавнего времени добавление следующего к определению класса (.cpp) могло бы помочь.

namespace { int x = Register<classType>(className); }

Это будет обернуто в макрос, а 'Register' передаст тип и имя моей фабрике.

Это работало нормально, и каждый класс, который включал этот макрос, регистрировался, пока я не переместил код в статическую библиотеку.Теперь, так как на классы ссылаются только фабрики, похоже, что они исключаются из сборки - мои функции 'Register' больше не вызываются, и поэтому моя фабрика пуста.

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

Однако я действительно не хочу делать это таким образом, и я не могу найти необязательный способ ссылки на классы вконструктор (например, class ClassToRegister;), который включает их в сборку, так что мои макросы регистров будут вызываться.

Во-первых, имеет ли это смысл?

Во-вторых, любые советы о том, как яможет заставить эти TU скомпилировать так, чтобы анонимные пространства имен «включались» во время выполнения?

Answer 1

Похоже, это неотъемлемая часть использования статических библиотек; неиспользуемый код не сможет пройти без компоновщика voodoo.

Answer 2

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

Answer 3

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

Вы можете попытаться обойти это так:

namespace foo
{
namespace{
MACRO_TO_DEFINE_VARIABLE( MyClass ); // define a variable named registrationObj
};

MyClass::MyClass()
{
  (void)registrationObj;
}
}