Talk:Operators in C and C++
From Wikipedia, the free encyclopedia
[edit] 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)
[edit] 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)
[edit] 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)
[edit] 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.
- Wow. That's really weird. 68.238.86.68 22:59, 29 May 2006 (UTC)
[edit] 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)
[edit] 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)
[edit] 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)
[edit] 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.
[edit] 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:
- The symbols
a
,b
, andc
as used in the table do not just represent "valid values": depending upon context, they might be object names or lvalues, as well. - The word "declaration" has two As and one E.
- The characters
&
,<
, and>
should never be entered directly into HTML. Use the character entities instead:&
,<
, and>
, respectively. - The models illustrating how to overload the operators make the table seem confusing and too technical.
- 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)
[edit] 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?