From: Rod Pemberton on

"Phil Carmody" <thefatphil_demunged(a)yahoo.co.uk> wrote in message
news:877ioj1qmv.fsf(a)nonospaz.fatphil.org...
> "Rod Pemberton" <do_not_have(a)nowhere.cmm> writes:
> > "Phil Carmody" <thefatphil_demunged(a)yahoo.co.uk> wrote in message
> > news:873aze5gms.fsf(a)nonospaz.fatphil.org...
> > > Well, it does say that ``la[--i]'' is to be evaluated before
> > ``la[--i]=i''.
> >
> > True, that is stated.
> >
> > > It also says that ``--i'' is to be evalutate before ``la[--i]''.
> >
> > False, that is unstated. But, it is a logical corollary to 'la[--i]'
being
> > evaluated.
> >
> > > That much I evidently have no issue with.
> > >
> > > It does *not* say that ``la[--i]'' is to be evaluated before ``i''.
> > >
> >
> > True, that is unstated. But, if it where stated, that would contradict
> > conditions of 'la[--i]' being evaluated prior to 'la[--i]=i'.
> >
> >
> > It says 'la[--i]' is to be evaluated before 'la[--i]=i'. I.e., '--i'
must
> > be evaluated prior to 'i' to maintain precedence:
>
> Utter utter nonsense. Your "i.e." contains no valid logic at all.
>

It's called precedence. The primary expression 'la[--i]' must be evaluated
before the much lower precedence 'la[--i]=i'.

> > 7. Expressions
> > "The precedence of expression operators is the same as the order of the
> > major subsections of this section (highest
> > precedence first). ... Otherwise the order of evaluation of
expressions is
> > undefined. In particular the compiler considers itself free to
> > compute subexpressions in the order it believes most efficient, even if
the
> > subexpressions involve side effects."
> >
> > 7.1.5
> > "A primary expression followed by an expression in square brackets is a
> > primary expression."...
>
> And?
>
> > 7.14.1 lvalue = expression
> > "The value of the expression replaces that of the object referred to by
the
> > lvalue."...
>
> And?
>
> I'm failing to see the "`lvalue' is evaluated before 'expression'"
> in the above. If it said that, you'd have a point. It doesn't, for
> a reason, and you don't, for a reason too.
>

7. clearly states that both precedence and evaluation follow the section
ordering. Therefore, 7.14.1 is evaluated after 7.1.5. I.e., the 'lvalue',
'la[--i]', is a primary expression that is evaluated prior to
'lvalue=expression', 'la[--i]=i'. You seem to still be focusing on applying
the "sequence points" concept - breaking the grammar apart into smaller
statements and asking which should come first - without taking into account
that the section ordering equals precedence equals order of evaluation.

> And you've not worked out my teaser yet either I notice.

Your "teaser" applies sequence points... Why should I bother?


Rod Pemberton

From: Phil Carmody on
"Rod Pemberton" <do_not_have(a)nowhere.cmm> writes:
> "Phil Carmody" <thefatphil_demunged(a)yahoo.co.uk> wrote in message
> news:877ioj1qmv.fsf(a)nonospaz.fatphil.org...
> > "Rod Pemberton" <do_not_have(a)nowhere.cmm> writes:
....
> > > It says 'la[--i]' is to be evaluated before 'la[--i]=i'. I.e., '--i'
> must
> > > be evaluated prior to 'i' to maintain precedence:
> >
> > Utter utter nonsense. Your "i.e." contains no valid logic at all.
>
> It's called precedence. The primary expression 'la[--i]' must be evaluated
> before the much lower precedence 'la[--i]=i'.


Are you desperately trying to flood this thread with irrelevancies
in order to hope no-one will notice your repeated error? It's failing.

I myself have already stated that due to precedence ``la[--i]'' must
be evaluated before ``la[--i]=i''. That is not being questioned.

What is being questioned is whether the ``i'' on the right of
the assignment is to be evaluated before the ``la[--i]'' on the
right. This is _not_ governed by precedence. It falls into the
'otherwise' clause, and is therefore explicitly undefined.

Do you really think that ``la[--i]'' has higher precedence than ``i''?

> > > 7. Expressions
> > > "The precedence of expression operators is the same as the order of the
> > > major subsections of this section (highest
> > > precedence first). ... Otherwise the order of evaluation of
> expressions is
> > > undefined. In particular the compiler considers itself free to
> > > compute subexpressions in the order it believes most efficient, even if
> the
> > > subexpressions involve side effects."
> > >
> > > 7.1.5
> > > "A primary expression followed by an expression in square brackets is a
> > > primary expression."...
> >
> > And?
> >
> > > 7.14.1 lvalue = expression
> > > "The value of the expression replaces that of the object referred to by
> the
> > > lvalue."...
> >
> > And?
> >
> > I'm failing to see the "`lvalue' is evaluated before 'expression'"
> > in the above. If it said that, you'd have a point. It doesn't, for
> > a reason, and you don't, for a reason too.
> >
>
> 7. clearly states that both precedence and evaluation follow the section
> ordering. Therefore, 7.14.1 is evaluated after 7.1.5. I.e., the 'lvalue',
> 'la[--i]', is a primary expression that is evaluated prior to
> 'lvalue=expression', 'la[--i]=i'. You seem to still be focusing on applying
> the "sequence points" concept - breaking the grammar apart into smaller
> statements and asking which should come first - without taking into account
> that the section ordering equals precedence equals order of evaluation.

You're clearly getting very confused. The above does not state that
the primary expression ``la[--i]'' is to be evaluated before the
primary expression ``i''. That is the issue in question. Your repeated
missing of the point is getting very very painful.

> > And you've not worked out my teaser yet either I notice.
>
> Your "teaser" applies sequence points... Why should I bother?

No sequence points were mentioned, nor needed for that issue.
Why? Because you could salvage some of your lost face if you show
the ability to actually think logically about something rather
than parroting irrelevant stuff.

Phil
--
Dear aunt, let's set so double the killer select all.
-- Microsoft voice recognition live demonstration
From: rhyde on
On Jul 29, 7:52 am, "Rod Pemberton" <do_not_h...(a)nowhere.cmm> wrote:
> "Phil Carmody" <thefatphil_demun...(a)yahoo.co.uk> wrote in message
>
> news:877ioj1qmv.fsf(a)nonospaz.fatphil.org...
>
>
>
>
>
> > "Rod Pemberton" <do_not_h...(a)nowhere.cmm> writes:
> > > "Phil Carmody" <thefatphil_demun...(a)yahoo.co.uk> wrote in message
> > >news:873aze5gms.fsf(a)nonospaz.fatphil.org...
> > > > Well, it does say that ``la[--i]'' is to be evaluated before
> > > ``la[--i]=i''.
>
> > > True, that is stated.
>
> > > > It also says that ``--i'' is to be evalutate before ``la[--i]''.
>
> > > False, that is unstated. But, it is a logical corollary to 'la[--i]'
> being
> > > evaluated.
>
> > > > That much I evidently have no issue with.
>
> > > > It does *not* say that ``la[--i]'' is to be evaluated before ``i''.
>
> > > True, that is unstated. But, if it where stated, that would contradict
> > > conditions of 'la[--i]' being evaluated prior to 'la[--i]=i'.
>
> > > It says 'la[--i]' is to be evaluated before 'la[--i]=i'. I.e., '--i'
> must
> > > be evaluated prior to 'i' to maintain precedence:
>
> > Utter utter nonsense. Your "i.e." contains no valid logic at all.
>
> It's called precedence. The primary expression 'la[--i]' must be evaluated
> before the much lower precedence 'la[--i]=i'.
>

Careful Phil, the fact that '=' has lower precedence has nothing to do
with the evaluation order. The fact that '=' defines a sequence point
is what guarantees that the left hand side will be evaluated before
the right hand side.

There are lots of examples of precedence that *fail* to guarantee
order of evaluation. A trivial example is the expression:

a*b + a*c

(assume a, b, and c can be arbitrary expressions) There is nothing
stopping the compile from pre-evaluating expression and reusing the
value on the right hand size. Indeed, most optimizing compilers will
do this. There is nothing stopping the compiler from pre-computing a
and using it in both subexpressions. Indeed, most optimizing compilers
do this. Likewise, the fact that '+' has lower precedence than '*'
does not mean that the compiler will evaluate b's value before c's.
The C standard *explicitly* leaves such evaluation orderings
undefined. What the C standard *does* discuss are sequence points.
I'd look up the term "sequence point" on the net (Wikipedia, for
example). It is an interesting read for those who make assumptions
about sub-expression evaluation order.
hLater,
Randy Hyde

From: santosh on
rhyde(a)cs.ucr.edu wrote:

> On Jul 29, 7:52 am, "Rod Pemberton" <do_not_h...(a)nowhere.cmm> wrote:
>> "Phil Carmody" <thefatphil_demun...(a)yahoo.co.uk> wrote in message
>>
>> news:877ioj1qmv.fsf(a)nonospaz.fatphil.org...
>> > "Rod Pemberton" <do_not_h...(a)nowhere.cmm> writes:
>> > > "Phil Carmody" <thefatphil_demun...(a)yahoo.co.uk> wrote in message
>> > >news:873aze5gms.fsf(a)nonospaz.fatphil.org...
>> > > > Well, it does say that ``la[--i]'' is to be evaluated before
>> > > ``la[--i]=i''.
>>
>> > > True, that is stated.
>>
>> > > > It also says that ``--i'' is to be evalutate before ``la[--i]''.
>>
>> > > False, that is unstated. But, it is a logical corollary to 'la[--i]'
>> being
>> > > evaluated.
>>
>> > > > That much I evidently have no issue with.
>>
>> > > > It does *not* say that ``la[--i]'' is to be evaluated before ``i''.
>>
>> > > True, that is unstated. But, if it where stated, that would
>> > > contradict conditions of 'la[--i]' being evaluated prior to
>> > > 'la[--i]=i'.
>>
>> > > It says 'la[--i]' is to be evaluated before 'la[--i]=i'. I.e., '--i'
>> must
>> > > be evaluated prior to 'i' to maintain precedence:
>>
>> > Utter utter nonsense. Your "i.e." contains no valid logic at all.
>>
>> It's called precedence. The primary expression 'la[--i]' must be
>> evaluated before the much lower precedence 'la[--i]=i'.
>>
>
> Careful Phil,

The statement you're responding to is from Rod Pemberton.

> the fact that '=' has lower precedence has nothing to do
> with the evaluation order. The fact that '=' defines a sequence point
> is what guarantees that the left hand side will be evaluated before
> the right hand side.

The assignment operator does *not* define a sequence point.

<snip>

From: Phil Carmody on
santosh <santosh.k83(a)gmail.com> writes:
> rhyde(a)cs.ucr.edu wrote:
> > the fact that '=' has lower precedence has nothing to do
> > with the evaluation order. The fact that '=' defines a sequence point
> > is what guarantees that the left hand side will be evaluated before
> > the right hand side.
>
> The assignment operator does *not* define a sequence point.
>
> <snip>

I occasionally wonder what I'm missing by having Randy in
my killfile, I'm sure that he does post some useful stuff
occasionally. However, replies such as yours provide useful
data points which help maintain the status quo.

Phil
--
Dear aunt, let's set so double the killer delete select all.
-- Microsoft voice recognition live demonstration
First  |  Prev  |  Next  |  Last
Pages: 9 10 11 12 13 14 15 16 17 18 19 20 21 22
Prev: masm linking from console
Next: NASM HelloWorld - DOS