Czy ma sens używanie wbudowanych słów kluczowych w szablonach?

Ponieważ szablony są zdefiniowane w nagłówkach, a kompilator jest w stanie określić, czy wstawianie funkcji jest korzystne, czy ma to jakiś sens? Słyszałem, że współczesne kompilatory wiedzą lepiej, kiedy wstawić funkcję i ignorują inlinewskazówkę.

edycja: chciałbym zaakceptować obie odpowiedzi, ale nie jest to możliwe. Aby zamknąć sprawę, przyjmuję odpowiedź phresnela , ponieważ otrzymał on najwięcej głosów i formalnie ma on rację, ale jak wspomniałem w komentarzach, uważam, że odpowiedzi Szczenięcia i Komponentu 10 również są poprawne, z innego punktu widzenia .

Problem tkwi w semantyce C ++, która nie jest ścisła w przypadku inlinesłów kluczowych i inliningu. phresnel mówi „pisz w tekście , jeśli masz to na myśli”, ale to, co właściwie oznacza, inlinenie jest jasne, ponieważ ewoluowało od pierwotnego znaczenia do dyrektywy, która „powstrzymuje kompilatory narzekanie na naruszenia ODR”, jak mówi Puppy .

Nie jest to bez znaczenia. I nie, nie każdy szablon funkcji jest inlinedomyślny. Norma jest nawet wyraźnie o tym mowa w specjalizacji jawnej ([temp.expl.spec])

Mają następujące cechy:

a.cc

#include "tpl.h"

b.cc

#include "tpl.h"

tpl.h (zaczerpnięte z Explicit Specialization):

#ifndef TPL_H
#define TPL_H
template<class T> void f(T) {}
template<class T> inline T g(T) {}

template<> inline void f<>(int) {} // OK: inline
template<> int g<>(int) {} // error: not inline
#endif

Skompiluj to i voila:

g++ a.cc b.cc
/tmp/ccfWLeDX.o: In function `int g<int>(int)':
inlinexx2.cc:(.text+0x0): multiple definition of `int g<int>(int)'
/tmp/ccUa4K20.o:inlinexx.cc:(.text+0x0): first defined here
collect2: ld returned 1 exit status

Brak informacji inlinepodczas wykonywania jawnej instancji może również prowadzić do problemów.

Podsumowując : w przypadku nie w pełni wyspecjalizowanych szablonów funkcji, czyli takich, które zawierają co najmniej jeden nieznany typ, można pominąć inlinei nie otrzymać błędów, ale tak nie jest inline. W przypadku specjalizacji pełnych, czyli wykorzystujących tylko znane typy, nie można tego pominąć.

Proponowana praktyczna zasada : pisz, inlinejeśli masz to na myśli i bądź konsekwentny. Sprawia, że ​​mniej myślisz o tym, czy chcesz, czy nie, tylko dlatego, że możesz. (Ta praktyczna zasada jest zgodna z szablonem C ++ Vandevoorde'a / Josuttisa : kompletny przewodnik ).

To nieistotne. Wszystkie szablony już są inline- nie wspominając, że od 2012 roku jedynym zastosowaniem inlinesłowa kluczowego jest zatrzymanie kompilatorów narzekających na naruszenia ODR. Masz absolutną rację - Twój kompilator obecnej generacji sam wie, co wstawić i prawdopodobnie może to zrobić nawet między jednostkami tłumaczeniowymi.

Jak zasugerowałeś, inline jest wskazówką dla kompilatora i niczym więcej. Może ją zignorować lub w rzeczywistości wstawiać funkcje nieoznaczone jako wbudowane.

Używanie inlinez szablonami było kiedyś (słabym) sposobem obejścia problemu, że każda jednostka kompilacji tworzyłaby oddzielny obiekt dla tej samej klasy z szablonami, co powodowałoby problemy z powielaniem w czasie łączenia. Używającinline (myślę), że zniekształcenie nazwy działa inaczej, co powoduje konflikt nazw w czasie łącza, ale kosztem ogromnie rozdętego kodu.  

Marshall Cline wyjaśnia to lepiej niż ja.