Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Newsgroups | comp.lang.c |
| Subject | Re: Unspecified Behaviors in C90 - part 3 |
| Date | 2015-07-16 21:17 -0400 |
| Organization | A noiseless patient Spider |
| Message-ID | <mo9l06$ntj$1@dont-email.me> (permalink) |
| References | (4 earlier) <d5963c50-6159-4137-940d-f5d08a0a257e@googlegroups.com> <mo3fka$bds$1@dont-email.me> <45ba9b21-0f12-4662-b89a-9f38c63a9486@googlegroups.com> <mo7d96$2pm$1@dont-email.me> <7836b7da-7660-443a-bece-c85e053014e3@googlegroups.com> |
On 07/16/2015 08:10 PM, David Kleinecke wrote:
> On Wednesday, July 15, 2015 at 9:53:28 PM UTC-7, James Kuyper wrote:
>> On 07/15/2015 10:38 PM, David Kleinecke wrote:
...
>>> What about
>>> y = f(g(x),h(x));
>>> where g and h have different non-commutive side-effects on something
>>> else? Say g(x) = {y=y+2} and h(x) = {y=3*y}
>>
>> If the order matters, then write your code in such a way that it has the
>> sequence points needed to make the order you want mandatory:
>>
>> temp1 = g(x);
>> y = f(temp1, h(x));
>>
>> When you don't care about the order, use constructs with unspecified
>> order of evaluation, leaving the compiler is free to optimize the order.
>> When you do care about the order, use constructs that only allow the
>> order you need to have happen. It's not rocket science.
>
> But it might be very helpful if to know if the orde could be
> assumed.
I suppose it might be. For that matter, he moon might be made of green
cheese. It would be helpful if you could articulate a plausible reason
why it would be helpful.
It seems to me that the only plausible consequence of requiring
implementations to document rules that could be used to determine the
order of evaluation, is that some people will check those rules, and if
the order selected by a given implementation happens to be the one that
they need, they'll write y = f(g(), h()). That's bad - if the order
matters, they should write code that explicitly forces the functions to
be called in the desired order.
--
James Kuyper
Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Unspecified Behaviors in C90 - part 3 David Kleinecke <dkleinecke@gmail.com> - 2015-07-09 11:21 -0700
Re: Unspecified Behaviors in C90 - part 3 James Kuyper <jameskuyper@verizon.net> - 2015-07-09 14:54 -0400
Re: Unspecified Behaviors in C90 - part 3 Richard Heathfield <rjh@cpax.org.uk> - 2015-07-09 21:38 +0100
Re: Unspecified Behaviors in C90 - part 3 raltbos@xs4all.nl (Richard Bos) - 2015-07-13 21:22 +0000
Re: Unspecified Behaviors in C90 - part 3 David Kleinecke <dkleinecke@gmail.com> - 2015-07-14 08:21 -0700
Re: Unspecified Behaviors in C90 - part 3 Keith Thompson <kst-u@mib.org> - 2015-07-14 08:48 -0700
Re: Unspecified Behaviors in C90 - part 3 David Kleinecke <dkleinecke@gmail.com> - 2015-07-14 09:33 -0700
Re: Unspecified Behaviors in C90 - part 3 Richard Heathfield <rjh@cpax.org.uk> - 2015-07-14 18:08 +0100
Re: Unspecified Behaviors in C90 - part 3 David Kleinecke <dkleinecke@gmail.com> - 2015-07-15 19:38 -0700
Re: Unspecified Behaviors in C90 - part 3 James Kuyper <jameskuyper@verizon.net> - 2015-07-16 00:47 -0400
Re: Unspecified Behaviors in C90 - part 3 David Kleinecke <dkleinecke@gmail.com> - 2015-07-16 17:10 -0700
Re: Unspecified Behaviors in C90 - part 3 James Kuyper <jameskuyper@verizon.net> - 2015-07-16 21:17 -0400
Re: Unspecified Behaviors in C90 - part 3 maddoxr@acm.org - 2015-07-17 07:43 -0700
Re: Unspecified Behaviors in C90 - part 3 Richard Heathfield <rjh@cpax.org.uk> - 2015-07-16 09:35 +0100
Re: Unspecified Behaviors in C90 - part 3 David Kleinecke <dkleinecke@gmail.com> - 2015-07-16 17:18 -0700
Re: Unspecified Behaviors in C90 - part 3 Richard Heathfield <rjh@cpax.org.uk> - 2015-07-17 01:45 +0100
Re: Unspecified Behaviors in C90 - part 3 James Kuyper <jameskuyper@verizon.net> - 2015-07-16 21:19 -0400
Re: Unspecified Behaviors in C90 - part 3 James Kuyper <jameskuyper@verizon.net> - 2015-07-17 12:14 -0400
Re: Unspecified Behaviors in C90 - part 3 Keith Thompson <kst-u@mib.org> - 2015-07-17 11:00 -0700
Re: Unspecified Behaviors in C90 - part 3 raltbos@xs4all.nl (Richard Bos) - 2015-07-19 21:24 +0000
Re: Unspecified Behaviors in C90 - part 3 Keith Thompson <kst-u@mib.org> - 2015-07-16 07:40 -0700
Re: Unspecified Behaviors in C90 - part 3 David Kleinecke <dkleinecke@gmail.com> - 2015-07-16 17:20 -0700
Re: Unspecified Behaviors in C90 - part 3 Richard Heathfield <rjh@cpax.org.uk> - 2015-07-17 01:49 +0100
Re: Unspecified Behaviors in C90 - part 3 Keith Thompson <kst-u@mib.org> - 2015-07-14 11:23 -0700
Re: Unspecified Behaviors in C90 - part 3 James Kuyper <jameskuyper@verizon.net> - 2015-07-14 15:11 -0400
Re: Unspecified Behaviors in C90 - part 3 David Kleinecke <dkleinecke@gmail.com> - 2015-07-15 19:46 -0700
Re: Unspecified Behaviors in C90 - part 3 James Kuyper <jameskuyper@verizon.net> - 2015-07-16 01:50 -0400
Re: Unspecified Behaviors in C90 - part 3 David Kleinecke <dkleinecke@gmail.com> - 2015-07-16 17:15 -0700
Re: Unspecified Behaviors in C90 - part 3 Richard Heathfield <rjh@cpax.org.uk> - 2015-07-17 01:39 +0100
Re: Unspecified Behaviors in C90 - part 3 James Kuyper <jameskuyper@verizon.net> - 2015-07-16 22:26 -0400
Re: Unspecified Behaviors in C90 - part 3 raltbos@xs4all.nl (Richard Bos) - 2015-07-19 21:22 +0000
Re: Unspecified Behaviors in C90 - part 3 James Kuyper <jameskuyper@verizon.net> - 2015-07-19 17:57 -0400
csiph-web