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

Я нахожу много ресурсов в Интернете о том, как inline (и даже __attribute__((always_inline)) или же __forceinline) не заставляет компилятор (например, gcc или VisualC ++) встроить функцию. Но когда именно он не будет введен в действие? Есть ли игрушечный пример?

Возможно, не обязательно тот же вопрос, когда будет функция с тегом inline включены в два разных файла cpp создают проблемы во время связывания? А именно, генерировать дубликаты символов?

Вот конкретная песочница для того, чтобы попытаться сломать встраивание компилятора и сгенерировать дублированный символ:

В myinline.h:

inline int myinline()
{
// code that cannot be inlined...
...
}

В aux.cpp:

#include "myinline.h"int aux()
{
return my_inline();
}

В main.cpp:

#include "myinline.h"int aux();
int main()
{
return aux() + my_inline();
}

Тогда, например, в случае gcc есть некоторый (минимальный) код для myinline это приведет к дублированию символа при компиляции и связывании с:

g++ -o aux.o -c aux.cpp
g++ -o main.o -c main.cpp
g++ -o example aux.o main.o

?

1

Решение

«Вставка» и «дубликаты символов» — разные вещи. inline Ключевое слово явно допускает несколько определений (то есть освобождает вас от правила одного определения), поэтому платформа (компилятор и компоновщик) должна знать, как обрабатывать и дедуплицировать это.

(Это происходит постоянно для функций-членов класса, которые определены в заголовках.)

Если вы просто хотите генерация кода для этого вы можете хранить адрес функции где-нибудь:

auto fp = my_inline;

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

1

Другие решения

Других решений пока нет …

По вопросам рекламы [email protected]