Ttdfjt

Why is the Apollo LEM ladder so far from the ground?

How many oliphaunts died in all of the Lord of the Rings battles?

Why did House of Representatives need to condemn Trumps Tweets?

Why does this RX-X lock not appear in Extended Events?

Can a US President, after impeachment and removal, be re-elected or re-appointed?

Applying a Taylor series WITH RESPECT TO ... and AROUND...

How long until two planets become one?

Self-deportation of American Citizens from US

What do you call a flexible diving platform?

Why did some Apollo missions carry a grenade launcher?

Does dual boot harm a laptop battery or reduce its life?

How to store my pliers and wire cutters on my desk?

Is it safe if the neutral lead is exposed and disconnected?

Does Wolfram Mathworld make a mistake describing a discrete probability distribution with a probability density function?

Are the named pipe created by `mknod` and the FIFO created by `mkfifo` equivalent?

Are there any unpublished Iain M. Banks short stories?

Summoning A Technology Based Demon

Why force the nose of 737 Max down in the first place?

How can religions be structured in ways that allow inter-faith councils to work?

Anti-cheating: should there be a limit to a number of toilet breaks per game per player?

Exploiting the delay when a festival ticket is scanned

What is "sed -i 's,-m64,,g'" doing to this Makefile?

Can I change the license of a forked project to the MIT if the license of the parent project has changed from the GPL to the MIT?

What steps would an amateur scientist have to take in order to get a scientific breakthrough published?

literal `0` being a valid candidate for int and const string& overloads causes ambiguous call

Ambiguous call to Overloaded Function (const variety)Can we overload main() function in C++?call of overloaded 'min(int&, int&)' is ambiguousHow to resolve ambiguous overloaded function call?“ambiguous overload for 'operator[]'” if conversion operator to int existC++11 auto, std::function and ambiguous call to overloaded functionReplacing a 32-bit loop counter with 64-bit introduces crazy performance deviationsC++ - How does the compiler decide between overloaded functions with reference types as parameter?Why does the compiler complain for ambiguity in overloaded function?Failed to understand (and fix) why this warning “call of overload xxx is ambiguous” exists

.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty margin-bottom:0;

38

3

I fixed a bug recently.

In the following code, one of the overloaded function was const and the other one was not. The issue will be fixed by making both functions const.

My question is why compiler only complained about it when the parameter was 0.

#include <iostream>
#include <string>

class CppSyntaxA

public:
 void f(int i = 0) const i++; 
 void f(const std::string&)
;

int main()

 CppSyntaxA a;
 a.f(1); // OK
 //a.f(0); //error C2666: 'CppSyntaxA::f': 2 overloads have similar conversions
 return 0;

c++ overloading ambiguous-call

share|improve this question

edited Jul 23 at 22:40

Paulw11

73.7k1010 gold badges9595 silver badges111111 bronze badges

asked Jul 18 at 20:00

Cong MaCong Ma

60388 silver badges1616 bronze badges

• 
  
  
  

  
  3
  

  
  
  
  
  
  

  
  
  @NeilButterworth GCC shows the same behavior.
  
  – Miles Budnek
  Jul 18 at 20:05
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  @Miles No, it doesn't.
  
  – Neil Butterworth
  Jul 18 at 20:06
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  
  @NeilButterworth sure does: wandbox.org/permlink/mEtMFPt5KMdSVGs3 and wandbox.org/permlink/8UiG8XD7d0ol8U8v
  
  – Parsa
  Jul 18 at 20:06
  
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  clang seems happy with it for what that's worth.
  
  – tadman
  Jul 18 at 20:07
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  Obviously, I can't illustrate the lack of an error message, but GCC 8.1.0 compiles it with both -std=c++11 and -std=c++17
  
  – Neil Butterworth
  Jul 18 at 20:08
  

  
  
  
  

 | 
show 3 more comments

38

3

I fixed a bug recently.

In the following code, one of the overloaded function was const and the other one was not. The issue will be fixed by making both functions const.

My question is why compiler only complained about it when the parameter was 0.

#include <iostream>
#include <string>

class CppSyntaxA

public:
 void f(int i = 0) const i++; 
 void f(const std::string&)
;

int main()

 CppSyntaxA a;
 a.f(1); // OK
 //a.f(0); //error C2666: 'CppSyntaxA::f': 2 overloads have similar conversions
 return 0;

c++ overloading ambiguous-call

share|improve this question

edited Jul 23 at 22:40

Paulw11

73.7k1010 gold badges9595 silver badges111111 bronze badges

asked Jul 18 at 20:00

Cong MaCong Ma

60388 silver badges1616 bronze badges

• 
  
  
  

  
  3
  

  
  
  
  
  
  

  
  
  @NeilButterworth GCC shows the same behavior.
  
  – Miles Budnek
  Jul 18 at 20:05
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  @Miles No, it doesn't.
  
  – Neil Butterworth
  Jul 18 at 20:06
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  
  @NeilButterworth sure does: wandbox.org/permlink/mEtMFPt5KMdSVGs3 and wandbox.org/permlink/8UiG8XD7d0ol8U8v
  
  – Parsa
  Jul 18 at 20:06
  
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  clang seems happy with it for what that's worth.
  
  – tadman
  Jul 18 at 20:07
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  Obviously, I can't illustrate the lack of an error message, but GCC 8.1.0 compiles it with both -std=c++11 and -std=c++17
  
  – Neil Butterworth
  Jul 18 at 20:08
  

  
  
  
  

 | 
show 3 more comments

I fixed a bug recently.

In the following code, one of the overloaded function was const and the other one was not. The issue will be fixed by making both functions const.

My question is why compiler only complained about it when the parameter was 0.

#include <iostream>
#include <string>

class CppSyntaxA

public:
 void f(int i = 0) const i++; 
 void f(const std::string&)
;

int main()

 CppSyntaxA a;
 a.f(1); // OK
 //a.f(0); //error C2666: 'CppSyntaxA::f': 2 overloads have similar conversions
 return 0;

c++ overloading ambiguous-call

share|improve this question

edited Jul 23 at 22:40

Paulw11

73.7k1010 gold badges9595 silver badges111111 bronze badges

asked Jul 18 at 20:00

Cong MaCong Ma

60388 silver badges1616 bronze badges

#include <iostream>
#include <string>

class CppSyntaxA

public:
 void f(int i = 0) const i++; 
 void f(const std::string&)
;

int main()

 CppSyntaxA a;
 a.f(1); // OK
 //a.f(0); //error C2666: 'CppSyntaxA::f': 2 overloads have similar conversions
 return 0;

share|improve this question

edited Jul 23 at 22:40

Paulw11

73.7k1010 gold badges9595 silver badges111111 bronze badges

asked Jul 18 at 20:00

Cong MaCong Ma

60388 silver badges1616 bronze badges

share|improve this question

edited Jul 23 at 22:40

Paulw11

73.7k1010 gold badges9595 silver badges111111 bronze badges

asked Jul 18 at 20:00

Cong MaCong Ma

60388 silver badges1616 bronze badges

edited Jul 23 at 22:40

Paulw11

73.7k1010 gold badges9595 silver badges111111 bronze badges

edited Jul 23 at 22:40

Paulw11

73.7k1010 gold badges9595 silver badges111111 bronze badges

asked Jul 18 at 20:00

Cong MaCong Ma

60388 silver badges1616 bronze badges

asked Jul 18 at 20:00

Cong MaCong Ma

60388 silver badges1616 bronze badges

2 Answers
2

active

oldest

votes

51

0 is special in C++. A null pointer has the value of 0 so C++ will allow the conversion of 0 to a pointer type. That means when you call

a.f(0);

You could be calling void f(int i = 0) const with an int with the value of 0, or you could call void f(const std::string&) with a char* initialized to null.

Normally the int version would be better since it is an exact match but in this case the int version is const, so it requires "converting" a to a const CppSyntaxA, where the std::string version does not require such a conversion but does require a conversion to char* and then to std::string. This is considered enough of a change in both cases to be considered an equal conversion and thus ambiguous. Making both functions const or non const will fix the issue and the int overload will be chosen since it is better.

share|improve this answer

edited Jul 19 at 15:35

p.s.w.g

124k1919 gold badges221221 silver badges262262 bronze badges

answered Jul 18 at 20:07

NathanOliverNathanOliver

110k1919 gold badges166166 silver badges245245 bronze badges

• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  @FrançoisAndrieux Answer updated.
  
  – NathanOliver
  Jul 18 at 20:14
  

  
  
  
  


• 
  
  
  

  
  2
  

  
  
  
  
  
  

  
  
  @FrançoisAndrieux Don't worry, compiler implementers do as well ;)
  
  – NathanOliver
  Jul 18 at 20:21
  

  
  
  
  


• 
  
  
  

  
  4
  

  
  
  
  
  
  

  
  
  @JesperJuhl A null pointer, and nullptr are different things. A null pointer is an integer with the value of 0 along with also being a prvalue of nullptr_t.
  
  – NathanOliver
  Jul 18 at 20:32
  
  

  
  
  
  


• 
  
  
  

  
  2
  

  
  
  
  
  
  

  
  
  The most infuriating part of this overload issue is that it's UB to call the constructor of std::string with a null pointer :/
  
  – Matthieu M.
  Jul 19 at 7:17
  

  
  
  
  


• 
  
  
  

  
  4
  

  
  
  
  
  
  

  
  
  A null pointer has the value 0? That's a new one. It's implementation-defined what value it has, though as literal 0 can be implicitly converted to any null pointer type, it therefore will compare equal. (intptr_t)(void*)0 == 0 is not guaranteed, though holds on (most?) modern platforms. @JesperJuhl Seems you got off-track with nullptr.
  
  – Deduplicator
  Jul 19 at 8:06
  
  

  
  
  
  

 | 
show 6 more comments

10

My question is why compiler only complained about it when the parameter was 0.

Because 0 is not only an integer literal, but it is also a null pointer literal. 1 is not a null pointer literal, so there is no ambiguity.

The ambiguity arises from the implicit converting constructor of std::string that accepts a pointer to a character as an argument.

Now, the identity conversion from int to int would otherwise be preferred to the conversion from pointer to string, but there is another argument that involves a conversion: The implicit object argument. In one case, the conversion is from CppSyntaxA& to CppSyntaxA& while in other case it is CppSyntaxA& to const CppSyntaxA&.

So, one overload is preferred because of one argument, and the other overload is preferred because of another argument and thus there is no unambiguously preferred overload.

The issue will be fixed by making both functions const.

If both overloads are const qualified, then the implicit object argument conversion sequence is identical, and thus one of the overloads is unambiguously preferred.

share|improve this answer

answered Jul 18 at 20:12

eerorikaeerorika

102k66 gold badges8181 silver badges157157 bronze badges

add a comment | 

Your Answer

StackExchange.ifUsing("editor", function ()
StackExchange.using("externalEditor", function ()
StackExchange.using("snippets", function ()
StackExchange.snippets.init();
);
);
, "code-snippets");

StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "1"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);

else
createEditor();

);

function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);



);

draft saved

draft discarded

Sign up or log in

StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);

Sign up using Google

Sign up using Facebook

Sign up using Email and Password

Post as a guest

Name

Email

Required, but never shown

StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f57101872%2fliteral-0-being-a-valid-candidate-for-int-and-const-string-overloads-causes-a%23new-answer', 'question_page');

);

Post as a guest

Name

Email

Required, but never shown

51

0 is special in C++. A null pointer has the value of 0 so C++ will allow the conversion of 0 to a pointer type. That means when you call

a.f(0);

You could be calling void f(int i = 0) const with an int with the value of 0, or you could call void f(const std::string&) with a char* initialized to null.

Normally the int version would be better since it is an exact match but in this case the int version is const, so it requires "converting" a to a const CppSyntaxA, where the std::string version does not require such a conversion but does require a conversion to char* and then to std::string. This is considered enough of a change in both cases to be considered an equal conversion and thus ambiguous. Making both functions const or non const will fix the issue and the int overload will be chosen since it is better.

share|improve this answer

edited Jul 19 at 15:35

p.s.w.g

124k1919 gold badges221221 silver badges262262 bronze badges

answered Jul 18 at 20:07

NathanOliverNathanOliver

110k1919 gold badges166166 silver badges245245 bronze badges

• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  @FrançoisAndrieux Answer updated.
  
  – NathanOliver
  Jul 18 at 20:14
  

  
  
  
  


• 
  
  
  

  
  2
  

  
  
  
  
  
  

  
  
  @FrançoisAndrieux Don't worry, compiler implementers do as well ;)
  
  – NathanOliver
  Jul 18 at 20:21
  

  
  
  
  


• 
  
  
  

  
  4
  

  
  
  
  
  
  

  
  
  @JesperJuhl A null pointer, and nullptr are different things. A null pointer is an integer with the value of 0 along with also being a prvalue of nullptr_t.
  
  – NathanOliver
  Jul 18 at 20:32
  
  

  
  
  
  


• 
  
  
  

  
  2
  

  
  
  
  
  
  

  
  
  The most infuriating part of this overload issue is that it's UB to call the constructor of std::string with a null pointer :/
  
  – Matthieu M.
  Jul 19 at 7:17
  

  
  
  
  


• 
  
  
  

  
  4
  

  
  
  
  
  
  

  
  
  A null pointer has the value 0? That's a new one. It's implementation-defined what value it has, though as literal 0 can be implicitly converted to any null pointer type, it therefore will compare equal. (intptr_t)(void*)0 == 0 is not guaranteed, though holds on (most?) modern platforms. @JesperJuhl Seems you got off-track with nullptr.
  
  – Deduplicator
  Jul 19 at 8:06
  
  

  
  
  
  

 | 
show 6 more comments

51

0 is special in C++. A null pointer has the value of 0 so C++ will allow the conversion of 0 to a pointer type. That means when you call

a.f(0);

You could be calling void f(int i = 0) const with an int with the value of 0, or you could call void f(const std::string&) with a char* initialized to null.

Normally the int version would be better since it is an exact match but in this case the int version is const, so it requires "converting" a to a const CppSyntaxA, where the std::string version does not require such a conversion but does require a conversion to char* and then to std::string. This is considered enough of a change in both cases to be considered an equal conversion and thus ambiguous. Making both functions const or non const will fix the issue and the int overload will be chosen since it is better.

share|improve this answer

edited Jul 19 at 15:35

p.s.w.g

124k1919 gold badges221221 silver badges262262 bronze badges

answered Jul 18 at 20:07

NathanOliverNathanOliver

110k1919 gold badges166166 silver badges245245 bronze badges

• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  @FrançoisAndrieux Answer updated.
  
  – NathanOliver
  Jul 18 at 20:14
  

  
  
  
  


• 
  
  
  

  
  2
  

  
  
  
  
  
  

  
  
  @FrançoisAndrieux Don't worry, compiler implementers do as well ;)
  
  – NathanOliver
  Jul 18 at 20:21
  

  
  
  
  


• 
  
  
  

  
  4
  

  
  
  
  
  
  

  
  
  @JesperJuhl A null pointer, and nullptr are different things. A null pointer is an integer with the value of 0 along with also being a prvalue of nullptr_t.
  
  – NathanOliver
  Jul 18 at 20:32
  
  

  
  
  
  


• 
  
  
  

  
  2
  

  
  
  
  
  
  

  
  
  The most infuriating part of this overload issue is that it's UB to call the constructor of std::string with a null pointer :/
  
  – Matthieu M.
  Jul 19 at 7:17
  

  
  
  
  


• 
  
  
  

  
  4
  

  
  
  
  
  
  

  
  
  A null pointer has the value 0? That's a new one. It's implementation-defined what value it has, though as literal 0 can be implicitly converted to any null pointer type, it therefore will compare equal. (intptr_t)(void*)0 == 0 is not guaranteed, though holds on (most?) modern platforms. @JesperJuhl Seems you got off-track with nullptr.
  
  – Deduplicator
  Jul 19 at 8:06
  
  

  
  
  
  

 | 
show 6 more comments

0 is special in C++. A null pointer has the value of 0 so C++ will allow the conversion of 0 to a pointer type. That means when you call

a.f(0);

You could be calling void f(int i = 0) const with an int with the value of 0, or you could call void f(const std::string&) with a char* initialized to null.

Normally the int version would be better since it is an exact match but in this case the int version is const, so it requires "converting" a to a const CppSyntaxA, where the std::string version does not require such a conversion but does require a conversion to char* and then to std::string. This is considered enough of a change in both cases to be considered an equal conversion and thus ambiguous. Making both functions const or non const will fix the issue and the int overload will be chosen since it is better.

share|improve this answer

edited Jul 19 at 15:35

p.s.w.g

124k1919 gold badges221221 silver badges262262 bronze badges

answered Jul 18 at 20:07

NathanOliverNathanOliver

110k1919 gold badges166166 silver badges245245 bronze badges

a.f(0);

share|improve this answer

edited Jul 19 at 15:35

p.s.w.g

124k1919 gold badges221221 silver badges262262 bronze badges

answered Jul 18 at 20:07

NathanOliverNathanOliver

110k1919 gold badges166166 silver badges245245 bronze badges

edited Jul 19 at 15:35

p.s.w.g

124k1919 gold badges221221 silver badges262262 bronze badges

edited Jul 19 at 15:35

p.s.w.g

124k1919 gold badges221221 silver badges262262 bronze badges

answered Jul 18 at 20:07

NathanOliverNathanOliver

110k1919 gold badges166166 silver badges245245 bronze badges

answered Jul 18 at 20:07

NathanOliverNathanOliver

110k1919 gold badges166166 silver badges245245 bronze badges

10

My question is why compiler only complained about it when the parameter was 0.

Because 0 is not only an integer literal, but it is also a null pointer literal. 1 is not a null pointer literal, so there is no ambiguity.

The ambiguity arises from the implicit converting constructor of std::string that accepts a pointer to a character as an argument.

Now, the identity conversion from int to int would otherwise be preferred to the conversion from pointer to string, but there is another argument that involves a conversion: The implicit object argument. In one case, the conversion is from CppSyntaxA& to CppSyntaxA& while in other case it is CppSyntaxA& to const CppSyntaxA&.

So, one overload is preferred because of one argument, and the other overload is preferred because of another argument and thus there is no unambiguously preferred overload.

The issue will be fixed by making both functions const.

If both overloads are const qualified, then the implicit object argument conversion sequence is identical, and thus one of the overloads is unambiguously preferred.

share|improve this answer

answered Jul 18 at 20:12

eerorikaeerorika

102k66 gold badges8181 silver badges157157 bronze badges

add a comment | 

10

My question is why compiler only complained about it when the parameter was 0.

Because 0 is not only an integer literal, but it is also a null pointer literal. 1 is not a null pointer literal, so there is no ambiguity.

The ambiguity arises from the implicit converting constructor of std::string that accepts a pointer to a character as an argument.

Now, the identity conversion from int to int would otherwise be preferred to the conversion from pointer to string, but there is another argument that involves a conversion: The implicit object argument. In one case, the conversion is from CppSyntaxA& to CppSyntaxA& while in other case it is CppSyntaxA& to const CppSyntaxA&.

So, one overload is preferred because of one argument, and the other overload is preferred because of another argument and thus there is no unambiguously preferred overload.

The issue will be fixed by making both functions const.

If both overloads are const qualified, then the implicit object argument conversion sequence is identical, and thus one of the overloads is unambiguously preferred.

share|improve this answer

answered Jul 18 at 20:12

eerorikaeerorika

102k66 gold badges8181 silver badges157157 bronze badges

add a comment | 

My question is why compiler only complained about it when the parameter was 0.

Because 0 is not only an integer literal, but it is also a null pointer literal. 1 is not a null pointer literal, so there is no ambiguity.

The ambiguity arises from the implicit converting constructor of std::string that accepts a pointer to a character as an argument.

Now, the identity conversion from int to int would otherwise be preferred to the conversion from pointer to string, but there is another argument that involves a conversion: The implicit object argument. In one case, the conversion is from CppSyntaxA& to CppSyntaxA& while in other case it is CppSyntaxA& to const CppSyntaxA&.

So, one overload is preferred because of one argument, and the other overload is preferred because of another argument and thus there is no unambiguously preferred overload.

The issue will be fixed by making both functions const.

If both overloads are const qualified, then the implicit object argument conversion sequence is identical, and thus one of the overloads is unambiguously preferred.

share|improve this answer

answered Jul 18 at 20:12

eerorikaeerorika

102k66 gold badges8181 silver badges157157 bronze badges

share|improve this answer

answered Jul 18 at 20:12

eerorikaeerorika

102k66 gold badges8181 silver badges157157 bronze badges

answered Jul 18 at 20:12

eerorikaeerorika

102k66 gold badges8181 silver badges157157 bronze badges

answered Jul 18 at 20:12

eerorikaeerorika

102k66 gold badges8181 silver badges157157 bronze badges