6

This question arised in the context of this answer.

As I would expect, this translation unit does not compile:

template <int Num> int getNum() { return Num; }
template int getNum<0>();
template int getNum<0>();  // error: duplicate explicit instantiation of 'getNum<0>'
int main() { getNum<0>(); return 0; }

I understand this, I have tried to make the same explicit template instantiation twice. However, it turns out that, separating this into different units, it compiles:

// decl.h
template <int Num> int getNum() { return Num; }

// a.cc
#include <decl.h>
template int getNum<0>();

// b.cc
#include <decl.h>
template int getNum<0>();
int main() { getNum<0>(); return 0; }

I did not expect this. I assumed that multiple explicit template instantiations with the same parameters would break ODR, but that does not seem to be the case. This, however, does fail:

// decl.h
template <int Num> int getNum();

// a.cc
#include "decl.h"
template <> int getNum<0>() { return 0; }

// b.cc
#include "decl.h"
template <> int getNum<0>() { return 0; }
int main() { getNum<0>(); return 0; }

User Oliv helpfully pointed me to this relevant paragraph in the standard, but I am still somewhat confused by it, so I was hoping someone could explain in simpler terms the logic behind this (as in, what should or should not be considered to break ODR and why my expectation was wrong).

EDIT:

As a further example, here is a program divided in two units that compiles correctly yet it produces arguably surprising results:

// a.cc
template <int Num> int getNum() { return Num + 1; }
template int getNum<0>();

// b.cc
#include <iostream>
template <int Num> int getNum() { return Num; }
template int getNum<0>();
int main() { std::cout << getNum<0>() << std::endl; return 0; }

Output:

1

In this case, removing the explicit template instantiations produces 0. I know that having two templates with different definitions is not a common use case, but I thought ODR was precisely enforced to avoid this sort of problem.

jdehesa
  • 58,456
  • 7
  • 77
  • 121
  • AFAIK, there’s no difference between implicit and explicit instantiation other than the invisibility of the former. – molbdnilo Oct 05 '18 at 11:20
  • 1
    Yeah, template instantiations are weak symbols, so the linker just chooses any which it feels like. Not too sure about it though, hence not an answer. – Hugo Maxwell Oct 05 '18 at 11:30
  • @molbdnilo Thanks for the comment. I understand what you mean, but I'm not convinced why it should be like that. I have added a (convoluted) case where explicit initialization produces an unexpected result. – jdehesa Oct 05 '18 at 11:41
  • 3
    "Every program shall contain exactly one definition of every non-inline function or variable that is odr-used in that program outside of a discarded statement; **no diagnostic required**." – geza Oct 05 '18 at 11:42
  • @geza Right, which means that if I do that the program may compile but will probably not work as expected, right? But wouldn't it be better to treat explicit template instantiations as strong symbols, and fail on linking if necessary? Is there any benefit to the current behavior? Or is there any reason why compilers might not be able to do that? – jdehesa Oct 05 '18 at 11:50
  • @jdehesa: yep. You've just given an example of this (printing 0 vs 1). About strong symbols: it would only solve the case, when you have two explicit instantiations. For other cases (one expl. and one impl.), it doesn't. Perhaps NDR is there, because it is hard to detect whether two (impl.) instantiations are the same reliably (across different versions of the compiler, or even across different compilers). – geza Oct 05 '18 at 12:02
  • 1
    strong/weak symbol are outside of c++ standard. it has been done to not force compiler to check that, IMO, as in general case it might be complicated to check each ODR violation. – Jarod42 Oct 05 '18 at 12:04
  • The last answer is really out of the subject. The point of instantiation may only influence dependent name lookup (that is if you perform a call that would involve ADL and when an argument depend on a template parameter). All other name are resolved at the point of definition of the template. So instantiation point has no influence on ODR here. To be read: http://eel.is/c++draft/temp.dep.res#1 – Oliv Oct 05 '18 at 21:13

2 Answers2

5

Eureka! I finally fall on the relevant paragraph, [temp.spec]/5

For a given template and a given set of template-arguments,

  • (5.1) an explicit instantiation definition shall appear at most once in a program,

  • (5.2) an explicit specialization shall be defined at most once in a program, as specified in [basic.def.odr], and

  • (5.3) both an explicit instantiation and a declaration of an explicit specialization shall not appear in a program unless the explicit instantiation follows a declaration of the explicit specialization.

An implementation is not required to diagnose a violation of this rule.

So explicit template instantiation definition (not implicit instantiation) can cause ODR violation, no diagnostic required (and at least gcc and clang - ld toolchains do not produce diagnostic)

Oliv
  • 17,610
  • 1
  • 29
  • 72
  • Great work, that makes it quite clear indeed. I suppose it is more difficult than it seems for a compiler to diagnose this mistake. Btw, I think this implies that the compilation error for the third example in the question (with template specializations) is not actually guaranteed by the standard? – jdehesa Oct 05 '18 at 16:05
  • @jdehesa In the third case, you declare explicit template *specializations*, this is treated in an other paragraph [temp.expl.spec](http://eel.is/c++draft/temp.expl.spec#6). (I was just reading it now), => *no diagnostic required* – Oliv Oct 05 '18 at 16:11
  • @jdehesa But good news if you compile with gcc or clang, the symbol in the object file is not weak! So you will always get a link time error. – Oliv Oct 05 '18 at 16:15
  • Oh I see, thanks, I thought that was covered by 5.2 in the paragraph you posted, and that the paragraph you linked was about the declaration-use order of the specialization. Anyway, NDR in any case! Thanks for checking with gcc and clang, I tested with MSVC and it seems to do the same. – jdehesa Oct 05 '18 at 16:16
  • @jdehesa Indeed the second sentence of this last paragraph is redundant with the second bullet of the first paragraph. – Oliv Oct 05 '18 at 16:22
0

Both, explicit specialization and explicit instantiation definition will violate ODR based on the context they are used and the meaning of the entities they generate.

The following explain the first and the third case and why they does violate ODR with NDR [temp.spec]/5

For a given template and a given set of template-arguments,

  • (5.1) an explicit instantiation definition shall appear at most once in a program,

  • (5.2) an explicit specialization shall be defined at most once in a program (according to 6.2), [...]

function templates may have different points of instantiation in both the same translation unit where they are defined and in others translation units, these specialization are guaranteed not to violate ODR when the meaning of these specialization is the same in all the points of instantiation.

since by [temp.point]/6

An explicit instantiation definition is an instantiation point for the specialization or specializations specified by the explicit instantiation.

and [temp.point]/8

[...] If two different points of instantiation give a template specialization different meanings according to the one-definition rule (6.2), the program is ill-formed, no diagnostic required.

the second case does not violate ODR, because the meaning of the instantiations in these TU is the same.

// decl.h
template <int Num> int getNum() { return Num; }

// a.cc
#include <decl.h>
template int getNum<0>();

// b.cc
#include <decl.h>
template int getNum<0>();
int main() { getNum<0>(); return 0; }

But the last is certainly not a valid one (violate ODR NDR), because even the function templates have the same signatures the instantiations from them will have different meanings. You can't relay in the result you got, the standard don't guarantee the behavior when these violation happens.

// a.cc
template <int Num> int getNum() { return Num + 1; }
template int getNum<0>();

// b.cc
#include <iostream>
template <int Num> int getNum() { return Num; }
template int getNum<0>();
int main() { std::cout << getNum<0>() << std::endl; return 0; }
Community
  • 1
  • 1
Jans
  • 11,064
  • 3
  • 37
  • 45
  • Thank you for the detailed explanation, reading the standard can make me feel like Groucho Marx, but this is helpful. You explain that the first and third examples violate ODR with NDR, although these two are actually the ones where I get compilation errors. You mean then these compilation errors are not guaranteed by the standard, right? – jdehesa Oct 05 '18 at 19:01
  • in the same section of [temp.spec]/5 state that the implementation is not required to diagnose, that make me think that no, they aren't obligated but these cases are IMO easy to recognize then, why not diagnose them? – Jans Oct 05 '18 at 19:21
  • Aff... The second case is not valid, because it violates temp.spec/5.1 it can't be clearer. In the last one, ODR violation is due to the different template definitions see [basic.def.odr]/12, even without any template instantiation! – Oliv Oct 05 '18 at 20:49
  • Last but not least, the point of instantiation can only change the definition of a template function because of dependent name lookup. There are no dependent name lookup in any definitions of template getNum. So your answer is realy out of the subject. Sorry! – Oliv Oct 05 '18 at 21:08
  • @Oliv, for the second case (5.1) relate to appearing at most once(which it doesn't, NDR) but what is not clear to me is that is explicitly state that they constitue a ODR violation, because [basic.def.odr]/12 refer to template specialization for which some template parameters are not specified (which they aren't). – Jans Oct 05 '18 at 21:59
  • For the last case, read again [basic.def.odr]/12, 12.7 and [temp]/10 and you'll see that the multiple definitions of a function template doesn't make it violate ODR as long as they are composed of the same sequence of tokens(which they don't), and you're right, this violation happens even without instantiation, I neved denied that. – Jans Oct 05 '18 at 21:59
  • @Jans Indeed (5.1) does not refers to basic.def.odr. But it requires that only one template instantiation definition exist in the program. So this is literally but not formally an odr rule. The same apply to implicit instantiation at the points of instantiation, it is never said in the standard (what your answer seems to suppose) that variations of the meaning of the definition of a template specialization at two different point of instantiation consitute an ODR violation. But I agree with you to call this variation an ODR violation. – Oliv Oct 06 '18 at 06:59