Talk:cpp/language/implicit conversion

Example for temporary materialization part mentions some "A.m", which is not in the example.--Mmatrosov (talk) 03:27, 27 November 2016 (PST)

that was a poor way to say cpp/language/operator_member_access#Built-in_member_access_operators, edited --Cubbi (talk) 08:53, 27 November 2016 (PST)

The part on integral promotion is not completely true. According to the Integral promotions section of the standard (4.5.1):

"A prvalue of an integer type other than bool, char16_t, char32_t, or wchar_t whose integer conversion rank (4.13) is less than the rank of int can be converted to a prvalue of type int if int can represent all the values of the source type; otherwise, the source prvalue can be converted to a prvalue of type unsigned int."

Means that an unsigned char will first be converted to an (signed) int (as it can contain all values of an unsigned char), not as mentioned on the page, only to unsigned short.

192.109.190.88 04:06, 27 September 2013 (PDT) Troels Frimor

Yes, that was an error, thank you for bringing it up. --Cubbi (talk) 06:31, 27 September 2013 (PDT)

C multiple definition errors

In this article it is written "const char* const * p2 = p; // error in C, OK in C++", butthat's not true, I've tried gcc with c90 std and all warnings, it's legal Yanpas (talk) 00:25, 5 October 2016 (PDT)

You are either using some ancient buggy version of gcc or running your tests wrong. Regardless, we document the language as described by the standard, not as implemented by any particular compiler. T. Canens (talk) 01:44, 5 October 2016 (PDT)

"long" + "unsigned"

The text on the page mentions in section "Integral conversions" always a "destination type". That does not help me to decide the result type of an arithmetical expression, e.g. with "long" and "unsigned". :-(

I also compared this page with the according page for the C programming language, which is structured quite differently. Perhaps it would help when this page would emphasize the differences between C and C++, if any.

What about this graphical chart: http://eel.is/c++/resulttypes.png It does not correspond to the rules I found in the C standard e.g. for "long" + "unsigned".

--2003:89:E97C:DD00:A65E:60FF:FEC7:34A5 05:33, 13 June 2017 (PDT)

the destination type of an argument in an arithmetic expression is in cpp/language/operator_arithmetic#Conversions. The result type is determined by each operator individually. I suppose it's worth linking from there. --Cubbi (talk) 05:45, 13 June 2017 (PDT)

Thanks, yes that linking would be a good idea. It seems that the definition in C++ does not differ much from C. And the chart I mentioned is not exact, right? --2003:89:E97C:DD00:A65E:60FF:FEC7:34A5 12:25, 13 June 2017 (PDT)

Rename of section "Value transformations"

I would rename the section "Value transformations" within this page to "Lvalue Transformation" as the list of described transformation is (nearly) equal to the content of Table 13 in N4659 (Draft) in section [over.ics.scs] B166ER (talk) 20:36, 4 January 2018 (PST)

User-defined conversion

I'm confused about this paragraph:

"A user-defined conversion consists of zero or one non-explicit single-argument constructor or non-explicit conversion function call."

The "conversion function" call above has a link to a section whose title is "user-defined conversion". What is then the definition of a user-defined-conversion?

--Belloc (talk) 12:50, 24 May 2020 (PDT)

as the first sentence says, it's a conversion that considers cpp/language/converting_constructor and cpp/language/cast_operator. I've adjusted the title of the second page. --Cubbi (talk) 14:55, 26 May 2020 (PDT)

The sixth bullet in See also, named "user-defined-conversion" links to the page User-defined conversion function. Shouldn't the link then be named "user-defined conversion function" instead of "user-defined-conversion"? Belloc (talk) 13:11, 30 June 2020 (PDT)

Implicit conversion sequences

As far as I understand the following sentence is wrong and addresses a far more complex set of rules described in the C++ standards.

"When considering the argument to a constructor or to a user-defined conversion function, only a standard conversion sequence is allowed (otherwise user-defined conversions could be effectively chained)."

(Sadly I do not have the profound knowledge to fix that in an acceptable manner - or see my error in reasoning. I appreciated it if someone would take up the issue.) Gmork (talk) 06:57, 21 July 2020 (PDT)