28

Why does the C++ standard define two phase lookup for templates? Couldn't non dependent declarations and definitions' lookups be deferred to the instantiation stage as well?

Johannes Schaub - litb
  • 496,577
  • 130
  • 894
  • 1,212
Xyand
  • 4,470
  • 4
  • 36
  • 63
  • 1
    Related: [What exactly is “broken” with Microsoft Visual C++'s two-phase template instantiation?](http://stackoverflow.com/questions/6273176/what-exactly-is-broken-with-microsoft-visual-cs-two-phase-template-instanti). Also, if you google `msvc broken two-phase name lookup` you will get a few more examples of what happens. – Jesse Good Sep 24 '12 at 09:18

2 Answers2

33

They could. This is the way most early implementations of templates worked, and is still the way the Microsoft compiler worked. It was felt (in the committee) that this was too error prone; it made it too easy to accidentally hijack a name, with the instantiation in one translation unit picking up a local name, rather than the desired global symbol. (A typical translation unit will consist of a sequence of #includes, declaring the names that everyone should see, followed by implementation code. At the point of instantiation, everything preceding the point of instantation is visible, including implementation code.)

The final decision was to classify the symbols in a template into two categories: dependent and non-dependent, and to insist that the non-dependent symbols be resolved at the point of definition of the template, to reduce the risk of them accidentally being bound to some local implementation symbols. Coupled with the requirement to specify typename and template when appropriate for dependent symbols, this also allows parsing and some error checking at the point of definition of the template, rather than only when the template is instantiated.

Jive Dadson
  • 16,680
  • 9
  • 52
  • 65
James Kanze
  • 150,581
  • 18
  • 184
  • 329
  • +1 - a great explanation of reasoning behind definitions given in standard – Zdeslav Vojkovic Sep 24 '12 at 09:08
  • Thanks! Just the reasoning I was looking for. So now local names (say non-dependent inherited member functions) can be hijacked by globals. Is that right? – Xyand Sep 24 '12 at 12:27
  • 6
    @Albert Yes. To be frank, I wasn't (and still am not) too hot on the adapted solution. Partially, because it doesn't really solve all of the problem; you need to systematically use fully qualified names for that, even today. And also because I find the implicit differentiation between dependent and non-dependent names a bit tricky: _if_ two different look-ups really are necessary, then I'd prefer having to explicitly specify the names which get dependent look-up, rather than have it depend on arguments, etc. – James Kanze Sep 24 '12 at 14:12
  • 1
    @JamesKanze can you please provide a proper example where this will fail? – user1708860 Jul 19 '15 at 20:05
1

This could be viewed as an application of separation of concerns.

At the first phase it just checks for correct syntax, and resolves non-dependent names, as explained here. At the second phase it does something more template specific, verifying if the calls are valid with the specific types. See this [answer] ( Two phase lookup - explanation needed)

Furthermore, if it would be done in only one phase, then it should be done every instantiation. This way is done only once.

If would be done only on the first instantiation, then it would be the same thing, only less structured.

Community
  • 1
  • 1
coredump
  • 3,017
  • 6
  • 35
  • 53