This is the
talk page for discussing improvements to the
Operators in C and C++ article. This is not a forum for general discussion of the article's subject. |
Article policies
|
Find sources: Google ( books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL |
![]() | This article is rated C-class on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | |||||||||||||||||||||||||||||
|
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. —Preceding unsigned comment added by 108.16.83.48 ( talk) 20:15, 27 January 2011 (UTC)
There is no exponentiation operator in c++ because ^ and the other usual ones are taken. One needs to use the function pow(BASE,EXPONENT). — Preceding
unsigned comment added by
129.69.39.34 (
talk) 09:46, 19 February 2014 (UTC)
The prototype column horribly esoteric. It needs its own explanation.
--
I agree that it's esoteric, but I don't think it needs explanation: the whole column needs to be removed completely. It's completely redundant.
I think its content is highly inappropriate for Wikipedia, and if you're looking for more useful information (like what the h-ll the operators actually mean), you'll end up using Google, anyway.
Similar to the comment below, I suggest that we replace the prototype column with another column that briefly describes what the operator actually does.
121.210.170.141 ( talk) 06:40, 19 November 2009 (UTC)
The prototype column should be corrected, then it would be very usefull. For example, a prototype for an assignment operator that returns a type R!=T, where T is the type of the calling object is a wrong prototype. The build-in assignment operator returns a reference to the left-hand side operator, which has particular effects. Overloaded operators should implement an analogous interface. Therefore, it worths if the column prototypes describe the interface of the build-in operators. Actually, that was the approach of an older version of the page. Why it has changed? Actually, we are allowed to overload an operator with no restriction, eg. we can overload operator= as a void but such an approach would cause confusion to the application programmer who should cope with various behaviors of assignment operation — Preceding unsigned comment added by Lefteris.moussiades ( talk • contribs) 18:20, 11 December 2012 (UTC)
Hi. I wonder if it might be useful to describe what some of these operators do. I'm not familiar, for example, with the comma (',') operator, and it would be neat to know what it does.
Well, it is hard to put that stuff in the table, but I agree it would be nice to have links or something. For what it is worth though, the comma operator is not very important. The most common place it is used is in for statements, for ( ix=0, jx=0; ix < t; ix++ ){}. Do you see the comma? It means, "evaluate the expression to the left, now go on and evaluate the expression to the right". The final value is the value of the last expression (ignored in this very typical case). It is different than commas in function calls because, for one thing, terms there are evaluated right to left. Also note that, at least in this case, there is another way to write this without commas: jx=0; for (ix=0; ix < t; ix++){}. AJim 01:34, 16 May 2004 (UTC)
Why have C and C++ operators been lumped into one article? It would be less confusing to have separate articles for each. Eric119 00:12, 1 May 2005 (UTC)
This page needs an order of operations. I'll probably put it on here. 67.161.46.169 09:42, 27 December 2005 (UTC)
I think this section needs to be moved to just before notes. It interferes with the first paragraph which is describing the tables following the order section. —Preceding unsigned comment added by 121.44.233.63 ( talk) 07:04, 14 April 2008 (UTC)
Someone needs to add the ! operator to the precedence table. I'd love to know where it goes because I've odd behavior with it. Retep998 ( talk) 04:58, 27 December 2010 (UTC)
Can the reference operator really be overloaded? I'm fairly sure it can't.... Not sure where to look, though. 68.238.86.68 21:50, 29 May 2006 (UTC)
I just removed this sentance:
Those operators that are in C are also in Java, Perl, C#, and PHP with the same precedence, associativity, and semantics.
From the article. I'm happy for something similar to go back in, but as it stands it is not true, as for example the comma operator, which is in C, is not in java or C#. Mrjeff 14:55, 4 June 2006 (UTC)
It's also the case that PHP's ?: operator has the "wrong" associativity. I don't think the article on C operators should really be making claims about other languages at all, but if it does it should be correct. — Preceding unsigned comment added by Amalloy ( talk • contribs) 22:29, 18 August 2011 (UTC)
This article seems to be suffering the line of reasoning that "C is a programming language. C++ is a programming language. Thus, C and C++ are the same." (and all other programming languages are affected by this logic too). The issue with lumping C and C++ into the same article is that C++ diverged from C long before the standardisation if C. Once C was standardised, things started to change. If the editors can't understand that, then this article will always be of poor quality. 123.200.203.23 ( talk) 01:02, 26 August 2011 (UTC)
I don't know the answer to this question, but it seems like a useful thing to be in this article, if someone else knows. The C-style cast operator (type)
is in the table, but what about the special C++ cast operators static_cast<type>()
, dynamic_cast<type>()
, reinterpret_cast<type>()
, and const_cast<type>()
?
safe_cast<type>()
, it's not official C++ but it's widely used with .Net productions and is important for .net optimization. I personally dislike .net very much but for completeness sake, it's used and recommended.
Wiseguy12851 (
talk) 20:36, 2 April 2010 (UTC)
The scope operator in C++ is different from the other operators, I think. Even if it is mentioned as an operator in some parts of the C++ standard it does not behave like an operator but as an token (or name) joiner. I.e. you cannot put parentheses around to change the order of evaluation: if A::B::C
is a valid expression, (A::B)::C
has a different meaning (a C-style type cast) and A::(B::C)
is a syntax error. What do you think, should we mention this special behavior of the "operator" ::
? --
89.55.168.117 10:46, 21 July 2006 (UTC) (
de:Benutzer:RokerHRO)
Recently, there was a revert to remove the Label Value Operator && from the list of C/C++ operators. While it is true that the operator is not at all standard ISO C/C++, it is a non-standard extension to some dialects, one of which is documented here. This raises the question of whether or not there should be a seperate table for operators sometimes seen as extensions to the language. I mean, such operators aren't C/C++, but they might still be of interest to some programmers. Maybe another page would be good? Extended operators? -- Cgranade 08:04, 12 October 2006 (UTC)
Not many operators get added as extensions (slight changes in existing operator semantics are more common), so added a new subsection to the table. See how things develop. Derek farn 08:32, 12 October 2006 (UTC)
I don't get this. Why include some non-standard operator that is not found in most compilers? There is already a standard label: statement (not operator) that should be compatible with all compilers. - Andrew flame him | stalk him 23:53, 14 July 2007 (UTC)
A recent edit made a large number of changes to this article, none of which I feel contribute positively to its content. That's just my opinion, but I did revert them; here is my reasoning:
a
, b
, and c
as used in the table do not just represent "valid values": depending upon context, they might be object names or lvalues, as well.&
, <
, and >
should never be entered directly into HTML. Use the character entities instead: &
, <
, and >
, respectively.I'm not going to defend the article like a hawk, but I would like to see some discussion rather than a total reversion.— Kbolino 03:49, 22 February 2007 (UTC)
The title says it all - in the article about associativity which is linked from this article, there are two terms defined: "left-associative" and "right-associative". But in this article, "left-ro-right" and "right-to-left" is used. That's inconsistent. I think that "left-to-right" probably corresponds to "left-associative" and the same for right, but thinking is not knowing. If so, maybe a middle-way correction could be good ("left-associative (left-to-right)"), since "left-to-right" is more intuitive name that "left-associative", so I think we should keep both namings. What do you think?
a & b == 7
means
a & (b == 7) ,
while
a + b == 7
means
(a + b) == 7 .
......Does this mean the same thing?
Are there any plans on adding the stringify operator (#)? Another operator to consider adding would be the token concatenation operator (##).
If so, how would they get added, especially considering they are only usable in macros?
Deterb ( talk) 18:23, 7 December 2007 (UTC)
Agreed, leave them in the preprocessor section. —Preceding unsigned comment added by Serendipity33 ( talk • contribs) 06:15, 15 April 2008 (UTC)
I would like to have it confirmed before I will edit and change this page.
so ...
statement
e = ((a ? b : c) = d)
is not an error!
a?b:c returns reference to a or b. So we have lvalue.
Please confirm that I'm right or wrong
Varciasz ( talk) 14:26, 31 January 2008 (UTC)
It is NOT an error! Both in C as in C++. 'b' and 'c' are lvalues, so assignment is possible. There will be a "warning: use of conditional as lvalues is deprecated" in C and its meaning will be different than in C++, but it works! -- Der schiefe Turm ( talk) 17:04, 16 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
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. -- Woong.jun ( talk) 11:43, 15 March 2010 (UTC)
In C++, it is clearly incorrect to simply list ?: has having higher precedence than =. For example, the statement "1 ? a : b = 7;" does nothing, in clear violation of the table. Thus, the table should be changed at least to clearly state that the situation is more complex. Is it sufficient to say that ?: and assignment have the same precedence, and both associate right to left? GIrving ( talk) 22:33, 10 September 2012 (UTC)
This page needs more links. I will start by turning some words into links (without changing the content). —Preceding unsigned comment added by 121.44.233.63 ( talk) 07:15, 14 April 2008 (UTC)
This is a pretty cool operator. I'm not sure if it's 'standard' or should be in the 'extensions' section, but it should be in the article. Also, I think the 'extensions' section should be expanded. The article shouldn't be 'noisy', but it should be a place where people can learn things about C++ they didn't previously know. (e.g., I had no idea about ->* or typeid()). Oh, and 'throw' is missing from the table. I'd like to know if it's overloadable. —Preceding unsigned comment added by 207.38.195.47 ( talk) 14:33, 7 May 2008 (UTC)
operators >? and >? doesn't exist in gcc anymore. (since gcc 4)
The section 6.5.4 "Cast operators" in the WG14 N1124 draft stands after the unary operators section 6.5.3. According to a comment to the 6.5 "Expressions" chapter, this makes casting a lower precedence operator than unary operators. But I understand that there is no way to write a test for this as both cast and unary kinds apply to one operand and thus cannot be interpreted differently. -- ilgiz ( talk) 01:20, 29 January 2009 (UTC)
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. SimonTrew ( talk) 17:34, 27 February 2009 (UTC)
So? If "this" is not an operator, what is it then? Akilaa ( talk) 08:33, 15 June 2010 (UTC)
The article sais that the postfix ++ operator is performed last; This should be: it is performed before returning a value, but the returned value is the old (unincremented) one. Can anyone change this? —Preceding unsigned comment added by 132.229.16.187 ( talk • contribs) 12:35, 8 May 2009 (UTC)
Should C++'s placement new and placement delete operators also go in the table?
void * operator new (size_t, void *) throw();
void operator delete (void *, void *) throw();
Darthmarth37 ( talk) 04:58, 1 November 2009 (UTC)
I spent 2 hours trying to find out what a bitwise left shift did. Your "Prototype examples" are not much help to anyone trying to learn anything. I finally found out that (a<<2) shifts all bits two units to the left. I strongly suggest you include examples.
It seems people trying to teach something frequently wind up bragging about all they know. They throw in everything including the kitchen sink. They feel very superior but they teach nothing and completely confuse the person learning. —Preceding unsigned comment added by Arydberg ( talk • contribs) 16:18, 20 November 2009 (UTC)
There needs to be a lot of cleanup done in the operators table, this has been discussed countless times but is an important article and is highly useful for reference and we've been cleaning it up for about 2 or more years. The problem we are having is the information it shows in the table is useful but complicated and not well explained, yet there's no room for any more than what's there now without making it look messy.
The solution is simple, we have to bite the rock and finish creating the wiki pages for the rest of the operators, For wiki pages where multiple operators can fall on one then the links can point to anchors in those pages. The pages can have the table row at the top with a more detailed explanation plus full information on that particular operator. Even though these are separate wiki pages it would help if they followed a template of some sort for uniform and so people will know where to find the information they need no matter what operator they look at.
After that then we can simplify the table down on the operators page safely knowing that there's a nice link to all the information they want about that operator.
It's really taking a very long time to accomplish something that should be much shorter, and these pages are not old or losing popularity. I would love to devote several hours a day of my time on this but my proposal is pretty major and I'd rather not do that and all get reverted, but I do propose finishing, uniforming, and making the needed changes / improvements within a much faster pace.
If anyone wants to do certain things differently than one or more of the above points, please reply. I'm hoping to get started within 7 days and finish within 14 - 30 days after start. Wiseguy12851 ( talk) 21:10, 3 April 2010 (UTC)
T1 T1::operator +(const T2& b) const;
T3 T1::operator +(const T2& b) const;
T1 T1::operator +(const T1& b) const;
It's much more efficient simply to say, "all arithmetic operators [e.g.] are overloadable." The advantage of consistency of content from table to table is not enough to make up for the costs in terms of: table code complexity; information redundancy; filesize. ᛭ LokiClock ( talk) 21:17, 20 April 2010 (UTC)
==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. ―
AoV² 22:35, 20 April 2010 (UTC)
There's no indication of what the type "R" means. OrangeDog ( τ • ε) 10:33, 23 June 2010 (UTC)
Compound literals are classified as "postfix operators" in C (ISO/IEC 9899:1990 §6.3.2.5, ISO 9899:1999 §6.5.2.5). They are not included in C++, and they are missing from this article as far as I can see. For those who haven't encountered them, an example of a compound literal, straight from the C90 standard: p = (int []){2, 4};
, or read
DrDobbs for more details. Note that it has nothing to do with type casting. How about a passing mention? --
Cubbi (
talk) 03:35, 20 September 2010 (UTC)
http://www.bitwise.iitkgp.ernet.in/enigma_thegame/qpics/a1.jpg
these are the combination of operators (Operators in C and C++).can u identify these in separately. —Preceding unsigned comment added by 218.248.64.207 ( talk) 03:34, 30 January 2011 (UTC)
An array allocation form is missing for C. C99 allows for arrays to be declared at runtime with a varable instead of at compile with a constant. The syntax is type labelcount].
For example:
void foo (int count)
{
int myarraycount];
//Now do something here.
}
From Operators_in_C_and_C++#Notes:
"* For example, ++x*3
is ambiguous without some precedence rule(s). The precedence table tells us that: x is 'bound' more tightly to ++ than to *, so that whatever ++ does (now or later—see below), it does it ONLY to x (and not to x*3
); it is equivalent to (++x
, x*3
)."
This looks like it is saying that
++x*3
is equivalent to (++x, x*3)
. Which is incorrect: with the comma operator, the arguments can be evaluated in any order.
EDIT: I wasn't aware of sequence points.
Nevermind! :)
Muntoo ( talk) 23:21, 1 November 2011 (UTC)
C11 defines an alignment operator _Alignof
. I have read about something similar in C++11, although I can't find anyone that actually references the ISO/IEC 14882:2011 document. If anyone know the standards better than I, then please add information about it.
Caesar (
talk) 08:05, 7 February 2012 (UTC)
alignof
, according to chapter 3.11, "Alignment", of ISO/IEC 14882:2011. That is also the name of the macro included in the C header stdalign.h
.
Caesar (
talk) 22:19, 7 February 2012 (UTC)Unless I'm wrong, there's something amiss with the return types of most overloaded binary operators as shown on the page. They return values, not references, but use reference arguments (right hand operands). This means that in their current state as shown on the page, they cannot be used in right-to-left algebraic expressions (e.g.: a + (b + c) will trigger a compiler error, unless (b + c) is stored in a variable first and used as such).-- Printz150 ( talk) 18:58, 25 February 2012 (UTC)
What about this one ? (New in C++11) Declaration is like : int operator"" _stuff ( int val);
And use would be : int x = 36_stuff; Doom Oo7 ( talk) 09:27, 23 August 2013 (UTC)
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.)
Duoas ( talk) 22:06, 6 May 2014 (UTC)
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 — Preceding unsigned comment added by 2.244.33.171 ( talk) 20:36, 15 June 2015 (UTC)
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. Debanshu.Das ( talk) 04:55, 4 August 2020 (UTC)
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 A::B::C
cannot be written neither as (A::B)::C
– that would be a C-style typecast – nor as A::(B::C)
– that would be a syntax error. --
RokerHRO (
talk) 21:04, 5 February 2021 (UTC)
Given that
a++;
changes the objects internal value and is equivalent to
a+=1;
for numerical objects, shouldn't the increment/decrement operators be considered assignment operators? 80.62.116.42 ( talk) 07:45, 17 October 2022 (UTC)
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. -- Wassermaus ( talk) 22:32, 26 October 2023 (UTC)
or
). 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. a??(0??)
and a<:0:>
mean exactly the same thing despite the former being just a[0]
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, a or b
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 int and a = 0;
the and
is not an operator.
Nickps (
talk) 09:25, 27 October 2023 (UTC)
R<%a%>
and R??<a??>
plus the ones with auto
, 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 and
.
Nickps (
talk) 22:54, 8 May 2024 (UTC)The C23 standard adds the operators typeof
and typeof_unqual
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,
p2958, groups them together with decltype
, which makes sense. However, I can't find any source that refers to decltype
as an "operator". In the
decltype page one of the references is called
decltype operator, but that name has since been changed to "decltype Type Specifier". (EDIT: Some examples of the phrase "decltype operator" I found:
[1]
[2] and
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 decltype
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.
Nickps (
talk) 18:07, 30 October 2023 (UTC)
This is the
talk page for discussing improvements to the
Operators in C and C++ article. This is not a forum for general discussion of the article's subject. |
Article policies
|
Find sources: Google ( books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL |
![]() | This article is rated C-class on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | |||||||||||||||||||||||||||||
|
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. —Preceding unsigned comment added by 108.16.83.48 ( talk) 20:15, 27 January 2011 (UTC)
There is no exponentiation operator in c++ because ^ and the other usual ones are taken. One needs to use the function pow(BASE,EXPONENT). — Preceding
unsigned comment added by
129.69.39.34 (
talk) 09:46, 19 February 2014 (UTC)
The prototype column horribly esoteric. It needs its own explanation.
--
I agree that it's esoteric, but I don't think it needs explanation: the whole column needs to be removed completely. It's completely redundant.
I think its content is highly inappropriate for Wikipedia, and if you're looking for more useful information (like what the h-ll the operators actually mean), you'll end up using Google, anyway.
Similar to the comment below, I suggest that we replace the prototype column with another column that briefly describes what the operator actually does.
121.210.170.141 ( talk) 06:40, 19 November 2009 (UTC)
The prototype column should be corrected, then it would be very usefull. For example, a prototype for an assignment operator that returns a type R!=T, where T is the type of the calling object is a wrong prototype. The build-in assignment operator returns a reference to the left-hand side operator, which has particular effects. Overloaded operators should implement an analogous interface. Therefore, it worths if the column prototypes describe the interface of the build-in operators. Actually, that was the approach of an older version of the page. Why it has changed? Actually, we are allowed to overload an operator with no restriction, eg. we can overload operator= as a void but such an approach would cause confusion to the application programmer who should cope with various behaviors of assignment operation — Preceding unsigned comment added by Lefteris.moussiades ( talk • contribs) 18:20, 11 December 2012 (UTC)
Hi. I wonder if it might be useful to describe what some of these operators do. I'm not familiar, for example, with the comma (',') operator, and it would be neat to know what it does.
Well, it is hard to put that stuff in the table, but I agree it would be nice to have links or something. For what it is worth though, the comma operator is not very important. The most common place it is used is in for statements, for ( ix=0, jx=0; ix < t; ix++ ){}. Do you see the comma? It means, "evaluate the expression to the left, now go on and evaluate the expression to the right". The final value is the value of the last expression (ignored in this very typical case). It is different than commas in function calls because, for one thing, terms there are evaluated right to left. Also note that, at least in this case, there is another way to write this without commas: jx=0; for (ix=0; ix < t; ix++){}. AJim 01:34, 16 May 2004 (UTC)
Why have C and C++ operators been lumped into one article? It would be less confusing to have separate articles for each. Eric119 00:12, 1 May 2005 (UTC)
This page needs an order of operations. I'll probably put it on here. 67.161.46.169 09:42, 27 December 2005 (UTC)
I think this section needs to be moved to just before notes. It interferes with the first paragraph which is describing the tables following the order section. —Preceding unsigned comment added by 121.44.233.63 ( talk) 07:04, 14 April 2008 (UTC)
Someone needs to add the ! operator to the precedence table. I'd love to know where it goes because I've odd behavior with it. Retep998 ( talk) 04:58, 27 December 2010 (UTC)
Can the reference operator really be overloaded? I'm fairly sure it can't.... Not sure where to look, though. 68.238.86.68 21:50, 29 May 2006 (UTC)
I just removed this sentance:
Those operators that are in C are also in Java, Perl, C#, and PHP with the same precedence, associativity, and semantics.
From the article. I'm happy for something similar to go back in, but as it stands it is not true, as for example the comma operator, which is in C, is not in java or C#. Mrjeff 14:55, 4 June 2006 (UTC)
It's also the case that PHP's ?: operator has the "wrong" associativity. I don't think the article on C operators should really be making claims about other languages at all, but if it does it should be correct. — Preceding unsigned comment added by Amalloy ( talk • contribs) 22:29, 18 August 2011 (UTC)
This article seems to be suffering the line of reasoning that "C is a programming language. C++ is a programming language. Thus, C and C++ are the same." (and all other programming languages are affected by this logic too). The issue with lumping C and C++ into the same article is that C++ diverged from C long before the standardisation if C. Once C was standardised, things started to change. If the editors can't understand that, then this article will always be of poor quality. 123.200.203.23 ( talk) 01:02, 26 August 2011 (UTC)
I don't know the answer to this question, but it seems like a useful thing to be in this article, if someone else knows. The C-style cast operator (type)
is in the table, but what about the special C++ cast operators static_cast<type>()
, dynamic_cast<type>()
, reinterpret_cast<type>()
, and const_cast<type>()
?
safe_cast<type>()
, it's not official C++ but it's widely used with .Net productions and is important for .net optimization. I personally dislike .net very much but for completeness sake, it's used and recommended.
Wiseguy12851 (
talk) 20:36, 2 April 2010 (UTC)
The scope operator in C++ is different from the other operators, I think. Even if it is mentioned as an operator in some parts of the C++ standard it does not behave like an operator but as an token (or name) joiner. I.e. you cannot put parentheses around to change the order of evaluation: if A::B::C
is a valid expression, (A::B)::C
has a different meaning (a C-style type cast) and A::(B::C)
is a syntax error. What do you think, should we mention this special behavior of the "operator" ::
? --
89.55.168.117 10:46, 21 July 2006 (UTC) (
de:Benutzer:RokerHRO)
Recently, there was a revert to remove the Label Value Operator && from the list of C/C++ operators. While it is true that the operator is not at all standard ISO C/C++, it is a non-standard extension to some dialects, one of which is documented here. This raises the question of whether or not there should be a seperate table for operators sometimes seen as extensions to the language. I mean, such operators aren't C/C++, but they might still be of interest to some programmers. Maybe another page would be good? Extended operators? -- Cgranade 08:04, 12 October 2006 (UTC)
Not many operators get added as extensions (slight changes in existing operator semantics are more common), so added a new subsection to the table. See how things develop. Derek farn 08:32, 12 October 2006 (UTC)
I don't get this. Why include some non-standard operator that is not found in most compilers? There is already a standard label: statement (not operator) that should be compatible with all compilers. - Andrew flame him | stalk him 23:53, 14 July 2007 (UTC)
A recent edit made a large number of changes to this article, none of which I feel contribute positively to its content. That's just my opinion, but I did revert them; here is my reasoning:
a
, b
, and c
as used in the table do not just represent "valid values": depending upon context, they might be object names or lvalues, as well.&
, <
, and >
should never be entered directly into HTML. Use the character entities instead: &
, <
, and >
, respectively.I'm not going to defend the article like a hawk, but I would like to see some discussion rather than a total reversion.— Kbolino 03:49, 22 February 2007 (UTC)
The title says it all - in the article about associativity which is linked from this article, there are two terms defined: "left-associative" and "right-associative". But in this article, "left-ro-right" and "right-to-left" is used. That's inconsistent. I think that "left-to-right" probably corresponds to "left-associative" and the same for right, but thinking is not knowing. If so, maybe a middle-way correction could be good ("left-associative (left-to-right)"), since "left-to-right" is more intuitive name that "left-associative", so I think we should keep both namings. What do you think?
a & b == 7
means
a & (b == 7) ,
while
a + b == 7
means
(a + b) == 7 .
......Does this mean the same thing?
Are there any plans on adding the stringify operator (#)? Another operator to consider adding would be the token concatenation operator (##).
If so, how would they get added, especially considering they are only usable in macros?
Deterb ( talk) 18:23, 7 December 2007 (UTC)
Agreed, leave them in the preprocessor section. —Preceding unsigned comment added by Serendipity33 ( talk • contribs) 06:15, 15 April 2008 (UTC)
I would like to have it confirmed before I will edit and change this page.
so ...
statement
e = ((a ? b : c) = d)
is not an error!
a?b:c returns reference to a or b. So we have lvalue.
Please confirm that I'm right or wrong
Varciasz ( talk) 14:26, 31 January 2008 (UTC)
It is NOT an error! Both in C as in C++. 'b' and 'c' are lvalues, so assignment is possible. There will be a "warning: use of conditional as lvalues is deprecated" in C and its meaning will be different than in C++, but it works! -- Der schiefe Turm ( talk) 17:04, 16 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
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. -- Woong.jun ( talk) 11:43, 15 March 2010 (UTC)
In C++, it is clearly incorrect to simply list ?: has having higher precedence than =. For example, the statement "1 ? a : b = 7;" does nothing, in clear violation of the table. Thus, the table should be changed at least to clearly state that the situation is more complex. Is it sufficient to say that ?: and assignment have the same precedence, and both associate right to left? GIrving ( talk) 22:33, 10 September 2012 (UTC)
This page needs more links. I will start by turning some words into links (without changing the content). —Preceding unsigned comment added by 121.44.233.63 ( talk) 07:15, 14 April 2008 (UTC)
This is a pretty cool operator. I'm not sure if it's 'standard' or should be in the 'extensions' section, but it should be in the article. Also, I think the 'extensions' section should be expanded. The article shouldn't be 'noisy', but it should be a place where people can learn things about C++ they didn't previously know. (e.g., I had no idea about ->* or typeid()). Oh, and 'throw' is missing from the table. I'd like to know if it's overloadable. —Preceding unsigned comment added by 207.38.195.47 ( talk) 14:33, 7 May 2008 (UTC)
operators >? and >? doesn't exist in gcc anymore. (since gcc 4)
The section 6.5.4 "Cast operators" in the WG14 N1124 draft stands after the unary operators section 6.5.3. According to a comment to the 6.5 "Expressions" chapter, this makes casting a lower precedence operator than unary operators. But I understand that there is no way to write a test for this as both cast and unary kinds apply to one operand and thus cannot be interpreted differently. -- ilgiz ( talk) 01:20, 29 January 2009 (UTC)
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. SimonTrew ( talk) 17:34, 27 February 2009 (UTC)
So? If "this" is not an operator, what is it then? Akilaa ( talk) 08:33, 15 June 2010 (UTC)
The article sais that the postfix ++ operator is performed last; This should be: it is performed before returning a value, but the returned value is the old (unincremented) one. Can anyone change this? —Preceding unsigned comment added by 132.229.16.187 ( talk • contribs) 12:35, 8 May 2009 (UTC)
Should C++'s placement new and placement delete operators also go in the table?
void * operator new (size_t, void *) throw();
void operator delete (void *, void *) throw();
Darthmarth37 ( talk) 04:58, 1 November 2009 (UTC)
I spent 2 hours trying to find out what a bitwise left shift did. Your "Prototype examples" are not much help to anyone trying to learn anything. I finally found out that (a<<2) shifts all bits two units to the left. I strongly suggest you include examples.
It seems people trying to teach something frequently wind up bragging about all they know. They throw in everything including the kitchen sink. They feel very superior but they teach nothing and completely confuse the person learning. —Preceding unsigned comment added by Arydberg ( talk • contribs) 16:18, 20 November 2009 (UTC)
There needs to be a lot of cleanup done in the operators table, this has been discussed countless times but is an important article and is highly useful for reference and we've been cleaning it up for about 2 or more years. The problem we are having is the information it shows in the table is useful but complicated and not well explained, yet there's no room for any more than what's there now without making it look messy.
The solution is simple, we have to bite the rock and finish creating the wiki pages for the rest of the operators, For wiki pages where multiple operators can fall on one then the links can point to anchors in those pages. The pages can have the table row at the top with a more detailed explanation plus full information on that particular operator. Even though these are separate wiki pages it would help if they followed a template of some sort for uniform and so people will know where to find the information they need no matter what operator they look at.
After that then we can simplify the table down on the operators page safely knowing that there's a nice link to all the information they want about that operator.
It's really taking a very long time to accomplish something that should be much shorter, and these pages are not old or losing popularity. I would love to devote several hours a day of my time on this but my proposal is pretty major and I'd rather not do that and all get reverted, but I do propose finishing, uniforming, and making the needed changes / improvements within a much faster pace.
If anyone wants to do certain things differently than one or more of the above points, please reply. I'm hoping to get started within 7 days and finish within 14 - 30 days after start. Wiseguy12851 ( talk) 21:10, 3 April 2010 (UTC)
T1 T1::operator +(const T2& b) const;
T3 T1::operator +(const T2& b) const;
T1 T1::operator +(const T1& b) const;
It's much more efficient simply to say, "all arithmetic operators [e.g.] are overloadable." The advantage of consistency of content from table to table is not enough to make up for the costs in terms of: table code complexity; information redundancy; filesize. ᛭ LokiClock ( talk) 21:17, 20 April 2010 (UTC)
==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. ―
AoV² 22:35, 20 April 2010 (UTC)
There's no indication of what the type "R" means. OrangeDog ( τ • ε) 10:33, 23 June 2010 (UTC)
Compound literals are classified as "postfix operators" in C (ISO/IEC 9899:1990 §6.3.2.5, ISO 9899:1999 §6.5.2.5). They are not included in C++, and they are missing from this article as far as I can see. For those who haven't encountered them, an example of a compound literal, straight from the C90 standard: p = (int []){2, 4};
, or read
DrDobbs for more details. Note that it has nothing to do with type casting. How about a passing mention? --
Cubbi (
talk) 03:35, 20 September 2010 (UTC)
http://www.bitwise.iitkgp.ernet.in/enigma_thegame/qpics/a1.jpg
these are the combination of operators (Operators in C and C++).can u identify these in separately. —Preceding unsigned comment added by 218.248.64.207 ( talk) 03:34, 30 January 2011 (UTC)
An array allocation form is missing for C. C99 allows for arrays to be declared at runtime with a varable instead of at compile with a constant. The syntax is type labelcount].
For example:
void foo (int count)
{
int myarraycount];
//Now do something here.
}
From Operators_in_C_and_C++#Notes:
"* For example, ++x*3
is ambiguous without some precedence rule(s). The precedence table tells us that: x is 'bound' more tightly to ++ than to *, so that whatever ++ does (now or later—see below), it does it ONLY to x (and not to x*3
); it is equivalent to (++x
, x*3
)."
This looks like it is saying that
++x*3
is equivalent to (++x, x*3)
. Which is incorrect: with the comma operator, the arguments can be evaluated in any order.
EDIT: I wasn't aware of sequence points.
Nevermind! :)
Muntoo ( talk) 23:21, 1 November 2011 (UTC)
C11 defines an alignment operator _Alignof
. I have read about something similar in C++11, although I can't find anyone that actually references the ISO/IEC 14882:2011 document. If anyone know the standards better than I, then please add information about it.
Caesar (
talk) 08:05, 7 February 2012 (UTC)
alignof
, according to chapter 3.11, "Alignment", of ISO/IEC 14882:2011. That is also the name of the macro included in the C header stdalign.h
.
Caesar (
talk) 22:19, 7 February 2012 (UTC)Unless I'm wrong, there's something amiss with the return types of most overloaded binary operators as shown on the page. They return values, not references, but use reference arguments (right hand operands). This means that in their current state as shown on the page, they cannot be used in right-to-left algebraic expressions (e.g.: a + (b + c) will trigger a compiler error, unless (b + c) is stored in a variable first and used as such).-- Printz150 ( talk) 18:58, 25 February 2012 (UTC)
What about this one ? (New in C++11) Declaration is like : int operator"" _stuff ( int val);
And use would be : int x = 36_stuff; Doom Oo7 ( talk) 09:27, 23 August 2013 (UTC)
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.)
Duoas ( talk) 22:06, 6 May 2014 (UTC)
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 — Preceding unsigned comment added by 2.244.33.171 ( talk) 20:36, 15 June 2015 (UTC)
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. Debanshu.Das ( talk) 04:55, 4 August 2020 (UTC)
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 A::B::C
cannot be written neither as (A::B)::C
– that would be a C-style typecast – nor as A::(B::C)
– that would be a syntax error. --
RokerHRO (
talk) 21:04, 5 February 2021 (UTC)
Given that
a++;
changes the objects internal value and is equivalent to
a+=1;
for numerical objects, shouldn't the increment/decrement operators be considered assignment operators? 80.62.116.42 ( talk) 07:45, 17 October 2022 (UTC)
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. -- Wassermaus ( talk) 22:32, 26 October 2023 (UTC)
or
). 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. a??(0??)
and a<:0:>
mean exactly the same thing despite the former being just a[0]
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, a or b
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 int and a = 0;
the and
is not an operator.
Nickps (
talk) 09:25, 27 October 2023 (UTC)
R<%a%>
and R??<a??>
plus the ones with auto
, 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 and
.
Nickps (
talk) 22:54, 8 May 2024 (UTC)The C23 standard adds the operators typeof
and typeof_unqual
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,
p2958, groups them together with decltype
, which makes sense. However, I can't find any source that refers to decltype
as an "operator". In the
decltype page one of the references is called
decltype operator, but that name has since been changed to "decltype Type Specifier". (EDIT: Some examples of the phrase "decltype operator" I found:
[1]
[2] and
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 decltype
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.
Nickps (
talk) 18:07, 30 October 2023 (UTC)