Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Should Taking the Address of a Templatized Function Trigger its Compilation?

I got an official answer to this question that decltype should not trigger function compilation. In fact decltype on a function that is declared but not defined is legal.

Next question, should taking the address of a function trigger the compilation of a function? Take this example:

template <typename T>
void foo(T&& x) { x.func(); }

int main()
{
    auto bar = &foo<int>;
}

All the compilers I've tested fail with an error like:

Request for member func in x, which is of non-class type int

But if I just define foo and don't declare it, the code compiles fine. Can someone provide me with an official source on whether taking the address of a function should require it's compilation?

like image 538
Jonathan Mee Avatar asked Jul 15 '16 17:07

Jonathan Mee


People also ask

Are templates resolved at compile time?

All the template parameters are fixed+known at compile-time. If there are compiler errors due to template instantiation, they must be caught at compile-time!

Is template a compile time mechanism?

Templates are the feature that supports generic programming in C++, which are compile time mechanism and there is no runtime overhead associated with using them.

Are templates compile time or runtime?

This is a very important concept to understand when dealing with templates in C++: templates don't exist at runtime. All templates are compiled to real types at compile time.

What is true about function templates?

Explanation: As a template feature allows you to write generic programs. therefore a template function works with any type of data whereas normal function works with the specific types mentioned while writing a program. Both normal and template function accepts any number of parameters.


1 Answers

3.2/2:

An expression is potentially evaluated unless it is an unevaluated operand (Clause 5) or a subexpression thereof. ... A non-overloaded function whose name appears as a potentially-evaluated expression or a member of a set of candidate functions, if selected by overload resolution when referred to from a potentially-evaluated expression, is odr-used, unless it is a pure virtual function and its name is not explicitly qualified.

Then 3.2/3:

Every program shall contain exactly one definition of every non-inline function or variable that is odr-used in that program; no diagnostic required. The definition can appear explicitly in the program, it can be found in the standard or a user-defined library, or (when appropriate) it is implicitly defined (see 12.1, 12.4 and 12.8). An inline function shall be defined in every translation unit in which it is odr-used.

The function name is definitely not an unevaluated operand (for example to sizeof, decltype), AND it appears in an expression, so it's potentially evaluated. Then the second one requires exactly one non-inline definition, or identical inline definitions in each translation unit.

like image 75
Mark B Avatar answered Sep 18 '22 12:09

Mark B