Why is implicit conversion not ambiguous for non-primitive types?Can you use keyword explicit to prevent automatic conversion of method parameters?Why const for implicit conversion?Implicit conversion when overloading operators for template classesTemplate Constructor for Primitives, avoiding AmbiguityTemplate Type Deduction with Lambdasimplicit conversions from and to class typesConversion is ambiguous. Standard implicit conversion could not choose cast operatorGet type of implicit conversionImplicit conversion of stream to boolC++17: explicit conversion function vs explicit constructor + implicit conversions - have the rules changed?

Writing in a Christian voice

Strange behavior in TikZ draw command

Do native speakers use "ultima" and "proxima" frequently in spoken English?

How can I, as DM, avoid the Conga Line of Death occurring when implementing some form of flanking rule?

Capacitor electron flow

C++ lambda syntax

Why is participating in the European Parliamentary elections used as a threat?

Highest stage count that are used one right after the other?

What is the meaning of "You've never met a graph you didn't like?"

Why is implicit conversion not ambiguous for non-primitive types?

Asserting that Atheism and Theism are both faith based positions

Why does the frost depth increase when the surface temperature warms up?

Put the phone down / Put down the phone

How are passwords stolen from companies if they only store hashes?

Offset in split text content

How do you say "Trust your struggle." in French?

What is the purpose of using a decision tree?

What do the positive and negative (+/-) transmit and receive pins mean on Ethernet cables?

Travelling in US for more than 90 days

How to evaluate the research level of a paper before any publication?

How do I lift the insulation blower into the attic?

Why is "la Gestapo" feminine?

Why is indicated airspeed rather than ground speed used during the takeoff roll?

Exposing a company lying about themselves in a tightly knit industry (videogames) : Is my career at risk on the long run?



Why is implicit conversion not ambiguous for non-primitive types?


Can you use keyword explicit to prevent automatic conversion of method parameters?Why const for implicit conversion?Implicit conversion when overloading operators for template classesTemplate Constructor for Primitives, avoiding AmbiguityTemplate Type Deduction with Lambdasimplicit conversions from and to class typesConversion is ambiguous. Standard implicit conversion could not choose cast operatorGet type of implicit conversionImplicit conversion of stream to boolC++17: explicit conversion function vs explicit constructor + implicit conversions - have the rules changed?













7















Given a simple class template with multiple implicit conversion functions (non-explicit constructor and conversion operator), as in the following example:



template<class T>
class Foo

private:
T m_value;

public:
Foo();

Foo(const T& value):
m_value(value)



operator T() const
return m_value;


bool operator==(const Foo<T>& other) const
return m_value == other.m_value;

;

struct Bar

bool m;

bool operator==(const Bar& other) const
return false;

;

int main(int argc, char *argv[])

Foo<bool> a (true);
bool b = false;
if(a == b)
// This is ambiguous


Foo<int> c (1);
int d = 2;
if(c == d)
// This is ambiguous


Foo<Bar> e (Bartrue);
Bar f = false;
if(e == f)
// This is not ambiguous. Why?




The comparison operators involving primitive types (bool, int) are ambiguous, as expected - the compiler does not know whether it should use the conversion operator to convert the left-hand template class instance to a primitive type or use the conversion constructor to convert the right-hand primitive type to the expected class template instance.



However, the last comparison, involving a simple struct, is not ambiguous. Why? Which conversion function will be used?



Tested with compiler msvc 15.9.7.










share|improve this question






















  • The explicit keyword is a nice thing. You should research it.

    – Jesper Juhl
    2 hours ago











  • e == f will be ambiguous in C++20, for what its worth.

    – Barry
    2 hours ago















7















Given a simple class template with multiple implicit conversion functions (non-explicit constructor and conversion operator), as in the following example:



template<class T>
class Foo

private:
T m_value;

public:
Foo();

Foo(const T& value):
m_value(value)



operator T() const
return m_value;


bool operator==(const Foo<T>& other) const
return m_value == other.m_value;

;

struct Bar

bool m;

bool operator==(const Bar& other) const
return false;

;

int main(int argc, char *argv[])

Foo<bool> a (true);
bool b = false;
if(a == b)
// This is ambiguous


Foo<int> c (1);
int d = 2;
if(c == d)
// This is ambiguous


Foo<Bar> e (Bartrue);
Bar f = false;
if(e == f)
// This is not ambiguous. Why?




The comparison operators involving primitive types (bool, int) are ambiguous, as expected - the compiler does not know whether it should use the conversion operator to convert the left-hand template class instance to a primitive type or use the conversion constructor to convert the right-hand primitive type to the expected class template instance.



However, the last comparison, involving a simple struct, is not ambiguous. Why? Which conversion function will be used?



Tested with compiler msvc 15.9.7.










share|improve this question






















  • The explicit keyword is a nice thing. You should research it.

    – Jesper Juhl
    2 hours ago











  • e == f will be ambiguous in C++20, for what its worth.

    – Barry
    2 hours ago













7












7








7








Given a simple class template with multiple implicit conversion functions (non-explicit constructor and conversion operator), as in the following example:



template<class T>
class Foo

private:
T m_value;

public:
Foo();

Foo(const T& value):
m_value(value)



operator T() const
return m_value;


bool operator==(const Foo<T>& other) const
return m_value == other.m_value;

;

struct Bar

bool m;

bool operator==(const Bar& other) const
return false;

;

int main(int argc, char *argv[])

Foo<bool> a (true);
bool b = false;
if(a == b)
// This is ambiguous


Foo<int> c (1);
int d = 2;
if(c == d)
// This is ambiguous


Foo<Bar> e (Bartrue);
Bar f = false;
if(e == f)
// This is not ambiguous. Why?




The comparison operators involving primitive types (bool, int) are ambiguous, as expected - the compiler does not know whether it should use the conversion operator to convert the left-hand template class instance to a primitive type or use the conversion constructor to convert the right-hand primitive type to the expected class template instance.



However, the last comparison, involving a simple struct, is not ambiguous. Why? Which conversion function will be used?



Tested with compiler msvc 15.9.7.










share|improve this question














Given a simple class template with multiple implicit conversion functions (non-explicit constructor and conversion operator), as in the following example:



template<class T>
class Foo

private:
T m_value;

public:
Foo();

Foo(const T& value):
m_value(value)



operator T() const
return m_value;


bool operator==(const Foo<T>& other) const
return m_value == other.m_value;

;

struct Bar

bool m;

bool operator==(const Bar& other) const
return false;

;

int main(int argc, char *argv[])

Foo<bool> a (true);
bool b = false;
if(a == b)
// This is ambiguous


Foo<int> c (1);
int d = 2;
if(c == d)
// This is ambiguous


Foo<Bar> e (Bartrue);
Bar f = false;
if(e == f)
// This is not ambiguous. Why?




The comparison operators involving primitive types (bool, int) are ambiguous, as expected - the compiler does not know whether it should use the conversion operator to convert the left-hand template class instance to a primitive type or use the conversion constructor to convert the right-hand primitive type to the expected class template instance.



However, the last comparison, involving a simple struct, is not ambiguous. Why? Which conversion function will be used?



Tested with compiler msvc 15.9.7.







c++ templates c++17 implicit-conversion ambiguous






share|improve this question













share|improve this question











share|improve this question




share|improve this question










asked 2 hours ago









CybranCybran

1,047818




1,047818












  • The explicit keyword is a nice thing. You should research it.

    – Jesper Juhl
    2 hours ago











  • e == f will be ambiguous in C++20, for what its worth.

    – Barry
    2 hours ago

















  • The explicit keyword is a nice thing. You should research it.

    – Jesper Juhl
    2 hours ago











  • e == f will be ambiguous in C++20, for what its worth.

    – Barry
    2 hours ago
















The explicit keyword is a nice thing. You should research it.

– Jesper Juhl
2 hours ago





The explicit keyword is a nice thing. You should research it.

– Jesper Juhl
2 hours ago













e == f will be ambiguous in C++20, for what its worth.

– Barry
2 hours ago





e == f will be ambiguous in C++20, for what its worth.

– Barry
2 hours ago












2 Answers
2






active

oldest

votes


















10














According to [over.binary]/1




Thus, for any binary operator @, x@y can be interpreted
as either x.operator@(y) or operator@(x,y).




According to this rule, in the case of e == f, the compiler can only interpret it as e.operator==(f), not as f.operator==(e). So there is no ambiguity; the operator== you defined as a member of Bar is simply not a candidate for overload resolution.



In the case of a == b and c == d, the built-in candidate operator==(int, int) (see [over.built]/13) competes with the operator== defined as a member of Foo<T>.






share|improve this answer






























    2














    Operator overloads implemented as member functions don't allow for implicit conversion of their left hand side operand, which is the object on which they are called. It always helps to write down the explicit form of the operator overload to see what that means:



    Foo<Bar> e (Bartrue);
    Bar f = false;

    // Pretty explicit: call the member function Foo<Bar>::operator==
    if(e.operator ==(f)) /* ... */


    This can't be confused with the comparison operator in Bar, because it would require an implicit conversion of the left hand side operand, which is impossible. You can trigger an ambiguity similar to the ones you see with the builtin types when you define Bar and its comparison operator like this:



    struct Bar bool m; ;

    // A free function allows conversion, this will be ambigious:
    bool operator==(const Bar&, const Bar&)

    return false;



    This is nicely demonstrated and explained in Item 24, Scott Meyers, Effective C++.






    share|improve this answer
























      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


















      StackExchange.ready(
      function ()
      StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f55249017%2fwhy-is-implicit-conversion-not-ambiguous-for-non-primitive-types%23new-answer', 'question_page');

      );

      Post as a guest















      Required, but never shown

























      2 Answers
      2






      active

      oldest

      votes








      2 Answers
      2






      active

      oldest

      votes









      active

      oldest

      votes






      active

      oldest

      votes









      10














      According to [over.binary]/1




      Thus, for any binary operator @, x@y can be interpreted
      as either x.operator@(y) or operator@(x,y).




      According to this rule, in the case of e == f, the compiler can only interpret it as e.operator==(f), not as f.operator==(e). So there is no ambiguity; the operator== you defined as a member of Bar is simply not a candidate for overload resolution.



      In the case of a == b and c == d, the built-in candidate operator==(int, int) (see [over.built]/13) competes with the operator== defined as a member of Foo<T>.






      share|improve this answer



























        10














        According to [over.binary]/1




        Thus, for any binary operator @, x@y can be interpreted
        as either x.operator@(y) or operator@(x,y).




        According to this rule, in the case of e == f, the compiler can only interpret it as e.operator==(f), not as f.operator==(e). So there is no ambiguity; the operator== you defined as a member of Bar is simply not a candidate for overload resolution.



        In the case of a == b and c == d, the built-in candidate operator==(int, int) (see [over.built]/13) competes with the operator== defined as a member of Foo<T>.






        share|improve this answer

























          10












          10








          10







          According to [over.binary]/1




          Thus, for any binary operator @, x@y can be interpreted
          as either x.operator@(y) or operator@(x,y).




          According to this rule, in the case of e == f, the compiler can only interpret it as e.operator==(f), not as f.operator==(e). So there is no ambiguity; the operator== you defined as a member of Bar is simply not a candidate for overload resolution.



          In the case of a == b and c == d, the built-in candidate operator==(int, int) (see [over.built]/13) competes with the operator== defined as a member of Foo<T>.






          share|improve this answer













          According to [over.binary]/1




          Thus, for any binary operator @, x@y can be interpreted
          as either x.operator@(y) or operator@(x,y).




          According to this rule, in the case of e == f, the compiler can only interpret it as e.operator==(f), not as f.operator==(e). So there is no ambiguity; the operator== you defined as a member of Bar is simply not a candidate for overload resolution.



          In the case of a == b and c == d, the built-in candidate operator==(int, int) (see [over.built]/13) competes with the operator== defined as a member of Foo<T>.







          share|improve this answer












          share|improve this answer



          share|improve this answer










          answered 2 hours ago









          BrianBrian

          65.6k797186




          65.6k797186























              2














              Operator overloads implemented as member functions don't allow for implicit conversion of their left hand side operand, which is the object on which they are called. It always helps to write down the explicit form of the operator overload to see what that means:



              Foo<Bar> e (Bartrue);
              Bar f = false;

              // Pretty explicit: call the member function Foo<Bar>::operator==
              if(e.operator ==(f)) /* ... */


              This can't be confused with the comparison operator in Bar, because it would require an implicit conversion of the left hand side operand, which is impossible. You can trigger an ambiguity similar to the ones you see with the builtin types when you define Bar and its comparison operator like this:



              struct Bar bool m; ;

              // A free function allows conversion, this will be ambigious:
              bool operator==(const Bar&, const Bar&)

              return false;



              This is nicely demonstrated and explained in Item 24, Scott Meyers, Effective C++.






              share|improve this answer





























                2














                Operator overloads implemented as member functions don't allow for implicit conversion of their left hand side operand, which is the object on which they are called. It always helps to write down the explicit form of the operator overload to see what that means:



                Foo<Bar> e (Bartrue);
                Bar f = false;

                // Pretty explicit: call the member function Foo<Bar>::operator==
                if(e.operator ==(f)) /* ... */


                This can't be confused with the comparison operator in Bar, because it would require an implicit conversion of the left hand side operand, which is impossible. You can trigger an ambiguity similar to the ones you see with the builtin types when you define Bar and its comparison operator like this:



                struct Bar bool m; ;

                // A free function allows conversion, this will be ambigious:
                bool operator==(const Bar&, const Bar&)

                return false;



                This is nicely demonstrated and explained in Item 24, Scott Meyers, Effective C++.






                share|improve this answer



























                  2












                  2








                  2







                  Operator overloads implemented as member functions don't allow for implicit conversion of their left hand side operand, which is the object on which they are called. It always helps to write down the explicit form of the operator overload to see what that means:



                  Foo<Bar> e (Bartrue);
                  Bar f = false;

                  // Pretty explicit: call the member function Foo<Bar>::operator==
                  if(e.operator ==(f)) /* ... */


                  This can't be confused with the comparison operator in Bar, because it would require an implicit conversion of the left hand side operand, which is impossible. You can trigger an ambiguity similar to the ones you see with the builtin types when you define Bar and its comparison operator like this:



                  struct Bar bool m; ;

                  // A free function allows conversion, this will be ambigious:
                  bool operator==(const Bar&, const Bar&)

                  return false;



                  This is nicely demonstrated and explained in Item 24, Scott Meyers, Effective C++.






                  share|improve this answer















                  Operator overloads implemented as member functions don't allow for implicit conversion of their left hand side operand, which is the object on which they are called. It always helps to write down the explicit form of the operator overload to see what that means:



                  Foo<Bar> e (Bartrue);
                  Bar f = false;

                  // Pretty explicit: call the member function Foo<Bar>::operator==
                  if(e.operator ==(f)) /* ... */


                  This can't be confused with the comparison operator in Bar, because it would require an implicit conversion of the left hand side operand, which is impossible. You can trigger an ambiguity similar to the ones you see with the builtin types when you define Bar and its comparison operator like this:



                  struct Bar bool m; ;

                  // A free function allows conversion, this will be ambigious:
                  bool operator==(const Bar&, const Bar&)

                  return false;



                  This is nicely demonstrated and explained in Item 24, Scott Meyers, Effective C++.







                  share|improve this answer














                  share|improve this answer



                  share|improve this answer








                  edited 1 hour ago

























                  answered 2 hours ago









                  lubgrlubgr

                  13.8k32052




                  13.8k32052



























                      draft saved

                      draft discarded
















































                      Thanks for contributing an answer to Stack Overflow!


                      • Please be sure to answer the question. Provide details and share your research!

                      But avoid


                      • Asking for help, clarification, or responding to other answers.

                      • Making statements based on opinion; back them up with references or personal experience.

                      To learn more, see our tips on writing great answers.




                      draft saved


                      draft discarded














                      StackExchange.ready(
                      function ()
                      StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f55249017%2fwhy-is-implicit-conversion-not-ambiguous-for-non-primitive-types%23new-answer', 'question_page');

                      );

                      Post as a guest















                      Required, but never shown





















































                      Required, but never shown














                      Required, but never shown












                      Required, but never shown







                      Required, but never shown

































                      Required, but never shown














                      Required, but never shown












                      Required, but never shown







                      Required, but never shown







                      Popular posts from this blog

                      acmart: Multiple authors: all with same affiliation, one author an additional affiliationHow to Write Names of Multiple Authors with Shared Affiliation in ACM 2017 Template?Multiple authors with different primary affiliation, but same additional affiliationSame affiliation for all authors without extra packagesIOS-Book-Article.cls: one author with multiple affiliationacmart: Shared Author AffiliationMultiple authors with different primary affiliation, but same additional affiliationAuthor affiliation with only 1 authorAdding Multiple Authors with Different Affiliation in LaTeX ArticleLaTeX: Multiple authors stays on same lineHow to Label Multiple Authors with Same DescriptionHow to make two authors use the same affiliationTwo authors with same affiliation on finished front page

                      How to write “ä” and other umlauts and accented letters in bibliography?Accents in BibTeXSorting references with special characters alphabeticallyUse ae ligature in bibliographyEastern European nameInverted circumflex in BibTexBibTex, non-ascii initials and nameptr fproblems with accent in LatexHow to add a Ø to my bibliography from Jabref?References without accentsTroubles when trying to cite St“omer-Verlet in ”title" field of a bib entryComprehensive list of accented charactersHow to type the letter “i” with two dots (diaeresis) in math mode?Problem with glossary text and accented lettersSpecial character in bibliographyAccented letters, Unicode and LaTeX accentsHow to stop natbib from modifying bibliography styleCitation of a paper with non-standard characters by BibtexWrite accented characters to file using writeHow to group the bibliography alphabetically, if some surnames start with “accented” characters?How can I automatically capitalize significant words in my bibliography?

                      Problem using RevTeX4-1 with “! Undefined control sequence. @bibitemShut”