On Mon, 16 Nov 2009, Steven W. Orr wrote:
On 11/16/09 13:54, quoth Rick Stevens:
On 11/14/2009 01:55 PM, Frank Cox wrote:
On Sat, 14 Nov 2009 14:50:57 -0500
Steven W. Orr wrote:
There's nothing wrong with perl having all kinds of perldoc pages.
But perl
comes from one place. C, OTOH could come from lots of places besides
FSF and
the switch statement in gcc may not be exactly the same as the switch
statement in some other dialect.
As C is an ISO standard, I sincerely doubt there would be any
difference in the
syntax and behaviour of the keywords between C compilers on any Unix-like
operating system.
Incorrect. C, for example, does not guarantee the order of evaluation
of arithmetic operators of equal precedence in the same statement (in
other words, is something like "a + b + c" evaluated left to right, or
right to left?). This can have significant effects if some of the
operands have "side effects"
Another example is that a null pointer (or the value "NUL") is not
necessarily zero, only that it is guaranteed to not point at any valid
datum.
C allows quite a bit of leeway to the compiler implementation.
I think I disagree on this one. We jumped from standardization of keywords to
how operators perform. I quote from page 53 of K&R: Table of Precedence and
Associativity of Operators: a + b + c *always* goes from left to right. K&R is
not the standard, but does the standard say otherwise? Lots of things are up
to the compiler writer, but I'd be surprised if this was one of them. Sometime
people worry about things like
a++ + b++ + c++
but even there, the precedence and the associativity are defined. In this case
a++ + b++ + c++
becomes (in psuedo stack code):
a++
b++
c++
a b +
c +
because binary + is lower precedence than ++.
No?
No. The value of a++ is the original value of a.
Assuming a++ does not change the stack:
a b +
c +
a++
c++
b++
Also allowed:
c b a
b++
+
c++
+
a++
--
Michael hennebry@xxxxxxxxxxxxxxxxxxxxx
"Pessimist: The glass is half empty.
Optimist: The glass is half full.
Engineer: The glass is twice as big as it needs to be."
--
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
