overload-resolution

Java: runtime method resolution

别来无恙 提交于 2020-01-22 10:43:08
问题 I'm working on some dynamic invocation of code via an interpreter, and I'm getting into the sticky ugly areas of method resolution as discussed in JLS section 15.12. The "easy" way to choose a method is when you know the exact types of all the arguments, at which point you can use Class.getDeclaredMethod(String name, Class[] parameterTypes). Maybe you have to check method accessibility and the class's superclasses/superinterfaces. But this doesn't cover any of the following cases, so it's

In overload resolution, does selection of a function that uses the ambiguous conversion sequence necessarily result in the call being ill-formed?

北战南征 提交于 2020-01-22 06:45:07
问题 The question arose while I was researching the answer to this SO question. Consider the following code: struct A{ operator char() const{ return 'a'; } operator int() const{ return 10; } }; struct B { void operator<< (int) { } }; int main() { A a; B b; b << a; } The conversion of a to int can be either via a.operator char() followed by an integral promotion, or a.operator int() followed by an identity conversion (i.e., no conversion at all). The standard says that (§13.3.3.1 [over.best.ics]

In overload resolution, does selection of a function that uses the ambiguous conversion sequence necessarily result in the call being ill-formed?

爱⌒轻易说出口 提交于 2020-01-22 06:44:45
问题 The question arose while I was researching the answer to this SO question. Consider the following code: struct A{ operator char() const{ return 'a'; } operator int() const{ return 10; } }; struct B { void operator<< (int) { } }; int main() { A a; B b; b << a; } The conversion of a to int can be either via a.operator char() followed by an integral promotion, or a.operator int() followed by an identity conversion (i.e., no conversion at all). The standard says that (§13.3.3.1 [over.best.ics]

Overload resolution behaviour difference between GCC and clang (SFINAE)

与世无争的帅哥 提交于 2020-01-10 00:59:32
问题 GCC accepts the following code: template <typename T> struct meta { typedef typename T::type type; }; struct S {}; template <typename T> typename meta<T>::type foo(T, S); int foo(int, int); int main() { foo(0, 0); } But clang rejects it with the following error: test.cpp:4:22: error: type 'int' cannot be used prior to '::' because it has no members typedef typename T::type type; ^ test.cpp:10:10: note: in instantiation of template class 'meta<int>' requested here typename meta<T>::type foo(T,

Can implicits be used to disambiguate overloaded definition?

。_饼干妹妹 提交于 2020-01-04 04:53:17
问题 Consider the following overloaded definition of method mean : def mean[T](data: Iterable[T])(implicit number: Fractional[T]): T = { import number._ val sum = data.foldLeft(zero)(plus) div(sum, fromInt(data.size)) } def mean[T](data: Iterable[T])(implicit number: Integral[T]): Double = { import number._ val sum = data.foldLeft(zero)(plus) sum.toDouble / data.size } I would like second definition which returns Double only to be used in the case of Integral types, however mean(List(1,2,3,4))

Why isn't F# able to resolve overload between Async<> and Async<Result<>>?

自作多情 提交于 2020-01-03 16:44:40
问题 I want to understand the F# overload resolution a little better in a specific context. I'm writing a simple asyncResult workflow/computation expression to make error handling in the style of railway-oriented programming easier to use when combined with async workflows. I do this by overloading the Bind method on the workflow builder. This is fairly standard and used in all guides I've seen (and is also used in e.g. Chessie/ErrorHandling.fs). I have one overload that accepts an Async<_> and

Why isn't F# able to resolve overload between Async<> and Async<Result<>>?

房东的猫 提交于 2020-01-03 16:44:14
问题 I want to understand the F# overload resolution a little better in a specific context. I'm writing a simple asyncResult workflow/computation expression to make error handling in the style of railway-oriented programming easier to use when combined with async workflows. I do this by overloading the Bind method on the workflow builder. This is fairly standard and used in all guides I've seen (and is also used in e.g. Chessie/ErrorHandling.fs). I have one overload that accepts an Async<_> and

Conversion operator in direct-initialization

久未见 提交于 2020-01-03 13:04:57
问题 The C++14 standard (N4296) says in 8.5/17.6.1 If the initialization is direct-initialization [...], constructors are considered. The applicable constructors are enumerated, and the best one is chosen through overload resolution. [...] If no constructor applies, or the overload resolution is ambiguous, the initialization is ill-formed. Therefore in direct-initialization, only constructors are considered - conversion functions are ignored. In the following code there is no applicable

Why cannot C# resolve the correct overload in this case?

三世轮回 提交于 2020-01-03 06:45:11
问题 I've come across a strange situation which is non-ambiguous, yet the overload resolver doesn't think so. Consider: public static class Program { delegate int IntDel(); delegate string StringDel(); delegate void ParamIntDel(int x); delegate void ParamStringDel(string x); static void Test(IntDel fun) { } static void Test(StringDel fun) { } static void ParamTest(ParamIntDel fun) { } static void ParamTest(ParamStringDel fun) { } static int X() { return 42; } static void PX(int x) { } public

C++11: Universal executor

淺唱寂寞╮ 提交于 2020-01-02 04:11:08
问题 I would to know how get this code compiles: // test3.cpp #include <iostream> using namespace std; template<typename R, typename... rArgs> R universal_exer(R(*f)(rArgs...), rArgs... args) { return (*f)(forward<rArgs>(args)...); } int addition(int a) { return a; } int addition(int a, int b) { return a + b; } template<typename... Args> int addition(int a, int b, Args... args) { return a + b + addition(args...); } int main() { cout << universal_exer(&addition, 1) << endl; } Error message (gcc 4.7