Order of evaluation and better declaration of functions

[Bhushit Joshipura]

This post contains one question and one proposal.

A. May I know why order of evaluation of arguments is not specified in
C/C++?

I asked a question in comp.lang.c++ for the following possibility and
because the languages do not specify the order of evaluation, doing so
was an error.

int B::f ( int i, int j = i + 1 ) { // j defaults to i + 1
....
}

(Folks there suggested either to use polymorphism or to call
constructor of another class.)

B. If such an order is specified, we can not only default an argument
based on previous arguments, we can declare methods / functions
better. Think of this:


// file foo.h
// This example gains from fixed order of evaluation of arguments
// but it is not necessary to have fixed order if we disallow
references to
// previous arguments from an argument

(int *) B::f (
int i { //document here and assert at run time
i > 0 && i < INT_MAX
},
int j = i + 1 {
j > i || j < 0
},
int *k {
k != NULL && k!= some_global
}
) // end of argument documented assertion now return value's
turn
(
!= NULL
);

Upon execution, prologue to B::f may take each argument and assert.
The first argument can be asserted only against constants and globals.
If order of evaluation is not specified, other arguments follow the
suite
else their assertions and default assignment if any, may include
previous argument.
Then B::f's body gets executed
Then B::f's return value (if any) is checked against assertions if
any.

[I feel shy of suggesting a "default return value" for a function.]

This scheme has three advantages:
1. It facilitates communicating pre-conditions, post-conditions very
clearly (BIG plus)
2. It makes definition of function f clearer
3. Splint and other lints depend on specially annotated code to write
assumptions about the code. This approach is replacing annotation with
assertion and making code more robust.

I can see five problems with this scheme - some of them are easy to
solve
1. It may not always be possible to resolve globals and externs in a
..h file.
2. It may come in way of "counting the clock cycles" styled C because
of hidden assertions. [ A good code must have those assertions anyway.
#3 below solves this.]
3. These assertions must be "bypass-able" for released code. [However,
provision of an option in compiler would do that. Even then, all
argument related assertions are now viewable at a glance in a .h
file.]
4. It makes necessary to link the code to <assert.h> or equivalent.
[Once again, a good code must have this anyway.]
5. Function calls within assertions may become nasty. [At the worst,
we can disallow function calls there.]

Your comments?
-Bhushit

 

[Richard Heathfield]

This post contains one question and one proposal.

A. May I know why order of evaluation of arguments is not specified in
C/C++?

The two most obvious answers that spring to mind are:

1) why should it be?
2) perhaps conflicting implementations existed at the time of
standardisation, and nobody wanted to give ground in committee.

The first answer is, IMHO, compelling. There is no particular benefit to
pinning down the order of evaluation of arguments, and not doing so gives
compiler writers licence to optimise evaluation orders for their platforms.

 

[CBFalconer]

This post contains one question and one proposal.

A. May I know why order of evaluation of arguments is not specified
in C/C++?

So far so good, except that there is no language called C/C++.

I asked a question in comp.lang.c++ for the following possibility
and because the languages do not specify the order of evaluation,
doing so was an error.

int B::f ( int i, int j = i + 1 ) { // j defaults to i + 1
...
}

However this is C++ code, and makes it all OT for c.l.c.

(Folks there suggested either to use polymorphism or to call
constructor of another class.)

The language C has none of polymorphism or constructors or
classes. OT on c.l.c.

.... snip ...

Specifying order of parameter evaluation would have invalidated
much code when the standard was written. It would also restrict
future ingenuity. It is documented, so program accordingly.

f'ups set.

 

[Nick Hounsome]

This post contains one question and one proposal.

A. May I know why order of evaluation of arguments is not specified in
C/C++?

I asked a question in comp.lang.c++ for the following possibility and
because the languages do not specify the order of evaluation, doing so
was an error.

int B::f ( int i, int j = i + 1 ) { // j defaults to i + 1
...
}

(Folks there suggested either to use polymorphism or to call
constructor of another class.)

B. If such an order is specified, we can not only default an argument
based on previous arguments, we can declare methods / functions
better. Think of this:

I would guess that arguments are almost always evaluated right to left which
makes the particular example that you give here hard to do with optimal
efficiency in the general case of more complicated types.

The reason for right to left evaluation is probably mainly historical now -
For ancient C you needed to be able to deal with calling functions without a
declaration (same problem for varargs) and the simplest efficient way to do
that is to push the arguments in reverse order onto the stack so that the
first is readily findable on top.

The only reason I can think of for evaluation in arbirary order is that
modern compiler/processors tend to pass some args in registers that may also
be used for calculations and hence it may be more efficient to evaluate in
arbitrary order (But note this also favours reverse order as the registers
may be needed to calculate arguments 'later' in the arg list)

 

[Jack Klein]

This post contains one question and one proposal.

This post contains an egregious cross-post list that indicates
extremely poor usenet manners.

A. May I know why order of evaluation of arguments is not specified in
C/C++?

Even if there was a language C/C++, which there is most assuredly not,
how is this question about these two languages relevant to Cbjective C
or Java newsgroups, which are yet two other completely different
languages?

I asked a question in comp.lang.c++ for the following possibility and
because the languages do not specify the order of evaluation, doing so
was an error.

int B::f ( int i, int j = i + 1 ) { // j defaults to i + 1
...
}

(Folks there suggested either to use polymorphism or to call
constructor of another class.)

There is no polymorphism or constructors in C. That makes your post
off-topic in comp.lang.c, so we now have three of your four groups
where this doesn't belong.

B. If such an order is specified, we can not only default an argument
based on previous arguments, we can declare methods / functions
better. Think of this:

There are no such thing as default arguments in C, nor methods.

[snip code that's only a syntax error in C]

Your comments?
-Bhushit

Here are my comments:

1. Learn proper manners for posting to usenet.

2. Learn how to find an appropriate newsgroup for your question. It
is actually off-topic in comp.lang.c++, even though it is ostensibly
about the C++ language. comp.lang.c++ discusses the C++ language at
it exists, not the reasons behind the standard. The group that
discusses the past, present, and future of the C++ language standard
is

 

[Bhushit Joshipura]

Even if there was a language C/C++, which there is most assuredly not,
how is this question about these two languages relevant to Cbjective C
or Java newsgroups, which are yet two other completely different
languages?

I assumed people would map the example to corresponding languages C,
C++, Objective C and Java. I forgot to explicitly write that.
^^^^^^^^^^^^^

There is no polymorphism or constructors in C. That makes your post
off-topic in comp.lang.c, so we now have three of your four groups
where this doesn't belong.

I think now this part is clear and the question is still valid. Please
map my question to C, there *is* some substance in my question and
suggestion.

B. If such an order is specified, we can not only default an argument
based on previous arguments, we can declare methods / functions
better. Think of this:

There are no such thing as default arguments in C, nor methods.

[snip code that's only a syntax error in C]

It was bound to be a syntax error. "B." was the proposal part!

Here are my comments:

1. Learn proper manners for posting to usenet.

Apology again if I caused pain by forgetting instruction to map the
example to your language of concern.

2. Learn how to find an appropriate newsgroup for your question. It
is actually off-topic in comp.lang.c++, even though it is ostensibly
about the C++ language. comp.lang.c++ discusses the C++ language at
it exists, not the reasons behind the standard. The group that
discusses the past, present, and future of the C++ language standard
is news:comp.std.c++.

Thanks for the information.

-Bhushit

 

[nos]

lots of books have warnings about
making assumptions, so read up a little

This post contains one question and one proposal.

A. May I know why order of evaluation of arguments is not specified in
C/C++?

I asked a question in comp.lang.c++ for the following possibility and
because the languages do not specify the order of evaluation, doing so
was an error.

int B::f ( int i, int j = i + 1 ) { // j defaults to i + 1
...
}

(Folks there suggested either to use polymorphism or to call
constructor of another class.)

B. If such an order is specified, we can not only default an argument
based on previous arguments, we can declare methods / functions
better. Think of this:


// file foo.h
// This example gains from fixed order of evaluation of arguments
// but it is not necessary to have fixed order if we disallow
references to
// previous arguments from an argument

(int *) B::f (
int i { //document here and assert at run time
i > 0 && i < INT_MAX
},
int j = i + 1 {
j > i || j < 0
},
int *k {
k != NULL && k!= some_global
}
) // end of argument documented assertion now return value's
turn
(
!= NULL
);

Upon execution, prologue to B::f may take each argument and assert.
The first argument can be asserted only against constants and globals.
If order of evaluation is not specified, other arguments follow the
suite
else their assertions and default assignment if any, may include
previous argument.
Then B::f's body gets executed
Then B::f's return value (if any) is checked against assertions if
any.

[I feel shy of suggesting a "default return value" for a function.]

This scheme has three advantages:
1. It facilitates communicating pre-conditions, post-conditions very
clearly (BIG plus)
2. It makes definition of function f clearer
3. Splint and other lints depend on specially annotated code to write
assumptions about the code. This approach is replacing annotation with
assertion and making code more robust.

I can see five problems with this scheme - some of them are easy to
solve
1. It may not always be possible to resolve globals and externs in a
.h file.
2. It may come in way of "counting the clock cycles" styled C because
of hidden assertions. [ A good code must have those assertions anyway.
#3 below solves this.]
3. These assertions must be "bypass-able" for released code. [However,
provision of an option in compiler would do that. Even then, all
argument related assertions are now viewable at a glance in a .h
file.]
4. It makes necessary to link the code to <assert.h> or equivalent.
[Once again, a good code must have this anyway.]
5. Function calls within assertions may become nasty. [At the worst,
we can disallow function calls there.]

Your comments?
-Bhushit

 

[Risto Lankinen]

There is no particular benefit to
pinning down the order of evaluation of arguments, and not doing so gives
compiler writers licence to optimise evaluation orders for their

platforms.

I politely disagree. Constructs in the gray area of C++
that anyway work consistently within one compiler have
a tendency of tempting the beginning programmers into
using them thru trial-and-error. The cost of porting such
code to another compiler could be reduced significantly
if at least the most common "undefined behaviour" were
instead defined in the standard.

The usual counter-argument against defining the behaviour
of what still is labeled as undefined behaviour has outlived
its original intention of efficiency. The translation of source
language expressions is no longer one-to-one mapped with
machine instructions anyway, mostly due to the emergence
of efficient optimization techniques. The language design is
oriented towards abstraction everywhere else, so why do
we still need to stick with (largely miniscule or imaginary)
machine dependent efficiency argument when it comes to
expression evaluation?

Cheers!

- Risto -

 

[Reinder Verlinde]

The usual counter-argument against defining the behaviour
of what still is labeled as undefined behaviour has outlived
its original intention of efficiency.
[...]
The language design is
oriented towards abstraction everywhere else, so why do
we still need to stick with (largely miniscule or imaginary)
machine dependent efficiency argument when it comes to
expression evaluation?

Wouldn't it be more useful to outlaw all cases where order of evaluation
of arguments would matter? The usual argument for allowing such
constructs also has outlived its original intention of efficiency.

Reinder

 

[Richard Heathfield]

platforms.

I politely disagree. Constructs in the gray area of C++

Ah, perhaps we're suffering from crosspostitis. (In fact, this thread is
cross-posted to four groups, each for a different language!)

The usual counter-argument against defining the behaviour
of what still is labeled as undefined behaviour has outlived
its original intention of efficiency. The translation of source
language expressions is no longer one-to-one mapped with
machine instructions anyway, mostly due to the emergence
of efficient optimization techniques. The language design is
oriented towards abstraction everywhere else,

The C++ language design? Perhaps. I was thinking more of C. If you want to
persuade the C++ committee to nail down every behaviour in C++, be my
guest.

 

[Peter Ammon]

platforms.

I politely disagree. Constructs in the gray area of C++
that anyway work consistently within one compiler have
a tendency of tempting the beginning programmers into
using them thru trial-and-error. The cost of porting such
code to another compiler could be reduced significantly
if at least the most common "undefined behaviour" were
instead defined in the standard.

True, but being newbie-proof isn't, IMO, in the "philosophy" of C++.

It seems to me that the best way forward is for the compiler to emit
warnings for code that depends on the order of evaluation.

The usual counter-argument against defining the behaviour
of what still is labeled as undefined behaviour has outlived
its original intention of efficiency.

The second original counter-argument is that there's conflicting
implementations, and that still applies.

The translation of source
language expressions is no longer one-to-one mapped with
machine instructions anyway, mostly due to the emergence
of efficient optimization techniques. The language design is
oriented towards abstraction everywhere else,

Huh? Are we talking about the same C++ here?

so why do
we still need to stick with (largely miniscule or imaginary)
machine dependent efficiency argument when it comes to
expression evaluation?

Well, we don't; there are lots of languages that do specify the order of
expression evaluation in function calls. But it seems to me that there
is a real need for a language that puts performance first, and that
means enabling microoptimizations in its design. I'm not saying that C
or C++ are ideal languages in that sense, but they're pretty much the
best we've got, and there are a lot of languages where performance is a
secondary concern.

Another reason to avoid specifying this sort of thing is future
proofing. It's possible that this particular optimization will become
more valuable in the future (e.g. parallel machines might evaluate the
arguments in a different order in each thread to avoid competing for
shared resources). It's a mistake to pointlessly limit future
implementations.

Cheers!

- Risto -

-Peter

 

[Christopher Benson-Manica]

True, but being newbie-proof isn't, IMO, in the "philosophy" of C++.

Since comp.lang.c is still (gratuitously?) on the crosspost list, I'll
just note that the same could likely be said about C. Java is more
friendly than either C or C++, but users of those languages might
argue that that friendliness comes at the expense of flexibility.

It seems to me that the best way forward is for the compiler to emit
warnings for code that depends on the order of evaluation.

That might be nice. To clc: Is a diagnostic required in such
circumstances? If not, why not? (replies to this question should
abandon the crosspost).

 

[Richard Bos]

Oh, I see. Right. Well, even if a compiler can't find *every*
instance of OOE code, mightn't it still be nice to require a
diagnostic for

j=++i+++i;

Problem: how do you propose we formulate the rule deciding what to
demand a diagnostic for, and what to leave undefined, without either
only catching all the trivial, unrealistic cases like your example, or
being so complicated that it's overly hard to implement?

Richard

 

[pete]

Since comp.lang.c is still (gratuitously?) on the crosspost list, I'll
just note that the same could likely be said about C. Java is more
friendly than either C or C++, but users of those languages might
argue that that friendliness comes at the expense of flexibility.


That might be nice. To clc: Is a diagnostic required in such
circumstances? If not, why not? (replies to this question should
abandon the crosspost).

If you were writing a compiler, how would you detect the situation ?
Seems like a lot of trouble to detect
code that depends on the order of evaluation.
I have have no idea what constitutes all the different kinds of code
which depend on the order of evaluation.

/* BEGIN new.c */

#include <stdio.h>

int count(void)
{
static counter;

return counter++;
}

int main(void)
{
printf("%d %d\n", count(), count());
return 0 ;
}

/* END new.c */

 

[Christopher Benson-Manica]

int count(void)
{
static counter;

return counter++;
}

int main(void)
{
printf("%d %d\n", count(), count());
return 0 ;
}

Oh, I see. Right. Well, even if a compiler can't find *every*
instance of OOE code, mightn't it still be nice to require a
diagnostic for

j=++i+++i;

?

 

[pete]

Oh, I see. Right. Well, even if a compiler can't find *every*
instance of OOE code, mightn't it still be nice to require a
diagnostic for

j=++i+++i;

?

That's an example of undefined behavior.

I thought you you were talking about unspecified behavior
resulting from the unspecified order of evaluation
of function arguments.

 

[Christopher Benson-Manica]

I thought you you were talking about unspecified behavior
resulting from the unspecified order of evaluation
of function arguments.

Um, perhaps. My apologies.

 

[CBFalconer]

.... snip ...


That might be nice. To clc: Is a diagnostic required in such
circumstances? If not, why not? (replies to this question
should abandon the crosspost).

That would be pleasant. First, however, please describe how you
decide that proposition for:

foobar(foo(*glorp) - bar(*glorp));

when foo, bar, foobar are in other source files, although you have
proper prototypes. Omit no detail of the decision process. Note
that the other files may not even have been written yet.

 

[Christopher Benson-Manica]

That would be pleasant. First, however, please describe how you
decide that proposition for:

foobar(foo(*glorp) - bar(*glorp));

when foo, bar, foobar are in other source files, although you have
proper prototypes. Omit no detail of the decision process. Note
that the other files may not even have been written yet.

See my other reply where I admit that my original suggestion was
fatally flawed for precisely this reason. Of course, divine
intervention is always an option, but the Standard doesn't specify
which deity should be invoked

(seriously, apparently I'm quite clue-impaired today - sorry and
thanks!)

 

[Jerry Coffin]

[ ... ]

That might be nice. To clc: Is a diagnostic required in such
circumstances? If not, why not?

No -- order of evaluation is unspecified behavior. If the output
depends on unspecified behavior, the code is not strictly conforming,
but no diagnostic is required. It's not required because nothing in the
standard requires it.

(replies to this question should abandon the crosspost).

I've trimmed the cross-post to c.l.c and c.l.c++. C++ doesn't define
"strictly conforming", but otherwise it applies to both. Even without a
specific phrase to denote it, many C++ programmers are quite interested
in writing code that is maximally portable, so the concept seems (to me)
to remain relevant.