«

On Jul 13, 6:45 pm, "jkn...@gmail.com" <jkn...@gmail.com> wrote:
> On Jul 13, 4:47 am, James Kanze <james.ka...@gmail.com> wrote:

[...]
> Thanks, this is what I had assumed. What is still a bit
> unclear to me, though, is that Type is being used as the
> return type of foo, which I didn't think participated in
> overload resolution.

It doesn't, but...

In your example, the overload resolution of &T::foo was a
special case; the overload resolution of &T::foo depends on the
type it is initializing or being assigned to. And until the
compiler has done the type deduction of bar, the parameters
don't have a type, so neither type deduction nor overload
resolution can proceed. The return type of the pointer to
function parameter will be ignored once overload resolution for
&T::foo is invoked, but the compiler can't even get that far.

> At the point that it is resolving the overload for foo (and
> thus deducing the types for bar), wouldn't Type be extraneous
> information?

If the compiler got that far.

> If not, it seems that if you were to replace the templated foo
> with 'int foo(int arg)' that the amount of information is the
> same with respect to overload resolution, yet the latter case
> will work.

No, because the compiler can't start working until it has
deduced the actual type of foo. Which in turn depends on the
actual type of the parameter. Which depends on the type of the
argument. Which is what we're trying to deduce. The fact that
the return type will not be used in the overload resolution
later doesn't stop the compiler from having to deduce it. In
the end, the compiler will have to know the return type of both
the pointer to member function, and the function whose address
is being assigned to it. And there are no provisions for the
compiler to do partial type deduction on the parameter, skipping
the return type, then do overload resolution (with the
associated type deduction on the template functions), then come
back and finish the type deduction on bar.

> > As an intelligent human, you can easily solve the problem, but
> > if you think about it, in solving it, you jump back and forth,
> > first elimiating some of the overloads for foo (without having
> > all of the necessary information for full overload resolution),
> > using intuitive information about the possible results. The
> > compiler can only do one thing after the other, and in this
> > case, you have a circular dependency for it: to do A, it must
> > first do B, and to do B, it must first do A. It doesn't have
> > enough imagination to be able to speculatively do A and B in
> > parallel.

> Again, I understand you point here, but that presupposes that
> they return type for foo is relevant.

It is, in the end. It is needed to deduce the template
arguments for bar. And until those template arguments are
deduced, the "pointer to function" doesn't have a known type,
and the compiler cannot proceed with overload resolution on the
argument. The fact that the return type is not used in this
overload resolution is irrelevant; for the overload resolution
to start, the type must be known.

(Actually, I'm not even 100% certain that you can say that the
return type is irrelevant here. Taking the address of a
function is a special case, where the use is taken into account.
But it doesn't matter, because you don't get that far.)

> I was under the impression that it wasn't for overload
> resolution (at least at the resolution stage we are at), but
> obviously may be mistaken.

Again, you're failing before overload resolution starts.

--
James Kanze (GABI Software) email:
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

On 13 juil, 18:34, "jkn...@gmail.com" <jkn...@gmail.com> wrote:
> On Jul 13, 4:53*am, courp...@gmail.com wrote:
>
>
> > On 13 juil, 05:44, "jkn...@gmail.com" <jkn...@gmail.com> wrote:
>
> > > In this case, though, it shouldn't necessarily need to know the return
> > > type to determine the proper overloaded function as it can use the
> > > number of arguments. I'm just a bit confused about the order in which
> > > the two actions are applied (the type deduction and the overload
> > > resolution)
>
> > Overload resolution comes before type deduction.
>
> Understood. Do you know where this is mentioned in the standard?


14.8.2.2/1 : "Template arguments can be deduced from the type
specified when taking the address of an overloaded function."


As soon as type deduction handles adresses of overload functions, then
the whole type deduction process must complete after overload
resolution (otherwise it could lead to ambiguous cases) . However, I
would rather see overload resolution as a step in the type deduction
process and that step is generally the final one.

But, in our case, it is not the final step. If some types of the
signature of the overloaded function must be deduced and that
deduction can't be "directly" done from the function call (explicit
template specialization,...), then there is what we can call "template
overload resolution" : type deduction will check if the overload set
provides a match for the "template signature" (that overload set must
not contain function template). From that "template overload
resolution", type deduction can take from the matched candidate the
correct types.


> > As I said earlier, when function templates are involved, type
> > deduction fails. Your code is non-standard. It would be standard if
> > you replaced the function template foo by a non-template version.
>
> Assuming you are saying that this particular combination of type
> deduciton and overload resolution will not work, and not that the
> standard prevents you from overloading a funciton template with a non-
> template function (which is not true), is there a way to acheive the
> same effect in a compliant way? In the acutal code, the bar function
> takes additional parameters (a field name) and is used to copy a
> subset of the values of A (the foo functions represent accessors and
> mutators of A) on a seperate object. What I would rather not do is be
> forced to specify the bar<int>, which would be different for each
> accessor of A and subject to change.
>

If it's different for each accessor and subject to change, then
encapsulate it.
Slight modification of your example :

#include <iostream>
using namespace std;

class A
{
public:
typedef int return_type; // type trait
int foo()
{
cout << "int foo" << endl;
return 5;
}
template <class A>
void foo (A a)
{
cout << "template foo" << endl;
}
};

template <class Obj>
void bar (Obj& obj, typename Obj::return_type (Obj::*func)())
{
typename Obj::return_type t = (obj.*func)();
cout << "TYPE: " << t << endl;
}
int main ()
{
A a;
bar(a, &A::foo); // should compile on a conforming compiler
}


Here, every part of the foo signature can be directly deduced from the
function call (from &A::foo) without resorting to "template overload
resolution", then it doesn't matter whether there is a function
template in the foo overload set.


Alexandre Courpron.