Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Evaluation Order in Function Declaration

Reply
Thread Tools

Evaluation Order in Function Declaration

 
 
Shao Miller
Guest
Posts: n/a
 
      02-28-2012
Is the evaluation order guaranteed to be left-to-right for the
declaration of 'baz' in the following code? Or are the array size
expressions unsequenced relative to one another, as in 'a + b'? Or
something else?

#include <stdio.h>

int foo(void) { puts("foo"); return 1; }
int bar(void) { puts("bar"); return 1; }

int baz(int (* x)[foo()], int (* y)[bar()]) { return 0; }

int main(void) { return baz(0, 0); }
 
Reply With Quote
 
 
 
 
Jens Gustedt
Guest
Posts: n/a
 
      02-28-2012
Hello,

Am 02/28/2012 06:22 AM, schrieb Shao Miller:
> Is the evaluation order guaranteed to be left-to-right for the
> declaration of 'baz' in the following code? Or are the array size
> expressions unsequenced relative to one another, as in 'a + b'? Or
> something else?
>
> #include <stdio.h>
>
> int foo(void) { puts("foo"); return 1; }
> int bar(void) { puts("bar"); return 1; }
>
> int baz(int (* x)[foo()], int (* y)[bar()]) { return 0; }
>
> int main(void) { return baz(0, 0); }


Yes, not only that it is left to right, you are even allowed to use each
of the preceding identifiers in the expressions. Otherwise things like

double sum(size_t n, size_t m, double A[n][m]) { ... }

could never work reliably.

Jens

 
Reply With Quote
 
 
 
 
Kaz Kylheku
Guest
Posts: n/a
 
      02-28-2012
On 2012-02-28, Jens Gustedt <(E-Mail Removed)> wrote:
> Hello,
>
> Am 02/28/2012 06:22 AM, schrieb Shao Miller:
>> Is the evaluation order guaranteed to be left-to-right for the
>> declaration of 'baz' in the following code? Or are the array size
>> expressions unsequenced relative to one another, as in 'a + b'? Or
>> something else?
>>
>> #include <stdio.h>
>>
>> int foo(void) { puts("foo"); return 1; }
>> int bar(void) { puts("bar"); return 1; }
>>
>> int baz(int (* x)[foo()], int (* y)[bar()]) { return 0; }
>>
>> int main(void) { return baz(0, 0); }

>
> Yes, not only that it is left to right, you are even allowed to use each
> of the preceding identifiers in the expressions. Otherwise things like
>
> double sum(size_t n, size_t m, double A[n][m]) { ... }
>
> could never work reliably.


Sure they could. The above could mean that A[n][m], n and m independently
receive values from the same sources (the argument expressions). The [n][m]
doesn't have to refer to the values stored in the parameters n, and m
but rather the [n][m] can indicate additional sinks for the data flows
emanating from argument 1 and 2.

Such semantics can be hammered out. There is no end to how you can lay weasely
traps for the programmer (as the sordid history of this language shows.)
 
Reply With Quote
 
Jens Gustedt
Guest
Posts: n/a
 
      02-28-2012
Am 02/28/2012 10:31 AM, schrieb Kaz Kylheku:
> On 2012-02-28, Jens Gustedt <(E-Mail Removed)> wrote:
>> Hello,
>>
>> Am 02/28/2012 06:22 AM, schrieb Shao Miller:
>>> Is the evaluation order guaranteed to be left-to-right for the
>>> declaration of 'baz' in the following code? Or are the array size
>>> expressions unsequenced relative to one another, as in 'a + b'? Or
>>> something else?
>>>
>>> #include <stdio.h>
>>>
>>> int foo(void) { puts("foo"); return 1; }
>>> int bar(void) { puts("bar"); return 1; }
>>>
>>> int baz(int (* x)[foo()], int (* y)[bar()]) { return 0; }
>>>
>>> int main(void) { return baz(0, 0); }

>>
>> Yes, not only that it is left to right, you are even allowed to use each
>> of the preceding identifiers in the expressions. Otherwise things like
>>
>> double sum(size_t n, size_t m, double A[n][m]) { ... }
>>
>> could never work reliably.

>
> Sure they could. The above could mean that A[n][m], n and m independently
> receive values from the same sources (the argument expressions). The [n][m]
> doesn't have to refer to the values stored in the parameters n, and m
> but rather the [n][m] can indicate additional sinks for the data flows
> emanating from argument 1 and 2.


theoretically they could. pratically the standard says that the
identifier n for example is visible for the declaration of A

> Such semantics can be hammered out. There is no end to how you can lay weasely
> traps for the programmer (as the sordid history of this language shows.)


sure, I just don't see how your comment is related to the question
Shao had and how with any respect it would be helpful. You seem to
find it necessary to rant against VLA in any form you see them. Not
very helpful for anybody, probably not even for yourself.

Jens
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Order of function parameters evaluation subnet C Programming 13 03-09-2005 10:22 AM
Order of evaluation and better declaration of functions Bhushit Joshipura C Programming 26 01-21-2004 02:16 AM
Order of evaluation and better declaration of functions Bhushit Joshipura C++ 18 01-19-2004 11:44 PM
Order of function evaluation Jens.Toerring@physik.fu-berlin.de C Programming 15 10-27-2003 07:45 PM
Evaluation order for nested function calls cheeser C++ 3 10-05-2003 08:10 AM



Advertisments