The Wikipedia article on C and C++ operators

[kwikius]

This concerns the Wikipedia article on C and C++ operators:
http://en.wikipedia.org/wiki/Operators_in_C_and_C++

Until very recently the first table in the page was a very
useful one on the precedence of C operators. This has
recently been replaced by one on C++ operators. I'm
not at all happy with that but I guess I can always link
to the history page. But I was wondering if anyone could
have a look and verify that the C part is correct. I'm pretty
sure that in C postfix/prefix increment/decrement have
the same priority. Is it different in C++ ?

Hang on. Are you saying that the table of precedence for C++ operators,
now has precedence over the table of precedence for the table of C
operators, whereas previously the table now preceeding was in fact
previously not preceeding the table which previously preceeded it? If
so the correct procedure is to proceed to replace if possible these
tables of precedence in their previous precedence. Simple really ...

regards
Andy Little

 

[Victor Bazarov]

An example that compiles and has defined behaviour.

REALLY? On which compiler? I am asking so that I can avoid it like
a plague.

V

 

[Old Wolf]

REALLY? On which compiler? I am asking so that I can avoid it like
a plague.

Any conforming compiler (?)

 

[Frederick Gotham]

Old Wolf posted:

Any conforming compiler (?)

I wouldn't have much faith in a compiler which didn't give a warning or an
error for:

int main()
{
++5;
}

 

[Keith Thompson]

REALLY? On which compiler? I am asking so that I can avoid it like
a plague.

I think there was a misunderstanding here. Old Wolf was asking for
such an example; "++a++;" isn't one.

 

[Old Wolf]

Old Wolf posted:

I wouldn't have much faith in a compiler which didn't give a warning or an
error for:

int main()
{
++5;
}

What does that have to do with the topic at hand? I'm asking
for an example that compiles and has defined behaviour, of
code where assigning postfix++ the same priority as prefix++,
conflicts with the specification of the standard. Victor's example
and your example aren't such examples.

 

[Victor Bazarov]

[..] I'm asking
for an example that compiles and has defined behaviour, of
code where assigning postfix++ the same priority as prefix++,
conflicts with the specification of the standard.

You weren't, before. If you want to assign the same precedence to
those operators, you have to define first how they are going to work,
i.e. what the order of their processing is going to be, and how they
are going to interact with other operators.

Victor's example
and your example aren't such examples.

I gave you the example you asked for. Post-xxcrement has higher
precedence, so it's applied first. All postfix operators are
applied first *because* they have higher precedence. As soon as
you give them the same precedence as prefix operators, the grammar
breaks down.

You say "move them all to the same precedence". How? Which order
first? Left-to-right or right-to-left? Or mixed? One from left
and one from right, or reversed?

Stop wasting our time.

V

 

[Keith Thompson]

[..] I'm asking
for an example that compiles and has defined behaviour, of
code where assigning postfix++ the same priority as prefix++,
conflicts with the specification of the standard.

You weren't, before. If you want to assign the same precedence to
those operators, you have to define first how they are going to work,
i.e. what the order of their processing is going to be, and how they
are going to interact with other operators.

Victor's example
and your example aren't such examples.

I gave you the example you asked for. Post-xxcrement has higher
precedence, so it's applied first. All postfix operators are
applied first *because* they have higher precedence. As soon as
you give them the same precedence as prefix operators, the grammar
breaks down.

Your example included the line

++a++;

This is illegal in C, since neither prefix ++ nor postfix ++ yields an
lvalue. If you want to discuss it in the context of C++, please drop
comp.lang.c from the Newsgroups: header.

This is an excellent example of why cross-posts to comp.lang.c and
comp.lang.c++ are almost always a bad idea.

 

[Old Wolf]

Follow-ups set to c.l.c++ , as that is where Victor is reading

[..] I'm asking
for an example that compiles and has defined behaviour, of
code where assigning postfix++ the same priority as prefix++,
conflicts with the specification of the standard.

You weren't, before.

From my original post on this thread:

Can you give an example of that? I think both versions of ++ should
be in the lower category

I thought it went without saying that the example should be
well-defined.

If you want to assign the same precedence to
those operators, you have to define first how they are going to work,
i.e. what the order of their processing is going to be, and how they
are going to interact with other operators.

Please see the precedence table referenced from the initial
message in this thread.

I gave you the example you asked for.

Your example causes undefined behaviour.

Post-xxcrement has higher precedence, so it's applied first.
All postfix operators are applied first *because* they have
higher precedence. As soon as you give them the same
precedence as prefix operators, the grammar breaks down.

This is nonsense. Again, I ask you to give a program which is
well-defined according to the table as currently given, but would
be different if postfix ++ were moved to the same precedence
group as prefix ++.

You say "move them all to the same precedence". How? Which order
first? Left-to-right or right-to-left? Or mixed? One from left
and one from right, or reversed?

Stop wasting our time.

You continually ask the same question, which I have already
answered explicitly, and was covered by the table in the initial
message in this thread.

Again: postfix-++ should have the same precedence as prefix-++
in the table, and be right-to-left associative.

If you think my question is a waste of time, simply stop replying.

BTW, is English your first language? (I don't mean this as a flame,
I am just curious, as we seem to have a bit of a gap in understanding
here).

 

[Richard Bos]

That's where some differences between C and C++ come into play.

In C, from a formal point of view (as dictated by the language grammar),
precedence of postfix increment/decrement _is_ higher than that of prefix
increment/decrement. But the need to compare the two might only arise in
expressions like

++v--; /* it is '++(v--)', not (++v)-- */

The main practical reason is, of course, that it's not just postfix ++
which has a higher priority than prefix ++, but _all_ postfix operators
have higher priority than all unary (prefix) operators. This also means
that, for example, -a[10] is -(a[10]), not (-a)[10] - which is the
reasonable way for the priority to be.

Richard

 

[Richard Bos]

Hang on. Are you saying that the table of precedence for C++ operators,
now has precedence over the table of precedence for the table of C
operators, whereas previously the table now preceeding was in fact
previously not preceeding the table which previously preceeded it? If
so the correct procedure is to proceed to replace if possible these
tables of precedence in their previous precedence. Simple really ...

A prescient reply, but doing so might set a precedent.

Richard

 

[spibou]

So why did you mix C++ into it?

1) I wanted to find out if operator precedence
is different in C++. Partly due to curiosity and
partly because I wanted to know if it is reliable to
consult tables on C++ operator precedence when
I'm interested in C.

2) To alert the people on comp.lang.c++ that a change
has been made to a Wikipedia article on C++ in case
they wanted to check its accuracy. Assuming they're
not as cynical about Wikipedia as Richard Heathfield
is.

Spiros Bousbouras

 

[kwikius]

A prescient reply, but doing so might set a precedent.

No problem . I'm presently president of the society for the
preservation of precedence in Wiki operator precedence tables.
Unfortunately the previous president, Pete, was found to be unfairly
manipulating the the operators and the tables themselves by putting
brackets around everything. Preposterous!. It is the societies aim to
have brackets banned because they play havoc with operator precedence
and make our society look completely ridiculous. We won't stand for
this type of behaviour and request that any sightings of such use of
brackets be reported to us forthwith.

regards
Andy Little