Should this program compile?

Question

int foo() restrict(amp) {
    return 111;
}

 int foo() restrict(cpu) {
     return 999;
 }

void* get_address() {
    return static_cast<void*>(foo);
}

Error 1 error C2440: 'static_cast' : cannot convert from 'overloaded-function' to 'void *'

Answer 1

Hi wwwwpan,

Good question! First of all, you will get same error if you change the program to:

int foo(int)
{
    return 111;
}

int foo(float)
{
    return 999;
}

void * get_address()
{
    return static_cast<void*>(foo);
}

Simply provide the overloaded function name foo is not enough to disambiguate between the two foos in this case.

Now you could argue that since get_address is restrict(cpu), compiler could choose the restrict(cpu) version of foo to disambiguate. This could be one possible semantics. But we choose not to do so because if we use the ambient context to eliminate the restrict(amp) candidate for this case, then it's not clear what should be done if there is only one foo, which is restrict(amp). Error since there is no restrict(cpu) candidate but the ambient context is restrict(cpu), or bound to the restrict(amp) overload since there is no ambiguity? Note that we currently don't allow function pointers with restrict(amp) in v1, but we probably would relax that restriction in future. So we choose to make it ambiguous for this case. You could always use type cast to help the compiler to pick the one you want, like:

return static_cast<void*>((int (*)() restrict(cpu))foo);

"restrict(cpu)" could be omitted above since it's the default.

Does this make sense? Let me know if you have more questions.

Thanks,
Lingli 

Answer 2

 But we choose not to do so because if we use the ambient context to eliminate the restrict(amp) candidate for this case, then it's not clear what should be done if there is only one foo, which is restrict(amp).

An error is logical? Like inside a const member function you cannot call a non-const member function. 

Answer 3

Also the following code compiles

int foo() { return 111; } 

int foo() restrict(amp) { return 999; }

int bar() restrict(amp, cpu) {
   return foo(); // (*)
}

however, which foo function is called in (*) is determined by the call instance to bar. I.e the overload resolution is not unique during the parsing of declaration bar. This seems odd in c++.

  

Answer 4

Here, you are not invoking the function, instead, you are taking the address of the function. You can taking the address of non-const member function inside a const member function, right?

Answer 5

Yeah, this is by-design. Please refer to Function overloading with restrict in C++ AMP for more information regarding this topic.

The difference between this example and the example in your original post is that one invokes the function, the other takes the address of the function. Currently, we do restrict context sensitive resolution for function invocations, but not for taking address of functions. We are actively discussing the semantic for v.next, so your feedbacks would be very appreciated.

Answer 6

Great blog and thanks for answering my questions! It is interesting and deserves more thinking.

Answer 7

This implies that the first will not compile but the second will.

int bar() restrict(amp, cpu) {
 auto f = foo;    
 return f();
}

int bar() restrict(amp, cpu) {
  return foo();
}

Answer 8

Yes. We want to differentiate function invocations from function address taking so that in future we could potentially taking address of an amp-restricted function inside a restrict(cpu) function if we start to support function pointer with restrict(amp). If you always eliminate overload candidates based on ambient context, you will not be able to do that.