Хорошим методом обеспечения освобождения памяти соответствующей функцией является использование shared_ptr
(см. [C++TR104]). Интеллектуальный указатель shared_ptr
со счетчиком ссылок может захватить свой "удалитель" в процессе конструирования. "Удалитель" — это функциональный объект (или обычный указатель на функцию), который выполняет освобождение памяти. Поскольку упомянутый функциональный объект, или указатель на функцию, является частью состояния объекта shared_ptr
, модуль, выделивший память объекту, может одновременно определить функцию освобождения памяти, и эта функция будет корректно вызвана, даже если точка освобождения находится где-то в другом модуле — вероятно, относительно небольшой ценой (корректность важнее цены; см. также рекомендации 5, 6 и 8). Конечно, исходный модуль при этом должен оставаться загруженным.
Ссылки
[С++TR104]
61. Не определяйте в заголовочном файле объекты со связыванием
Резюме
Объекты со связыванием, включая переменные или функции уровня пространства имен, обладают выделенной для них памятью. Определение таких объектов в заголовочных файлах приводит либо к ошибкам времени компоновки, либо к бесполезному расходу памяти. Помещайте все объекты со связыванием в файлы реализации.
Обсуждение
Когда мы начинаем использовать С++, то все достаточно быстро уясняем, что заголовочный файл наподобие
// Избегайте определения объектов с внешним
// связыванием в заголовочном файле
int fudgeFactor;
string hello("hello, world!");
void foo() { /* ... */ }
будучи включен больше чем в один исходный файл, ведет при компиляции к ошибкам дублирования символов во время компоновки. Причина проста: каждый исходный файл в действительности определяет и выделяет пространство для fudgeFactor
, hello
и тела foo
, и когда приходит время сборки (компоновки, или связывания), компоновщик сталкивается с наличием нескольких объектов, которые носят одно и то же имя и борются между собой за видимость. Решение проблемы простое — в заголовочный файл надо поместить только объявления:
extern int fudgeFactor;
extern string hello;
void foo(); // В случае объявления функции "extern"
// является необязательным
Реальные же объявления располагаются в одном файле реализации:
int fudgeFactor;
string hello("hello, world!");
void foo() { /* ... */ }
He определяйте в заголовочном файле и статические объекты уровня пространства имен, например:
// избегайте определения объектов со статическим
// связыванием в заголовочном файле
static int fudgeFactor;
static string hello("Hello, world!");
static void foo() { /* ... */ }
Такое некорректное использование ключевого слова static
более опасно, чем простое определение глобальных объектов в заголовочном файле. В случае глобальных объектов, по крайней мере, компоновщик в состоянии обнаружить наличие дублей. Но статические данные и функции могут дублироваться на законных основаниях, поскольку компилятор делает закрытую копию для каждого исходного файла. Так что если вы определите статические данные и статические функции в заголовочном файле и включите его в 50 файлов, то тела функций и пространство для данных в выходном исполняемом файле будут дублированы 50 раз (только если у вас не будет использован очень интеллектуальный компоновщик, который сможет распознать 50 одинаковых тел функций и наличие одинаковых константных данных, которые можно безопасно объединить). Излишне говорить, что глобальные данные (такие как статические fudgeFactor
) на самом деле не являются глобальными объектами, поскольку каждый исходный файл работает со своей копией таких данных, независимой от всех остальных копий в программе.
Не пытайтесь обойти эту ситуацию при помощи использования безымянных пространств имен в заголовочных файлах, поскольку результат будет ничуть не лучше:
// В заголовочном файле это приводит к тому же
// эффекту, что и использование static
namespace {
int fudgeFactor;
string hello("Hello, world!");
void foo() { /* ... */ }
}
Исключения
В заголовочных файлах могут находиться следующие объекты с внешним связыванием.
• Встраиваемые функции. Они имеют внешнее связывание, но компоновщик гарантированно не отвергает многократные копии. Во всем остальном они ведут себя так же, как и обычные функции. В частности, адрес встраиваемой функции гарантированно будет единственным в пределах программы.
Читать дальше