Content deleted Content added
WikiProject assessment |
m Reverted edits by 102.91.4.155 (talk) to last version by Afernand74 |
||
| (37 intermediate revisions by 25 users not shown) | |||
Line 1:
{{Talk header}}
{{WikiProject banner shell|class=C|1=
{{WikiProject Computing
{{WikiProject C/C++|class=Start|importance=Top|c=yes|c++=yes}}
}}
Line 8:
came here looking for the exponentiation operator, did not find. Apparently there isn't one, so I shall do it with bit munging. A note here to the effect that one must use a function for exponentiation would improve the value of this page as a reference. <span style="font-size: smaller;" class="autosigned">—Preceding [[Wikipedia:Signatures|unsigned]] comment added by [[Special:Contributions/108.16.83.48|108.16.83.48]] ([[User talk:108.16.83.48|talk]]) 20:15, 27 January 2011 (UTC)</span><!-- Template:UnsignedIP --> <!--Autosigned by SineBot-->
There is no exponentiation operator in c++ because ^ and the other usual ones are taken. One needs to use the function pow(BASE,EXPONENT). <span style="font-size: smaller;" class="autosigned">— Preceding [[Wikipedia:Signatures|unsigned]] comment added by [[Special:Contributions/129.69.39.34|129.69.39.34]] ([[User talk:129.69.39.34|talk]]) 09:46, 19 February 2014 (UTC)</span><!-- Template:Unsigned IP --> <!--Autosigned by SineBot-->
==Prototypes==
Line 54 ⟶ 57:
:I was just looking for the C operators and precedences. This combined page is an absurdity and downright user hostile. It's 90% of stuff I'm not interested in but have to wade through to find what I am looking for. Needle. Haystack. Puh-leaze make this two separate pages. Thank you! --[[Special:Contributions/80.246.32.33|80.246.32.33]] ([[User talk:80.246.32.33|talk]]) 09:06, 17 July 2012 (UTC)
: Agreed on separate articles. As a C programmer most of this is really hard to parse. [[Special:Contributions/174.21.162.147|174.21.162.147]] ([[User talk:174.21.162.147|talk]]) 02:47, 16 April 2015 (UTC)
:bc they are mostly the same. I cringe when folks cringe at lumping C and C++ together. We do it since it makes sense! but... (and as they say on GoT, you can ignore everything before but :)) why does this article exist? WP is not a programming manual! Delete this article. [[User:Stevebroshar|Stevebroshar]] ([[User talk:Stevebroshar|talk]]) 13:34, 30 January 2025 (UTC)
==order of operations==
Line 172 ⟶ 178:
--[[User:Der schiefe Turm|Der schiefe Turm]] ([[User talk:Der schiefe Turm|talk]]) 17:04, 16 September 2009 (UTC)
:What Derek said. In C, the result of a conditional expression (or ternary expression) is an rvalue even if both the second and third operand are lvalues. <
::I have to insist: 'gcc (GCC) 3.4.6' compiles with the warning above!!! So if the ternary operator should expand to an rvalue, please show me where to find that in the standards. Anyway, I think this tiny detail only blurs the original message, so here is my proposal: If we change the sample code to "e = a ? b++ : b = d;", C compiler will stop with an error (postfix++ resolves to an rvalue). Plus: Now the code's goal is easier to understand: Either increment, or assign some value! I think there is nothing wrong with me rewriting the section, our discussion whether or not the current version results in an error does not conflict with the improvement. ;-) --[[User:Der schiefe Turm|Der schiefe Turm]] ([[User talk:Der schiefe Turm|talk]]) 15:08, 23 September 2009 (UTC)
:::It's a footnote in Section 6.5.15, as seen [http://www.google.no/search?q=%22A+conditional+expression+does+not+yield+an+lvalue.%22 here]. It's also highlighted in Annex C of the C++ Standard as one of the differences between C++ and C. <
::::THNX! --[[User:Der schiefe Turm|Der schiefe Turm]] ([[User talk:Der schiefe Turm|talk]]) 20:15, 23 September 2009 (UTC)
The explanation about parsing "e = a < d ? a++ : a = d" is incorrect. In C, it is not parsed as "(a < d ? a++ : a) = d" but just a syntax error; this is because the standard grammar for the assignment expression is
<
unary-expression assignment-operator assignment-exression
</syntaxhighlight>
and the conditional expression cannot match to "unary-expression." Most compilers (especially with recursive-descent parsers) modify the grammar by replacing "unary-expression" with "conditional-expression" to avoid back-tracking or look-ahead or to handle errors gracefully, and thereof the syntactic error turns into a semantic one saying that the left operand of "=" or "op=" should be an lvalue. Which is why many people mistake the error for the semantic error. --[[User:Woong.jun|Woong.jun]] ([[User talk:Woong.jun|talk]]) 11:43, 15 March 2010 (UTC)
Line 197 ⟶ 203:
:The keyword '''typeof''' is a non-standard extension to the C++ language. A similar feature will be provided by the '''decltype''' keyword in [[C++0x]]. The '''throw''' keyword is a standard part of the C++ language. That said, not all keywords are operators, and I am fairly certain that neither '''decltype''' nor '''throw''' would be considered to be operators. ← <span style="font-family: serif;"><b>[[User:Michael Safyan|Michael Safyan]]</b></span><sup> ([[User talk:Michael Safyan|talk]])</sup> 02:17, 8 May 2008 (UTC)
::It's a bit confusing, but while [[decltype]] is not explicitly referred to as an operator in the WP, the term "<
: "throw" behaves as any other operator, except that it returns void type. The conditional operator has a special case for one operand being a throw-expression, such that "false? 3 : throw xyz()" is an expression of type int that never completes evaluation. [[User:Potatoswatter|Potatoswatter]] ([[User talk:Potatoswatter|talk]]) 09:43, 15 June 2010 (UTC)
Line 215 ⟶ 221:
I see that once again "this" has been removed. Even if technically not an operator, I think it should be here somehow, because I think many will try to find it here. At least could we have a discussion about it instead of an edit war. [[User:SimonTrew|SimonTrew]] ([[User talk:SimonTrew|talk]]) 17:34, 27 February 2009 (UTC)
:Yes, I considered adding a comment on the talk page. But I felt that my edit comment would be enough to settle the issue: '''''removed "this" from the table, per [class.this]/1 of the standard'''''. <
::Yeah I was kinda thinking the same myself. But actually I am coming round to your opinion and wonder if it is justified at all in this article, it's not difficult to search for. I'm just quite a fan of making cross-references, I think that is part of what gives Wikipedia its value. [[User:SimonTrew|SimonTrew]] ([[User talk:SimonTrew|talk]]) 06:57, 28 February 2009 (UTC)
Line 284 ⟶ 290:
:This reflects the fact that the operators previously were all in one continuous table. I only split them apart on account of the {{code|1===section headings==}}, as while making other additions I realized a section which starts mid-table cannot provide a meaningful edit preview. I might re-write all of this from scratch in a week or two but I’m busy at the moment. For one, I’d like to reduce the width of the “yes”/“no” cells, combine the member vs. global operator prototypes into one cell, among other things. I’d also like to discuss common overloading paradigms but perhaps a separate article would be appropriate for that. ―[[User talk:AoV2|AoV²]] 22:35, 20 April 2010 (UTC)
::..So, it's okay to remove the column, right? And for "included in C"? ᛭ [[User:LokiClock|LokiClock]] ([[User talk:LokiClock|talk]]) 03:59, 15 May 2010 (UTC)
::: Even after 10 years, I'd favour to remove redundant "all yes" columns and replace them by a small text between sub-heading and table, as suggested by User:LokiClock. --[[User:RokerHRO|RokerHRO]] ([[User talk:RokerHRO|talk]]) 20:56, 5 February 2021 (UTC)
== Overload prototypes ==
There's no indication of what the type "R" means. [[User:OrangeDog|OrangeDog]]
== Compound literals missing ==
Line 302 ⟶ 310:
For example:
<
void foo (int count)
{
Line 308 ⟶ 316:
//Now do something here.
}
</syntaxhighlight>
== Notes ==
Line 314 ⟶ 322:
From [[Operators_in_C_and_C%2B%2B#Notes]]:
"* For example, <code>++x*3</code> is ambiguous without some precedence rule(s). The precedence table tells us that: <
<s>This looks like it is saying that <code>++x*3</code> is equivalent to <code>(++x, x*3)</code>. Which is incorrect: with the comma operator, the arguments can be evaluated in any order.</s>
Line 335 ⟶ 343:
:No. Since binary operator always returns a result without changing one of the operands, this result is saved and returned via temp variable. Since you cannot return reference to temp variable :you should do it by value <span style="font-size: smaller;" class="autosigned">— Preceding [[Wikipedia:Signatures|unsigned]] comment added by [[Special:Contributions/2.94.232.187|2.94.232.187]] ([[User talk:2.94.232.187|talk]]) 16:08, 9 November 2012 (UTC)</span><!-- Template:Unsigned IP --> <!--Autosigned by SineBot-->
== User-defined literals ==
What about this one ? (New in C++11)
Declaration is like :
int operator"" _stuff ( int val);
And use would be : int x = 36_stuff;
[[User:Doom Oo7|Doom Oo7]] ([[User talk:Doom Oo7|talk]]) 09:27, 23 August 2013 (UTC)
== const-correctness ==
As noted above, this page is a heavily used reference.
Some time ago someone removed all const-correctness from the prototype references. Why was that? Can we get it back? Because unless something fundamental changed about C++ recently it is technically deficient now. (And trying to fix const errors when people are overloading operators for the first time is frustrating enough already on C++ forums without them coming to Wikipedia and finding contradictory information.)
[[User:Duoas|Duoas]] ([[User talk:Duoas|talk]]) 22:06, 6 May 2014 (UTC)
== Wrong operator precedence with ternary- and assign-operator ==
The precedence table says that the ternary-operator has higher precedence than the assign-operator, so "a ? b : c = 1" should be evaluated like "(a ? b : c) = 1". In reality it is evaluated like "a ? b : (c = 1)". So the precedence table looks wrong.
See:
http://stackoverflow.com/questions/7499400/ternary-conditional-and-assignment-operator-precedence
and
http://en.cppreference.com/w/cpp/language/operator_precedence <small class="autosigned">— Preceding [[Wikipedia:Signatures|unsigned]] comment added by [[Special:Contributions/2.244.33.171|2.244.33.171]] ([[User talk:2.244.33.171|talk]]) 20:36, 15 June 2015 (UTC)</small><!-- Template:Unsigned IP --> <!--Autosigned by SineBot-->
:Done. [[User:ZBalling|ZBalling]] ([[User talk:ZBalling|talk]]) 09:21, 22 September 2019 (UTC)
== Include uses of operators ==
I searched through this article but found that there was no column for the usage and the logical purpose of these operators. Maybe I will include them in a new column.[[User:Debanshu.Das|Debanshu.Das]] ([[User talk:Debanshu.Das|talk]]) 04:55, 4 August 2020 (UTC)
:No, there is no place for that. [[Special:Contributions/109.252.94.59|109.252.94.59]] ([[User talk:109.252.94.59|talk]]) 02:38, 16 January 2021 (UTC)
== I'd remove the scope resolution "operator" ==
Albeit it might look like an operator, and many other sources list it as operator, it is ''not'' an operator, because it does not combine two arbitrary expressions to create a new one. Instead it combines two ''names'' or ''identifiers'' to form a new (function, type or variable) name. So it works completely on another level at compile-time only.
And, of course, as a name-building token it has no "associativity", because a name <code>A::B::C</code> cannot be written neither as <code>(A::B)::C</code> – that would be a C-style typecast – nor as <code>A::(B::C)</code> – that would be a syntax error. --[[User:RokerHRO|RokerHRO]] ([[User talk:RokerHRO|talk]]) 21:04, 5 February 2021 (UTC)
== Should the increment/decrement operators be considered assignment operators? ==
Given that
<code>a++;</code>
''changes the objects internal value'' and is equivalent to
<code>a+=1;</code>
for numerical objects, shouldn't the increment/decrement operators be considered assignment operators? [[Special:Contributions/80.62.116.42|80.62.116.42]] ([[User talk:80.62.116.42|talk]]) 07:45, 17 October 2022 (UTC)
== Remove trigraphs ==
Why mention ??!= along with |= or ??( along with < ? These ??-trigraphs are meant to represent characters such as | and < when they are not available in the code page of the hardware. This replacement is ALWAYS done by the preprocessor, not just in operators. -- [[User:Wassermaus|Wassermaus]] ([[User talk:Wassermaus|talk]]) 22:32, 26 October 2023 (UTC)
:At first, this article only mentioned the alternative keyword representations (like <code>or</code>). So, for consistency, I added digraphs since they were added to the standards at the same time and for the same reason. However, adding digraphs but not trigraphs also seemed inconsistent since they can both be used to represent the operators. <code>a??(0??)</code> and <code>a<:0:></code> mean exactly the same thing despite the former being just <code>a[0]</code> after the preprocessor and the latter using alternartive tokens with the same meaning. To a programmer using them it's a distinction without a difference. In addition, <code>a or b</code> is implemented as a keyword in C++ and as a macro in C. So, I argue that there is precedent to adding preprocessor substitutions to the list. And lastly, as you correctly said, trigraphs can also appear outside operators. However, that's also true for the keywords since in e.g. the declaration <code>int and a = 0;</code> the <code>and</code> is not an operator. [[User:Nickps|Nickps]] ([[User talk:Nickps|talk]]) 09:25, 27 October 2023 (UTC)
::After noticing that I still missed some digraphs and trigraphs on the conversion operators i.e.<code>R<%a%></code> and <code>R??<a??></code> plus the ones with <code>auto</code>, I realised the whole thing is pointless and removed all alternative spellings. If anyone disagrees they are free to revert but I don't think it's worth it. My argument above still stands which is why I also removed the operator synonyms like <code>and</code>. [[User:Nickps|Nickps]] ([[User talk:Nickps|talk]]) 22:54, 8 May 2024 (UTC)
== Is <code>decltype</code> an operator? ==
The C23 standard adds the operators <code>typeof</code> and <code>typeof_unqual</code> and refers to them as operators by name (ISO/IEC 9899/2023 6.7.2.5 Typeof specifiers says: "The typeof and typeof_unqual tokens are collectively called the typeof operators.") While neither operator is in C++ yet, they will almost certainly be added to C++26 for compatibility and the proposal that does so, [https://wg21.link/p2958 p2958], groups them together with <code>decltype</code>, which makes sense. However, I can't find any source that refers to <code>decltype</code> as an "operator". In the [[decltype]] page one of the references is called [http://msdn.microsoft.com/en-us/library/dd537655(VS.100,loband).aspx decltype operator], but that name has since been changed to "decltype Type Specifier". (EDIT: Some examples of the phrase "decltype operator" I found: [https://github.com/MicrosoftDocs/cpp-docs/blob/main/docs/cpp/decltype-cpp.md] [https://docwiki.embarcadero.com/RADStudio/Alexandria/en/Type_Specifier_decltype_(C%2B%2B11)] and [https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2343.pdf the original paper that proposed it]. I think the fact that the people who defined decltype in the first place called it an operator is enough to settle the question, but I'll leave this here in case someone disagrees. --19:42, 30 October 2023 (UTC))
So, the question is: Should <code>decltype</code> be added to the list of operators? My opinion is that it should, since it does basically the same thing as the typeof operators, so I will be adding it to the page for consistency, but feel free to revert if you can come up with a good counterargument. [[User:Nickps|Nickps]] ([[User talk:Nickps|talk]]) 18:07, 30 October 2023 (UTC)
== Is it 4 or 6? ==
WRT "...all four relational operators are automatically generated if operator<=> is defined": There are 6 relational operators other than <=>. Either the text should say six instead of four or should list the 4 that it refers to. [[User:Stevebroshar|Stevebroshar]] ([[User talk:Stevebroshar|talk]]) 13:22, 31 January 2025 (UTC)
== Is this a list operators? or everything one can say about operators? ==
Considering that this article is described as a list of operators, the section '''Expression evaluation order''' seems out of place. It used to be named '''operator precedence''', but I renamed it since it covers more than precedence. Maybe originally it was only about precedence and then someone added associativity which changed the section to be more general: covering evaluation order. Scope creep! Whatever. Regardless, this section does not seem to be covered as part of a list of operators. It should be removed from this article or the intro should say this is all about C/C++ operators; not a list of operators. [[User:Stevebroshar|Stevebroshar]] ([[User talk:Stevebroshar|talk]]) 15:16, 31 January 2025 (UTC)
| |||