Talk:Operators in C and C++

Prototypes

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)

Describe what they do

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)

Separate C and C++?

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)

They're better than 95% congruent. Having separate articles would be inefficient. Furthermore, placing them together emphasizes the close relationship between the two languages.

I agree, C++ is a superset of C. 67.161.46.169 09:42, 27 December 2005 (UTC)

Not quite, actually, but it's true operator-wise 68.238.86.68 21:50, 29 May 2006 (UTC)

Not true. The distinction is made even greater by the introduction of the C99 standard. Denis Kasak 12:58, 11 June 2006 (UTC)

Is it true from the point of view of operators however? I don't remember C99 introducing any new operators.

C++ didn't take any operators away, and C99 didn't add any (check the article). 141.149.206.197 22:50, 11 June 2006 (UTC)

Something needs to be done about the new and delete operators. First, new/delete definitely aren't in C. — Mobius 02:40, 30 August 2006 (UTC)

Right, that's why it says "no" under "in C?" --131.215.155.112 22:13, 31 August 2006 (UTC)

order of operations

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)

Reference (prefix &) operator

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)

Yes it can be overloaded (I just tried) Mrjeff 22:10, 29 May 2006 (UTC)

Wow. That's really weird. 68.238.86.68 22:59, 29 May 2006 (UTC)

Just in case you are curious, I went and had a look at why it can be overloaded. There are two main reasons. Firstly, there was a choice made that unless there is a good reason not to allow overloading an operator, all overloads would be allowed. Secondly, it could be useful if you have objects which taking a "normal reference" to might not make sense, but which you want to provide a "smart pointer" to. Mrjeff 23:11, 30 May 2006 (UTC)

Another use, is iterators as used in the STL.

Operators in other languages

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)

C++ cast operators?

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>()?

These are mentioned at the top of the page. I cannot see a good reason for them not to live in the table however, so they shouldn't probably be moved there. Feel free to do so :) Mrjeff 12:13, 22 June 2006 (UTC)

Don't forget 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)

This would be appropriate to mention in articles specific to w32 programming. ―AoV² 21:16, 2 April 2010 (UTC)

Scope operator

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)

Label value operator

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)

Sounds good, looks good. Think I'll make the name a link, though, since it isn't clear from the table what a label value operator is exactly.

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)

Major Changes

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:

1. The symbols 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.
2. The word "declaration" has two As and one E.
3. The characters &, <, and > should never be entered directly into HTML. Use the character entities instead: &, <, and >, respectively.
4. The models illustrating how to overload the operators make the table seem confusing and too technical.
5. Similarly, the explanation of how to overload the operators is an implementation detail; it is not, in my opinion, the job of this article to explain how to overload each operator.

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)

This is wiki-markup, you do not need to escape the chars. The reason I added the overload info was that I could not find an exhaustive list anywhere (I'm writing a code generator which infers operator overloads, on mathematic objects, of course). So, I painstakingly constructed one here, looking through many sources, guidelines to arrive at these. Yes, it makes it look technical, but this is programming, after all. True, people might not look to wikipedia for their programming reference, however, I've noticed more lately that language documentation is exceedingly crappy. I'd like to have a place I can lookup such overloads. For example, look at overloading postfix increment - is that crazy or what? Anyway, it'd be sacrificing my work, and valuable screen space that will just be blank. I'm reverting back, though taking out the spelling errorMgsloan 07:16, 22 February 2007 (UTC)

I wrote a rather large reply, but I guess I shut off my computer before actually hitting "Save page". I will try to recollect my thoughts and reply again.—Kbolino 23:17, 24 February 2007 (UTC)

Associativity - inconsistency with linked article ("left-ro-right" vs. "left-associative")

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?

& and | are arithmetic operators

  a & b == 7

means

  a & (b == 7)   ,

while

  a + b == 7

means

  (a + b) == 7   .

......Does this mean the same thing?

No, the first does == first, the second does addition first. It's what operator precedence is all about. --King Mir (talk) 22:05, 12 January 2008 (UTC)

C and C++ Stringify operator

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)

The stringify and token concatenation operators are not technically C or C++ operators -- they are preprocessor operators, and are dealt with in the article C preprocessor. I think it makes more sense to leave them there, rather than merging them here. --Wayne Miller (talk) 18:01, 2 January 2008 (UTC)

Agreed, leave them in the preprocessor section. —Preceding unsigned comment added by Serendipity33 (talk • contribs) 06:15, 15 April 2008 (UTC)

Error in article

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)

You are wrong in C and right in C++. Derek farn (talk) 14:40, 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)

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. decltype (talk) 17:12, 16 September 2009 (UTC)

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. ;-) --Der schiefe Turm (talk) 15:08, 23 September 2009 (UTC)

It's a footnote in Section 6.5.15, as seen here. It's also highlighted in Annex C of the C++ Standard as one of the differences between C++ and C. decltype (talk) 15:27, 23 September 2009 (UTC)

THNX! --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

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)

Adding links

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)

typeof()

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)

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. ← Michael Safyan ^(talk) 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 "decltype operator" is frequently used in the proposals. decltype (talk) 17:15, 16 September 2009 (UTC)

>? and <? operators

operators >? and >? doesn't exist in gcc anymore. (since gcc 4)

Precedence of type casting in plain C

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)

"this"

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)

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. this is not an operator, so I think it's just confusing to have it in a list of operators. Possibly a mention at the bottom of the article, but not in the actual table. Just my 5c. decltype 19:06, 27 February 2009 (UTC)

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. SimonTrew (talk) 06:57, 28 February 2009 (UTC)

Pre- and postfix ++/--

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)

The actual time when the increment happens is unspecified (as long as it is between the appropriate sequence points). Eric119 (talk) 16:04, 8 May 2009 (UTC)

Placement new and delete operators?

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)

A link in the table would be enough (or a * link to below the table), but I doubt it's appropriate to emphasize it too much. Wikipedia isn't a tutorial (and much is missing from this page already - covering everything would be impossible).

Also, the standard "placement" new/delete operators are are in #include <new>, and not redefinable, so they're basically just regular overloads of new/delete (new can take as many args as you want).

If you think it's that important, add it unobtrusively to the table.

121.210.170.141 (talk) 07:30, 19 November 2009 (UTC)

bitwise right shift

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)

Just like any other encyclopedia, Wikipedia is not a tutorial or an introduction.

Besides that, we could easily see someone making a complaint in the same vein about what 'bit shifting'/etc means if more inscrutable information were included.

More examples are inappropriate, in my opinion, but a link in "Operator name" column would be more than useful (this page is retarded in that way and others...).

There have been comments suggesting that this page should be a complete and informative source [for programmers]. I don't think this is what Wikipedia is about, but do think a community contributed reference table of operators would be nice (since, as mentioned, most online resources clearly fail in one way or another). This information could appropriately be placed in one of the wiki-books (if it hasn't been already) and [clearly] linked to from this article.

121.210.170.141 (talk) 12:22, 21 November 2009 (UTC)

Next Major Change and Re-Uniformity

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)

Which stage are you at right now? I have one change I want to do or to see done to the page, and that's all the templates (declaration examples). Today we have:

T1 T1::operator +(const T2& b) const;

This is paedagogically inconsistent. It should either be

T3 T1::operator +(const T2& b) const;

or

T1 T1::operator +(const T1& b) const;

Otherwise we are leading the reader to think that the return type of an operator is necessarily one of the argument types, or even the left hand side operator, or possibly the declaring type. And each of that is plain wrong in both of C (built-in operators) and C++.Lalaith (talk) 18:14, 14 May 2010 (UTC)

Get rid of Overloadable column for those all-yes

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)

This reflects the fact that the operators previously were all in one continuous table. I only split them apart on account of the ==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)