Sign Up

Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.

Have an account? Sign In

Have an account? Sign In Now

Sign In

Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.

Sign Up Here

Forgot Password?

Don't have account, Sign Up Here

Forgot Password

Lost your password? Please enter your email address. You will receive a link and will create a new password via email.

Have an account? Sign In Now

You must login to ask a question.

Forgot Password?

Need An Account, Sign Up Here

Please briefly explain why you feel this question should be reported.

Please briefly explain why you feel this answer should be reported.

Please briefly explain why you feel this user should be reported.

Sign InSign Up

The Archive Base

The Archive Base Logo The Archive Base Logo

The Archive Base Navigation

  • SEARCH
  • Home
  • About Us
  • Blog
  • Contact Us
Search
Ask A Question

Mobile menu

Close
Ask a Question
  • Home
  • Add group
  • Groups page
  • Feed
  • User Profile
  • Communities
  • Questions
    • New Questions
    • Trending Questions
    • Must read Questions
    • Hot Questions
  • Polls
  • Tags
  • Badges
  • Buy Points
  • Users
  • Help
  • Buy Theme
  • SEARCH
Home/ Questions/Q 3696940
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Editorial Team
Asked: May 19, 20262026-05-19T04:47:58+00:00 2026-05-19T04:47:58+00:00

Some time ago I was confused by the following behavior of some code when

  • 0

Some time ago I was confused by the following behavior of some code when I wanted to write a is_callable<F, Args...> trait. Overload resolution won’t call functions accepting arguments by non-const ref, right? Why doesn’t it reject in the following because the constructor wants a Test&? I expected it to take f(int)!

struct Test {
  Test() { }

  // I want Test not be copyable from rvalues!
  Test(Test&) { }

  // But it's convertible to int
  operator int() { return 0; }
};

void f(int) { }
void f(Test) { }

struct WorksFine { };
struct Slurper { Slurper(WorksFine&) { } };
struct Eater { Eater(WorksFine) { } };

void g(Slurper) { }
void g(Eater) { } // chooses this, as expected

int main() {
  // Error, why?
  f(Test());

  // But this works, why?
  g(WorksFine());
}

Error message is

m.cpp: In function 'int main()':
m.cpp:33:11: error: no matching function for call to 'Test::Test(Test)'
m.cpp:5:3: note: candidates are: Test::Test(Test&)
m.cpp:2:3: note:                 Test::Test()
m.cpp:33:11: error:   initializing argument 1 of 'void f(Test)'

Can you please explain why one works but the other doesn’t?

  • 1 1 Answer
  • 0 Views
  • 0 Followers
  • 0
Share
  • Facebook
  • Report

Leave an answer
Cancel reply

You must login to add an answer.

Forgot Password?

Need An Account, Sign Up Here

1 Answer

  • Voted
  • Oldest
  • Recent
  • Random
  1. Editorial Team
    Editorial Team
    2026-05-19T04:47:59+00:00Added an answer on May 19, 2026 at 4:47 am

    Overload resolution picks the function that is the closest match to the supplied argument. You supplied a Test. No conversion necessary — identity conversion used. Thus function resolution chooses f(Test). Test can’t be copied from rvalue, which you supplied, but overload resolution has succeeded already…conversion to int is never checked.

    g(Eater) is chosen because the types don’t exactly match, the identity conversion is NOT used, and the compiler has to find a conversion routine that works. g(Slurper) doesn’t because you can’t make one out of the supplied argument.

    “Why doesn’t this one fail: struct A { operator int(); }; void f(A&); void f(int); void g() { f(A()); }“

    Because f(A&) is not a viable overload for the supplied argument. In this case the parameter is a reference and the fact that temps don’t bind to non-const is allowed to effect the resolution. In this case it does and the that version of the function becomes a non-candidate, leaving only the one and it works.

    • 0
    • Reply
    • Share
      Share
      • Share on Facebook
      • Share on Twitter
      • Share on LinkedIn
      • Share on WhatsApp
      • Report

Sidebar

Related Questions

Some time ago I wrote a little piece of code to ask about on
some time ago I found an article ( Roles: Composable Units of Object Behavior
Some time ago, I came across a piece of code, that used some piece
Some time ago I got this error when building ANY Visual Studio Deployment project.
Some time ago I put together a time based library that could be used
Background: Some time ago, I built a system for recording and categorizing application crashes
I learned some time ago about Decision Trees and Decision tables. I feel that
I remember some rules from a time ago (pre-32bit Intel processors), when was quite
I commented on this answer some time ago regarding how visual studio comments out
Since some time, my Delphi debugger became much slower than I was used to

Explore

  • Home
  • Add group
  • Groups page
  • Communities
  • Questions
    • New Questions
    • Trending Questions
    • Must read Questions
    • Hot Questions
  • Polls
  • Tags
  • Badges
  • Users
  • Help
  • SEARCH

Footer

© 2021 The Archive Base. All Rights Reserved
With Love by The Archive Base

Insert/edit link

Enter the destination URL

Or link to existing content

    No search term specified. Showing recent items. Search or use up and down arrow keys to select an item.