Impossibly Fast C++ Delegates and different translation units
Asked Answered
M

2

19

According to Sergey Ryazanov, his Impossibly Fast C++ Delegates are not comparable:

My delegates cannot be compared. Comparison operators are not defined because a delegate doesn't contain a pointer to method. Pointer to a stub function can be different in various compilation units.

To which one the readers have replied:

"Pointer to a stub function can be different in various compilation units." AFAIK, this is not true. Compilers are required to re-use template functions generated in different compilation units (this I am sure of - but I think Borland once violated this rule). I think it is because classes (ones not in 'nameless' namespaces) use external linkage and the way you use the stub functions will always prevent them from being inlined (although this shouldn't be an issue either as taking the address of the function will force a non-inline version to be generated and 'external linkage' performed by the linker will eliminate all but one similarly named function (they are assumed and required to be identical by the standard))...

If you define a template function one translation unit (cpp file) and then define the same function differently in another translation unit, only one of the two versions will make it into the final executable. (This actually violates the "One Definition Rule", but works on GCC, at least... not sure about MSVC.) The point is: the address [of the stub] will be the same in different units.

I would urge you to update the article (including comparison capability) if you find this to be true for MSVC - if MSVC is standards conferment, in this regard.

Now the article is four years old and the author hasn't replied to any of the comments during the past three years or so, so I'm wondering if there's any merit to the above comment and whether this specific implementation can indeed be changed to support comparisons.

Does the C++ standard specifically prohibit such usage and if so, are any of the recent compilers actually standard-compliant in that regard?

Mutism answered 6/10, 2009 at 17:14 Comment(1)
Even if the statement was true, comparibility can easily be added by adding an otherwise unused member to his delegates.Fiveandten
N
12

The code is both standard compliant, and fine. I don't see any place where he violates ODR, and it is true that all instantiations of a function template with the same template parameters should have "the same address" (in a sense that pointers to functions should all be equal) - how this is achieved is not important. ISO C++03 14.5.5.1[temp.over.link] describes the rules in more detail.

So, a comparison could well be defined there in a conformant and portable way.

Newberry answered 6/10, 2009 at 17:28 Comment(2)
What if the template instantiations reside in different DLLs? Or one in the main application and others in different DLLs?Remorse
The Standard does not really deal with the notion of DLL/shared libraries. In practice, of course, since they are compiled and linked separately, there's no way for the compilers to merge instantiations. So, yes, that would be a gotcha.Newberry
D
1

The so-called stub functions in Impossibly Fast C++ Delegates are static template member functions, which are basically template functions. The same applies for the improved variant Impossibly Fast C++ Delegates, Fixed.

So the question boils down to this:

Do instantiations of a template function (using the same template parameters and definition) in different translation units share the same function pointer address?

According to the C++ standard (ISO C++17, § 17.5.6.1), the answer is yes.

As @Pavel said in his answer, the same applied for the ISO C++03 standard (ISO C++03, § 14.5.5.1).

In other words this approach is standard compliant and delegates are safely comparable - their data compare equal if and only if they are bound to the same function and (in case of member functions) the same object.

Dinger answered 31/3, 2019 at 13:32 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.