0

gcc fails to compile this code, but clang compiles it well.

According to this gcc is right. Because there is several base classes with the same function name - operator(), which is an ambiguity

Is it really clang bug? Or may be there is special lookup rules for operator() in standard or something else not so obvious?

#include <utility>

template <class... Ts>
class TMultiLambda: public Ts... {
public:
    template <class... Fs>
    TMultiLambda(Fs&&... Vs) noexcept: Ts(std::forward<Fs>(Vs))... {
    }
};
template <class... Ts>
auto MakeMultiLambda(Ts&&... Vs) noexcept -> TMultiLambda<std::remove_reference_t<Ts>...> {
    return { std::forward<Ts>(Vs)... };
}

int main() {
    int x;
    auto a = [x](int, int) { };
    auto b = [x] (char) { };
    auto c = MakeMultiLambda(a, b);
    c(2, 2);
    c('q');
    return 0;
}

P.S. You can compile code online here, do not forget to append -std=c++1y to compiler options

Community
  • 1
  • 1
DimanNe
  • 1,791
  • 3
  • 12
  • 19
  • What about the question you linked didn't answer your question? – Barry Sep 09 '15 at 20:02
  • @Barry Operator lookup might make a difference. (But it doesn't.) – dyp Sep 09 '15 at 20:04
  • Related: http://stackoverflow.com/q/19159784/ – dyp Sep 09 '15 at 20:05
  • @Barry Ah, that's the one I've been looking for :) – dyp Sep 09 '15 at 20:08
  • @Barry in this case I use lambdas, and they could be handled/treated in some special way. For example they can at some conditions define implicit conversion operator (see ClosureType::operator ret(*)(params)() at http://en.cppreference.com/w/cpp/language/lambda), which in its turn can somehow affect lookup rules. – DimanNe Sep 09 '15 at 20:14

0 Answers0