Can using a lambda in header files violate the ODR?

by

This boils down to whether or not a lambda’s type differs across translation units. If it does, it may affect template argument deduction and potentially cause different functions to be called – in what are meant to be consistent definitions. That would violate the ODR (see below).

However, that isn’t intended. In fact, this problem has already been touched on a while ago by core issue 765, which specifically names inline functions with external linkage – such as f:

7.1.2 [dcl.fct.spec] paragraph 4 specifies that local static variables and string literals appearing in the body of an inline function with
external linkage must be the same entities in every translation unit
in the program. Nothing is said, however, about whether local types
are likewise required to be the same.

Although a conforming program could always have determined this by use
of typeid, recent changes to C++ (allowing local types as template
type arguments, lambda expression closure classes) make this question
more pressing.

Notes from the July, 2009 meeting:

The types are intended to be the same.

Now, the resolution incorporated the following wording into [dcl.fct.spec]/4:

A type defined within the body of an extern inline function is the same type in every translation unit.

(NB: MSVC isn’t regarding the above wording yet, although it might in the next release).

Lambdas inside such functions’ bodies are therefore safe, since the closure type’s definition is indeed at block scope ([expr.prim.lambda]/3).
Hence multiple definitions of f were ever well-defined.

This resolution certainly doesn’t cover all scenarios, as there are many more kinds of entities with external linkage that can make use of lambdas, function templates in particular – this should be covered by another core issue.
In the meantime, Itanium already contains appropriate rules to ensure that such lambdas’ types coincide in more situations, hence Clang and GCC should already mostly behave as intended.

Standardese on why differing closure types are an ODR violation follows. Consider bullet points (6.2) and (6.4) in [basic.def.odr]/6:

There can be more than one definition of […]. Given such an entity named D defined in more than one translation unit, then each definition of D shall consist of the
same sequence of tokens; and

(6.2) – in each definition of D, corresponding names, looked up
according to [basic.lookup], shall refer to an entity defined within
the definition of D, or shall refer to the same entity, after
overload resolution ([over.match]) and after matching of partial
template specialization ([temp.over]), […]; and

(6.4) – in each definition of D, the overloaded operators referred to,
the implicit calls to conversion functions, constructors,
operator new functions and operator delete functions, shall refer to
the same function, or to a function defined within the definition of
D; […]

What this effectively means is that any functions called in the entity’s definition shall be the same in all translation units – or have been defined inside its definition, like local classes and their members. I.e. usage of a lambda per se is not problematic, but passing it to function templates clearly is, since these are defined outside the definition.

In your example with C, the closure type is defined within the class (whose scope is the smallest enclosing one). If the closure type differs in two TUs, which the standard may unintentionally imply with the uniqueness of a closure type, the constructor instantiates and calls different specializations of function‘s constructor template, violating (6.4) in the above quote.

More Related Contents:

  1. A positive lambda: ‘+[]{}’ – What sorcery is this? [duplicate]
  2. Capturing a reference by reference in a C++11 lambda
  3. Lambda capture and parameter with same name – who shadows the other? (clang vs gcc)
  4. What is a lambda expression in C++11?
  5. Has C++ standard changed with respect to the use of indeterminate values and undefined behavior in C++14?
  6. Is it possible to figure out the parameter type and return type of a lambda?
  7. C++11 does not deduce type when std::function or lambda functions are involved
  8. Do distinct functions have distinct addresses?
  9. Is the size of std::array defined by standard
  10. Using member variable in lambda capture list inside a member function
  11. Capturing perfectly-forwarded variable in lambda
  12. In C++11, does `i += ++i + 1` exhibit undefined behavior?
  13. Function returning a lambda expression
  14. What does the void() in decltype(void()) mean exactly?
  15. Can the point-of-instantiation be delayed until the end of the translation unit?
  16. How can an incomplete type be used as a template parameter to vector here?
  17. Is the Empty Base Class Optimization now a mandatory optimization (at least for standard-layout classes)?
  18. Can lambda functions be recursive? [duplicate]
  19. What is the lifetime of a C++ lambda expression?
  20. Classes with both template and non-template conversion operators in the condition of switch statement
  21. reinterpret_cast between char* and std::uint8_t* – safe?
  22. What is the difference between std::quick_exit and std::abort and why was std::quick_exit needed?
  23. Can we get the type of a lambda argument?
  24. Does C++11 change the behavior of explicitly calling std::swap to ensure ADL-located swap’s are found, like boost::swap?
  25. Using data member in lambda capture list inside a member function
  26. Using std::bind with member function, use object pointer or not for this argument?
  27. C++ priority_queue with lambda comparator error
  28. When to use functors over lambdas
  29. Why can’t C++11 move a noncopyable functor to a std::function?
  30. Using Boost adaptors with C++11 lambdas

Leave a Comment