Comments on: Perfect forwarding and overload resolution

By: Andrew Nelless

Andrew Nelless — Fri, 01 Jun 2012 13:53:56 +0000

Here’s some code that demonstrates what I mean:

http://codepad.org/mx41dQZu

By: Andrew Nelless

Andrew Nelless — Fri, 01 Jun 2012 13:50:17 +0000

Double actually, delete this and the above but not the above of the above ;) I’m right on this.

By: Andrew Nelless

Andrew Nelless — Fri, 01 Jun 2012 13:47:58 +0000

Actually nevermind, please delete this and the above.

By: Andrew Nelless

Andrew Nelless — Fri, 01 Jun 2012 13:42:07 +0000

Hi Boris, your ‘hairy’ example is missing “::type” on the end.

I don’t quite agree with your solution. First and foremost your template needs to be updated so it is disabled every time a “const Foo&” overload is added. If you’re doing that, why not just provide a f(Foo&) overload in the first place?

Convertibility testing is also imperfect. Let’s suppose you’ve only implementing f(int) and a user of your function developers a PrimeNumber class and declares a f(PrimeNumber const&) overload. Let’s also suppose this function is in a separate header file and merely forward declares PrimeNumber. Your template will deal with non-const PrimeNumber& lvalue references but, because the only way to provide implicit convertibility to int is via a conversion operator, will silently fail the is_convertible test because the full definition of the PrimeNumber class isn’t unavailable.

The result your template is still selected over the const& variant and your user is going to get unexpected linker errors or inconsistent behaviour.

By: Joe

Joe — Fri, 01 Jun 2012 12:57:20 +0000

I wasn’t trying to resolve the specific example. I was only trying to demonstrate that the same problem in the example exists if you overload with an lvalue ref template and, to a lesser extent, a non-reference template. With the point being that this particular trap is not rvalue ref/perfect forwarding specific.

By: Boris Kolpackov

Boris Kolpackov — Fri, 01 Jun 2012 06:19:03 +0000

Joe, Andrew, I agree there are different ways to resolve this issue. The approach I suggested is general enough that it can be applied to any set of overloaded functions while your approaches could be a better fit for this particular example.

By: Andrew Nelless

Andrew Nelless — Fri, 01 Jun 2012 00:53:40 +0000

You could have also created a template for static char arrays.

template
void f (char const (&arr)[N]) { f(std::string((char const*) arr, N)); }

Doing this will handle all the char array cases and (almost insignificantly) speed up the std::string construction. If your array reference contains binary data (a null char) this would actually be the safer option anyway (I think).

Personally I don’t feel the binding of f(s) to [T = std::string&] instead of to (const std::string&) is a bad thing either. Your perfect forwarding function could forward to a function capable of receiving a mutable reference. The alternative would be to force binding to const& over T&& and screw you over when you wanted to do just that.

By: Joe

Joe — Thu, 31 May 2012 21:21:31 +0000

I am not sure this is a fair criticism of rvalue refs or perfect forwarding.

I think you would run into the exact same issues if you used a simple rvalue ref

template
void f (T & x)
{
g (x);
}

if instead you use

template
void f (T x)
{
g (x);
}

Then f(s) will use the expected specialization, but f(”bbb”) will use the template.

The general lesson I’ve learned in the past is that overloading templates and non-templates that vary in cv qualifications or reference is asking for trouble. If a function signature doesn’t match the argument type exactly, it’s likely the template will be chosen.

By: sap

sap — Wed, 30 May 2012 22:04:20 +0000

oops the problem was indeed the missing const, not it works as you say.
great stuff.

By: Boris Kolpackov

Boris Kolpackov — Wed, 30 May 2012 18:44:50 +0000

Yes, without the enable_if addition, f(s) will be resolved to the forwarding function. I tested this with GCC 4.7 and now confirmed with Clang 3.0.

Note also that the non-template function in the post has the void f (const string&) signature, not void f (string&) as in your comment (that would certainly explain the difference in behavior). The other possibility is that VC11 implements v2.1 of the rvalue reference specification while GCC and Clang implement v3, which is what’s in the standard.