Вбудована функція члена C ++ у файлі .cpp

Я знаю, що вбудовані функції члена за визначенням повинні йти в заголовок. Але що, якщо неможливо помістити реалізацію функції в заголовок? Візьмемо таку ситуацію:

Файл Ах

#pragma once
#include "B.h"

class A{
    B b;
};

Файл Bh

#pragma once

class A; //forward declaration

class B{
    inline A getA();
};

Завдяки циркулярному включенню я повинен поставити реалізацію getAв

B.cpp

#include "B.h"
#include "A.h"

inline A B::getA(){
    return A();
}

Чи буде компілятор вбудованим getA? Якщо так, яке вбудоване ключове слово є значущим (ключовим у заголовку чи ключовим файлом .cpp)? Чи існує інший спосіб внести визначення вбудованої функції-члена у файл .cpp?

Посилання на поширені запитання на C ++ :

Примітка: Обов’язково потрібно, щоб визначення функції (частина між {...}) було розміщено у файлі заголовка, якщо функція не використовується лише в одному файлі .cpp. Зокрема, якщо ви вкладете визначення вбудованої функції у файл .cpp і викликаєте його з іншого файлу .cpp, ви отримаєте помилку "невирішена зовнішня" від компонувальника.

Компілятор повинен бачити визначення вбудованої функції, коли він знаходить якесь використання цієї вбудованої функції. Як правило, це можливо, якщо вбудована функція розміщується у файлі заголовка.

Чи вбудований компілятор отримає A?

Ні, за винятком випадків, коли використання використовується getA()в самому B.cpp.

Якщо так, яке вбудоване ключове слово є значущим (ключовим у заголовку чи ключовим словом cpp)?

Краща практика : лише у визначенні поза тілом класу.

Чи є інший спосіб помістити визначення вбудованої функції-члена у файл cpp?

Ні, принаймні я не знаю.

Це не може, поза сферою дії B.cpp. Компілятор працює на основі одиниці компіляції, тобто він компілює кожен файл .cpp окремо, тому, якщо він компілює C.cpp, у нього не буде коду getA (), і йому потрібно буде виконати виклик функції та попросіть компонувальник виправити це (або, якщо він насправді взяв вас за слово і спробував вбудувати, він в кінцевому підсумку отримає помилку лінкера. inlineмає подібні якості, як static).

Єдиним винятком є ​​LTCG, тобто генерація коду часу зв'язку, яка доступна на новіших компіляторах.

Одним із підходів у цьому випадку є наявність іншого заголовного файлу (іноді з назвою * .inl-файли), що містить вбудований код.

РЕДАГУВАТИ: Що стосується того, який рядок є важливим - це той, що є у визначенні класу, тобто у файлі заголовка. Майте на увазі, що багато компілятори мають власну думку щодо того, що можна і що слід вкладати. gcc, наприклад, може повністю відключити вставку (-O0), або може вбудувати все, що вважає вартим вкладання (наприклад, -O3).

Я б пішов про це з протилежного напрямку.

Не додавайте вбудовані декларації до вашої функції (якщо вам це теж не потрібно).

Єдиний раз, коли вам потрібно додати вбудовану декларацію до функції / методу, це якщо ви визначаєте функцію у файлі заголовка, але поза оголошенням класу.

Xh

class X
{
    public:
        int getX()   { return 4;} // No inline because it is part of the class.
                                  // The compiler knows that needs an inline tag
        int getY();
        int getZ();
};

inline
int X::getY()  { return 5;}       // This needs to be explicitly declared inline.
                                  // Otherwise the linker will complain about
                                  // multiple definitions in compilation units.

X.cpp

 // Never declare anything inline in the cpp file.

 int X::getZ() { return 6; }

Для вас більш конкретний випадок.
Видаліть усі вбудовані технічні характеристики. Вони роблять не те, що, на вашу думку, вони роблять.

У наші дні більшість компіляторів можуть виконувати вбудовування під час зв’язування, а також під час компіляції. Якщо ваша функція, швидше за все, виграє від вбудовування, тоді оптимізатор часу зв’язку, ймовірно, зробить саме це.

До того часу, як компонувальник дійде до нього, доступне не так багато про вбудований стан виводу компілятора, за винятком того, що компілятор буде позначати певні об'єкти колекційними, наприклад, тому що вбудована функція або екземпляр шаблону класу з'являється в декількох одиницях компіляції, це повинно викликати помилку, коли декілька символів мають спільне ім'я, наприклад, головна функція визначається двічі. Ніщо з цього не впливає на фактичний код, який він створить.

Ось як я це зробив.

Файл Ах

#pragma once
#include "B.h"

class A {
    B b;
};

Файл Bh

#pragma once

class B {
public:
    template<class T> inline T getA() {
        assert(NULL); // Use 'getA<A>()' template specialization only!
        return NULL;
    }
};

class A; // Forward declaration
template<> inline A B::getA<A>();

Файл Ch

#pragma once
#include "A.h"
#include "B.h"

// Implement template specialization here!
template<> inline A B::getA<A>() { return A(); }

Просто включіть файл "Ch", щоб мати можливість використовувати метод getA (). Єдиною зміною оригінального коду є те, що метод getA () повинен визначатися як загальнодоступний, а не як приватний.

Однак, як багато хто з вас пояснювали це, це насправді не корисно.