By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
438,737 Members | 1,989 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 438,737 IT Pros & Developers. It's quick & easy.

Order of evaluation and better declaration of functions

P: n/a
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
Jul 17 '05 #1
Share this Question
Share on Google+
11 Replies


P: n/a
Bhushit Joshipura wrote:
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.

--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
Jul 17 '05 #2

P: n/a
Bhushit Joshipura wrote:

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.

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
Jul 17 '05 #3

P: n/a

"Bhushit Joshipura" <bh*****@hotmail.com> wrote in message
news:84**************************@posting.google.c om...
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)

Jul 17 '05 #4

P: n/a
On 4 Jan 2004 01:47:38 -0800, bh*****@hotmail.com (Bhushit Joshipura)
wrote in comp.lang.c:
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 news:comp.std.c++.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html
Jul 17 '05 #5

P: n/a
<Burnt by flames> Apologies!
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 assumed people would map the example to corresponding languages C,
C++, Objective C and Java. I forgot to explicitly write that.
I asked a question in comp.lang.c++ for the following possibility and ^^^^^^^^^^^^^
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
Jul 17 '05 #6

P: n/a
nos
lots of books have warnings about
making assumptions, so read up a little

"Bhushit Joshipura" <bh*****@hotmail.com> wrote in message
news:84**************************@posting.google.c om...
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

Jul 17 '05 #7

P: n/a

"Richard Heathfield" <do******@address.co.uk.invalid> wrote in message
news:bt**********@hercules.btinternet.com...
Bhushit Joshipura wrote:
A. May I know why order of evaluation of arguments is not specified in
C/C++?


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 -

Jul 17 '05 #8

P: n/a
In article <ls******************@news1.nokia.com>,
"Risto Lankinen" <rl******@hotmail.com> wrote:
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
Jul 17 '05 #9

P: n/a
Risto Lankinen wrote:

"Richard Heathfield" <do******@address.co.uk.invalid> wrote in message
news:bt**********@hercules.btinternet.com...
Bhushit Joshipura wrote:
> A. May I know why order of evaluation of arguments is not specified in
> C/C++?
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++


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

<snip>
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. :-)

--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
Jul 17 '05 #10

P: n/a
Risto Lankinen wrote:
"Richard Heathfield" <do******@address.co.uk.invalid> wrote in message
news:bt**********@hercules.btinternet.com...
Bhushit Joshipura wrote:

A. May I know why order of evaluation of arguments is not specified in
C/C++?
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.


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

--
Pull out a splinter to reply.
Jul 17 '05 #11

P: n/a
In comp.lang.c Peter Ammon <ge******@splintermac.com> wrote:
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).

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cyberspace.org | don't, I need to know. Flames welcome.
Jul 17 '05 #12

This discussion thread is closed

Replies have been disabled for this discussion.