By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
435,241 Members | 799 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 435,241 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
Nov 14 '05 #1
Share this Question
Share on Google+
26 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
Nov 14 '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!
Nov 14 '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)

Nov 14 '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
Nov 14 '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
Nov 14 '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

Nov 14 '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 -

Nov 14 '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
Nov 14 '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
Nov 14 '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.
Nov 14 '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.
Nov 14 '05 #12

P: n/a
Christopher Benson-Manica wrote:

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


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 */

--
pete
Nov 14 '05 #13

P: n/a
pete <pf*****@mindspring.com> spoke thus:
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;

?

--
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.
Nov 14 '05 #14

P: n/a
Christopher Benson-Manica wrote:

pete <pf*****@mindspring.com> spoke thus:
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;

?


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.

--
pete
Nov 14 '05 #15

P: n/a
pete <pf*****@mindspring.com> spoke thus:
I thought you you were talking about unspecified behavior
resulting from the unspecified order of evaluation
of function arguments.


Um, perhaps. My apologies.

--
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.
Nov 14 '05 #16

P: n/a
Christopher Benson-Manica <at***@nospam.cyberspace.org> wrote:
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
Nov 14 '05 #17

P: n/a
Christopher Benson-Manica wrote:
Peter Ammon <ge******@splintermac.com> wrote:
.... snip ...
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).


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.

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

P: n/a
CBFalconer <cb********@yahoo.com> spoke thus:
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!)

--
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.
Nov 14 '05 #19

P: n/a
In article <bu**********@chessie.cirr.com>, at***@nospam.cyberspace.org
says...

[ ... ]
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?


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.

--
Later,
Jerry.

The universe is a figment of its own imagination.
Nov 14 '05 #20

P: n/a

"Jerry Coffin" <jc*****@taeus.com> wrote in message news:MP************************@news.clspco.adelph ia.net...
It's not required because nothing in the
standard requires it.


Actually, the omission of a defined behavior in the standard is UNDEFINED
BEHAVIOR. The ordering of operations is specifically stated as being arbitrary.
Nov 14 '05 #21

P: n/a
In article <40***********************@news.newshosting.com> ,
ro*@sensor.com says...

"Jerry Coffin" <jc*****@taeus.com> wrote in message news:MP************************@news.clspco.adelph ia.net...
It's not required because nothing in the
standard requires it.


Actually, the omission of a defined behavior in the standard is UNDEFINED
BEHAVIOR. The ordering of operations is specifically stated as being arbitrary.


Perhaps you should have actually read what I said -- I said that the
order of evaluation of subexpressions is unspecified. If you want that
more exactly, the C standard says (6.5/3):

Except as specified later (for the function call (), &&, ||, ?:
and comma operators), the order of evaluation of subexpressions
and the order in which side effect take place are both
unspecified.

The bit you've quoted above was referring specifically to whether there
was a requirement for an implementation to issue a diagnostic when the
output depends upon unspecified behavior. As I said, the answer is no,
and the reason is because no part of the standard requires a diagnostic.

The omission of behavior leading to undefined behavior ONLY relates to
the behavior the program at run time, NOT to behavior during
translation. The requirement for diagnostics is (5.1.1.3/1):

A conforming implementation shall produce at least one diagnostic
message (identified in an implementation defined manner) if a
preprocessing translation unit or translation unit contains a
violation of any syntax rule or constraint, even if the behavior
is also explicitly specified as undefined or implementation-
defined. Diagnostic messages need not be produced in other
circumstances.
Therefore, (as I said before) a diagnostic is not required because
nothing says it is -- i.e. there is no constraint (and clearly no syntax
rule) that says the output of a program cannot depend upon unspecified
behavior. Therefore, this is one of those "other circumstances" in
which a diagnostic need not be produced.

--
Later,
Jerry.

The universe is a figment of its own imagination.
Nov 14 '05 #22

P: n/a
Christopher Benson-Manica <at***@nospam.cyberspace.org> wrote in message news:<bu**********@chessie.cirr.com>...
pete <pf*****@mindspring.com> spoke thus:
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;


That expression does require a diagnostic. ;)

--
Peter
Nov 14 '05 #23

P: n/a
> 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;

?


Error: invalid lvalue in increment
Nov 14 '05 #24

P: n/a
On Mon, 19 Jan 2004 20:21:24 GMT in comp.lang.c++, Jerry Coffin
<jc*****@taeus.com> was alleged to have written:
Therefore, (as I said before) a diagnostic is not required because
nothing says it is


That's exactly correct, but not terribly informative. I'm think the
poster asking "why not" would like to know why the standard doesn't
require it. http://www.netfunny.com/rhf/jokes/98/Aug/sales.html

For one reason, because the standard generally requires a diagnostic
only for programs that are ill-formed, and this isn't.

For another, because it's unreasonable to expect the compiler to be able
to figure it out. Should a nuisance warning be produced for
int i = f() + g();
Nov 14 '05 #25

P: n/a
Peter Nilsson <ai***@acay.com.au> spoke thus:
j=++i+++i;
That expression does require a diagnostic. ;)


foo.c:4: error: you are dumb

;)

--
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.
Nov 14 '05 #26

P: n/a
Christopher Benson-Manica wrote:
Peter Nilsson <ai***@acay.com.au> spoke thus:

j=++i+++i;


That expression does require a diagnostic. ;)

foo.c:4: error: you are dumb

;)


foo.c:4: error: you lied when you told me this was a program

--
My address is yvoregnevna gjragl-guerr gjb-gubhfnaq guerr ng lnubb qbg pbz
Note: Rot13 and convert spelled-out numbers to numerical equivalents.
Nov 14 '05 #27

This discussion thread is closed

Replies have been disabled for this discussion.