This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: c++/3708: Zealous template expansion



To correct the last posting to this thread,

BarBar::operator Foo () actually wins the joust with Bar::operator T ()
[ T = Foo ]
in routine joust (gcc/cp/call.c) in the following code

...............

  /* or, if not that,
     F1 is a non-template function and F2 is a template function
     specialization.  */
         
  if (! cand1->template && cand2->template)
    return 1;
  else if (cand1->template && ! cand2->template)
    return -1;
...............

The code then wraps this in a Foo::Foo(const Foo&) target node, and
adds this to the previously generated candidate Foo::Foo(int).
So, the r-value candidates for foo = (Foo) black_sheep are:

Foo::Foo(const Foo&) (via BarBar::operator Foo ())
Foo::Foo(int)        (via Bar::operator T () [T=int])

Hence the error message.

Since the jousts at the lower level of reccursion were only between
candidates generated by the Foo(int) and Foo(const Foo&) targets
independently,
the two possibilities BarBar::operator Foo () and Bar::operator T ()
[T=int]
were never diectly compared. Difficult to see how they could be at the
lower
level of the reccursion.

The subsequent joust of the reamining two r-values does not decend the
tree
to check that BarBar::operator Foo () is an explicit implementation of
Bar::operator T (), and resolve the ambiguity. It only resolves the
partial
ordering rules for the top level nodes.

Even if one argues that BarBar::operator Foo () does not override
Bar::operator T () [T=int],
(they do indeed have differing signatures), one looses the argument to
the partial ordering 
rules. When one adds to the partial ordering rules the extra
consideration that Bar is a 
base class of BarBar, well, that would seem to tip the scales.

Perhaps a beginning strategy is to add a template_expansion_used flag to
the tree nodes. 
When a template expansion is involved at any lower level of the tree, 
this flag is set at all levels above. That at least would mitigate
unnecessary decent
most of the time.

More generally, some metric that trickles up the
graph that will allow a single compare at the top level to resolve the
partial ordering
issue. ...hmmm......tricky. It may take some time......


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]