Hello all,
My doubt is going to be so primitive that i ask you all to forgive me
beforehand....
Here's the code snippet:
int main()
{
int x=5;
x=x++ + ++x;
printf("%d",x);
return 0;
}
I know that the printf is going to print some value of x which none can
predict accurately for all times for all compilers....However,why i ask
this is because such type of questions keep appearing in a lot of
Question Papers....
Help me suggest a way to tackle this..
Thanks in advance!
May 21 '06
77  3608 
In article <L7******************************@bt.com>,
Richard Heathfield <in*****@invalid.invalid> wrote: Because it is not feasible to define behaviour of every possible
language construct that the grammar allows -- especially the silly
ones.
It's quite feasible, it's just not a choice that C made.
To define every possible behaviour, a programming language would have to be
a formal system. If it is a sufficiently powerful formal system, it is
either incomplete or inconsistent. That is, there will be some behaviours
that cannot be defined. And if it is not a sufficiently powerful formal
system, it loses interest.
At a pinch, I could make do with a programming language that was only
as well-defined as integer arithmetic.
-- Richard
On 22 May 2006 23:42:31 -0700, ao******@yahoo.com wrote: This is a behavior observed in MSVC and this is predictable. The
compiler is going to give me the same result whenever I execute this
code. This is predictable.
Are you prepared to debug and rewrite your code when MS releases a new
version of the compiler?
What do you mean by undefined when I am able
to define it. Do not write such irresponsible mails based on your
limitations and based on loose statements like "undefined".
Undefined is well defined ;-) Obviously you are not familiar with the
C standard. In this group, we deal with Standard C. If you want to
talk about the peculiarities of MSVC, there are a number of forums
where it's on topic.
I do not
care what is undefined as long as it works the way it is expected to
for a specific compiler.
Don't express such opinions in a job interview :-) On second thought,
go ahead - it might prevent an employer from making a costly mistake.
I encourage people to investigate this
behavior further and disseminate and find applications for such
expressions. I reiterate pls. do not write such replies.
Rgds.
--
Al Balmer
Sun City, AZ
"Dik T. Winter" <Di********@cwi.nl> wrote:
# In article <11**********************@j55g2000cwa.googlegroups .com> "Nick Keighley" <ni******************@hotmail.com> writes:
# > Dik T. Winter wrote:
# > > In article <e4**********@pc-news.cogsci.ed.ac.uk> ri*****@cogsci.ed.ac.uk (Richard Tobin) writes:
# ...
# > > > It's quite feasible, it's just not a choice that C made.
# > >
# > > Indeed. In a language like Algol 60 *each* construct had a precisely
# > > defined meaning, even the silly ones.
# >
# > I thought even Alogol-60 had holes in its semantics? Wasn't
# > call-by-name with
# > nested functions a bit hairy? This is based on a very vague memory...
#
# It was hairy, but well-defined. The problem was that it was a side-effect
# of a strict definition that was not foreseen (and that some people at that
# time thought not implementable).
45 years later and Algol-60 remains an improvement on its successors.
--
SM Ryan http://www.rawbw.com/~wyrmwif/
TEMPORARILY CLOSED
BE OPENED AFTER FIRST PERIOD ao******@yahoo.com writes: Thanks for your response. I am fully aware of the problems associated
with using such constructs. What I am trying to say is that, if we can
find out useful applications for expressions such as these, then it
makes sense for compiler writer to include this as a part of the
definition. Of course, there would still be many expressions which are
left out by compiler writers, but then a useful extension has been
made. The purpose of writing this is to arrive at some useful
extensions which would be of help to programmers rather than shutting
the door based on the current definition of the language.
Please don't top-post. Your response goes below, or interspersed with,
any quoted material (which should be trimmed to just what's relevant
to your response). See <http://www.caliburn.nl/topposting.html>.
Yes, extensions can be very useful, and some extensions can take the
form of the compiler defining behavior that is not defined by the
standard. This is explicitly allowed by the standard; C99 4p6 says:
A conforming implementation may have extensions (including
additional library functions), provided they do not alter the
behavior of any strictly conforming program.
Part of the problem is that you've picked a poor example to make the
case. The particular example we've been discussing is
x = x++ + ++x;
There's no real benefit in defining the behavior of something that
ugly; whatever it happens to do, there's a much clearer way to do
exactly the same thing, perhaps this:
x = 2 * x + 3;
But that's assuming that we're just talking about this specific case.
If you want to make a more general point, one possible extension would
be to define the order of evaluation for all expressions (say,
strictly left-to-right). A compiler that implements such an extension
would provide predictable results for some expressions that invoke
undefined behavior in standard C. The drawbacks would be that (1)
expression evaluation would likely be less efficient in some cases,
because some optimizations would be disallowed, and (2) any code that
depends on this extension would be non-portable, and would very likely
break on another implementation.
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Richard Heathfield wrote: Chris Dollin said:
Richard Heathfield wrote:
To define every possible behaviour, a programming language would
have to be a formal system. If it is a sufficiently powerful
formal
system, it is either incomplete or inconsistent.
Um ... I don't think that applies in the Goedel sense;
I think it probably does, actually, but this probably isn't the
place
to argue the toss about it. :-)
Well. One can define a complete and consistent set of rules that
describe a system accurately. You can design the set in a way that the
inconsistency in beyond the scope of the problem you are trying to
solve. (I mean you can still "add" numbers without worrying the Goedel
paradoxon)
I think that this is what a programming language should do.
--
Johannes
=============
You can have it:
Quick.
Accurate.
Inexpensive.
Pick two.
In article <L7******************************@bt.com>,
Richard Heathfield <in*****@invalid.invalid> wrote: To define every possible behaviour, a programming language would have to be
a formal system. If it is a sufficiently powerful formal system, it is
either incomplete or inconsistent. That is, there will be some behaviours
that cannot be defined. And if it is not a sufficiently powerful formal
system, it loses interest.
Richard, you are conflating the Goedel Incompleteness Theorem
and the Church-Rosser Theorem.
Goedel Incompleteness is only applicable to indefinitely large
(i.e., infinite) systems: if one is not working with an indefinitely large
system then there is no certainty that one is going to be able to
construct the unprovable statement under the Goedel system.
The Church-Rosser Theorem is more easily applied to bounded systems
[such as actual implementations], as you can take the jog into
Turing Machine emulation with a Universal Turing Machine, and then
use the theorem that shows that every UTM has the same size
to within a constant (that is dependant on the underlying implementation.)
That puts on upper bound on the size of the UTM, and allows one to draw
upon the body of works about Turing Computability subject to resource
restrictions.
Goedel Incompleteness, on the other hand, has no established upper
bound on the size of the unprovable statement: the theorem just
establishes that at least one such unprovable statement *exists*, and
does not establish that one can compute it with any particular limited
resource set.
For each finite resource [including output] deterministic computing
system, it would be possible [in a vastly larger system!] to write a
total state function that enumerated EVERY state transition --
every possible combination of values stored in memory and what the
result of each of the operations would be. The state table would be
complete and consistant... and vast, but finite. I don't think you
mean to say that the only computer systems of interest are those
which are non-deterministic or of [literally] infinite capacity.
--
Okay, buzzwords only. Two syllables, tops. -- Laurie Anderson
On 22 May 2006 23:42:31 -0700, in comp.lang.c , ao******@yahoo.com
wrote: This is a behavior observed in MSVC and this is predictable. The
compiler is going to give me the same result whenever I execute this
code.
Sure about that? What about when MS ship a patch that changes the
behaviour, or you upgrade to the latest vesion, or you turn on a
different optimising mode. Believe me, I've experienced changes of
this nature.
This is predictable. What do you mean by undefined when I am able
to define it.
Maybe, but thats not the definition of "undefined" in use in CLC.
Here, undefined means behaviour on which the C standard imposes no
requirements.
Do not write such irresponsible mails based on your
limitations and based on loose statements like "undefined". I do not
care what is undefined as long as it works the way it is expected to
for a specific compiler.
You can't guarantee this.
--
Mark McIntyre
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan
Walter Roberson said: In article <L7******************************@bt.com>,
Richard Heathfield <in*****@invalid.invalid> wrote:
To define every possible behaviour, a programming language would have to
be a formal system. If it is a sufficiently powerful formal system, it is
either incomplete or inconsistent. That is, there will be some behaviours
that cannot be defined. And if it is not a sufficiently powerful formal
system, it loses interest.
Richard, you are conflating the Goedel Incompleteness Theorem
and the Church-Rosser Theorem.
But at least I was doing so in a complete and consistent manner. :-)
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999 http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
In article <12*************@corp.supernews.com> SM Ryan <wy*****@tango-sierra-oscar-foxtrot-tango.fake.org> writes: "Dik T. Winter" <Di********@cwi.nl> wrote:
.... # > > Indeed. In a language like Algol 60 *each* construct had a precisely
# > > defined meaning, even the silly ones.
# >
# > I thought even Alogol-60 had holes in its semantics? Wasn't
# > call-by-name with
# > nested functions a bit hairy? This is based on a very vague memory...
#
# It was hairy, but well-defined. The problem was that it was a side-effect
# of a strict definition that was not foreseen (and that some people at that
# time thought not implementable).
45 years later and Algol-60 remains an improvement on its successors.
I think that is not true. Algol-68 was again a vast improvement (although
it did not have call by name). But again, it was ahead of its time. Many
people thought it not implementable, and some even did not understand the
way the syntax was written. For instance in:
'real' r;
'int' i;
i := r;
r := i;
has a syntax error on the third line (the type mismatch is not resolved by
the syntax), but not on the fourth line (here the syntax resolves the type
mismatch and also tells you what does happen in this case).
One of the biggest problem with Algol-60 was that you could use an integer
constant as an argument to a function (procedure) that could either be an
actual integer constant or a label, and the compiler would not be able to
determine what it was.
But although both Algol-60 and Algol-68 were thought to be not implementable,
I have used full implementations of both (yes, it did compile a program with
the problem above correctly, the argument was passed both as integer and as
label).
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/
Richard Heathfield wrote: Richard Tobin said:
In article <bs********************@bt.com>,
Vladimir Oka <no****@btopenworld.com> wrote:
why programming languages have undefined behavior?
Because it is not feasible to define behaviour of every possible
language construct that the grammar allows -- especially the silly
ones.
It's quite feasible, it's just not a choice that C made.
To define every possible behaviour, a programming language would have to be
a formal system. If it is a sufficiently powerful formal system, it is
either incomplete or inconsistent. That is, there will be some behaviours
that cannot be defined. And if it is not a sufficiently powerful formal
system, it loses interest.
so Alogol-68 was uninteresting...
--
Nick Keighley
Nick Keighley said: Richard Heathfield wrote:
To define every possible behaviour, a programming language would have to
be a formal system. If it is a sufficiently powerful formal system, it is
either incomplete or inconsistent. That is, there will be some behaviours
that cannot be defined. And if it is not a sufficiently powerful formal
system, it loses interest.
so Alogol-68 was uninteresting...
Since I've only just heard of it, after its (presumably) 38 years in the
field, I guess it can't have been all that earth-shattering. :-)
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999 http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
In article <TL********************@bt.com>,
Richard Heathfield <in*****@invalid.invalid> wrote: so Alogol-68 was uninteresting...
Since I've only just heard of it, after its (presumably) 38 years in the
field, I guess it can't have been all that earth-shattering. :-)
Though it was not as widely-used as it might have been, and its more
obvious innovations have not all been successful (the two-level
grammar in particular), it has had a wide-ranging influence on later
programming languages. In particular, C's type system clearly owes a
lot to Algol-68.
-- Richard
Richard Tobin wrote: In article <TL********************@bt.com>,
Richard Heathfield <in*****@invalid.invalid> wrote:
so Alogol-68 was uninteresting...
Since I've only just heard of it, after its (presumably) 38 years in the
field, I guess it can't have been all that earth-shattering. :-)
Though it was not as widely-used as it might have been, and its more
obvious innovations have not all been successful (the two-level
grammar in particular), it has had a wide-ranging influence on later
programming languages. In particular, C's type system clearly owes a
lot to Algol-68.
Rather than, say, Pascal, or Algol W, or Hoare's section of /Structured
Programming/?
--
Chris "electrick hedgehog" Dollin
"People are part of the design. It's dangerous to forget that." /Star Cops/
Richard Tobin said: In article <TL********************@bt.com>,
Richard Heathfield <in*****@invalid.invalid> wrote:
so Alogol-68 was uninteresting...
Since I've only just heard of it, after its (presumably) 38 years in the
field, I guess it can't have been all that earth-shattering. :-)
Though it was not as widely-used as it might have been, and its more
obvious innovations have not all been successful (the two-level
grammar in particular), it has had a wide-ranging influence on later
programming languages. In particular, C's type system clearly owes a
lot to Algol-68.
I had heard of Algol-68. What I had not heard of was Alogol-68. I first
presumed that the one was a typo for the other but, if that were the case,
then two people had made the same typo, which seemed unlikely. A quick
Google search revealed sufficient hits to suggest that it might be a
separate language (although I didn't read the hits terribly closely). If
so, though, it was certainly one of which I had never heard.
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999 http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
Richard Heathfield wrote: I had heard of Algol-68. What I had not heard of was Alogol-68.
I first presumed that the one was a typo for the other but,
if that were the case,
then two people had made the same typo, which seemed unlikely.
I frequently copy words from posts that I reply to.
A quick Google search revealed sufficient hits to suggest
that it might be a separate language
(although I didn't read the hits terribly closely).
Results 1 - 10 of about 76 for Alogol-68
Results 1 - 10 of about 17,600 for teh enb
Teh enb.
--
pete
pete said: Richard Heathfield wrote:
I had heard of Algol-68. What I had not heard of was Alogol-68.
I first presumed that the one was a typo for the other but,
if that were the case,
then two people had made the same typo, which seemed unlikely.
I frequently copy words from posts that I reply to.
A quick Google search revealed sufficient hits to suggest
that it might be a separate language
(although I didn't read the hits terribly closely).
Results 1 - 10 of about 76 for Alogol-68
Results 1 - 10 of about 17,600 for teh enb
Teh enb.
Yeah, fair point. My reasoning was as follows:
(1) it's probably a typo.
(2) hang on - what if it isn't? I'll look a right idiot for assuming it is.
(3) okay, quick Google search
(4) weird - it does appear to exist after all (I actually searched on
"Alogol" and got over 300 hits)
(5) post
(6) step (2) suddenly doesn't look so smart :-)
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999 http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
Chris Dollin wrote: Richard Tobin wrote:
Though it was not as widely-used as it might have been, and its more
obvious innovations have not all been successful (the two-level
grammar in particular), it has had a wide-ranging influence on later
programming languages. In particular, C's type system clearly owes a
lot to Algol-68.
Rather than, say, Pascal, or Algol W, or Hoare's section of /Structured
Programming/?
OK, I've followed pete's link, and DMR explicitly credits A68 with the
motivation for the type structure of C.
--
Chris "egglectric hedgehog" Dollin
"Who do you serve, and who do you trust?" /Crusade/
Richard Heathfield wrote:
pete said:
Richard Heathfield wrote:
I had heard of Algol-68. What I had not heard of was Alogol-68.
I first presumed that the one was a typo for the other but,
if that were the case,
then two people had made the same typo, which seemed unlikely.
I frequently copy words from posts that I reply to.
A quick Google search revealed sufficient hits to suggest
that it might be a separate language
(although I didn't read the hits terribly closely).
Results 1 - 10 of about 76 for Alogol-68
Results 1 - 10 of about 17,600 for teh enb
Teh enb.
Yeah, fair point. My reasoning was as follows:
(1) it's probably a typo.
(2) hang on - what if it isn't?
I'll look a right idiot for assuming it is.
(3) okay, quick Google search
(4) weird - it does appear to exist after all (I actually searched on
"Alogol" and got over 300 hits)
(5) post
(6) step (2) suddenly doesn't look so smart :-)
In my opinion, pretending not to understand,
seems to be one of your ways
of protesting perceived defficiencies of clarity of expression.
--
pete
pete said: In my opinion, pretending not to understand,
seems to be one of your ways
of protesting perceived defficiencies of clarity of expression.
I don't know what you mean!
:-)
Disingenuous replies are indeed part of my stock-in-trade. On this occasion,
however, it was genuine ignorance. Straight up, guv!
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999 http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
Richard Heathfield wrote: Disingenuous replies are indeed part of my stock-in-trade.
On this occasion,
however, it was genuine ignorance. Straight up, guv!
"Alogol-68" ?!!!!!!
Nobody else even noticed that it was misspelled!
--
pete
In article <bv********************@bt.com> in*****@invalid.invalid writes: Richard Tobin said:
.... Though it was not as widely-used as it might have been, and its more
obvious innovations have not all been successful (the two-level
grammar in particular), it has had a wide-ranging influence on later
programming languages. In particular, C's type system clearly owes a
lot to Algol-68.
I had heard of Algol-68. What I had not heard of was Alogol-68. I first
presumed that the one was a typo for the other but, if that were the case,
then two people had made the same typo, which seemed unlikely.
It appears that was indeed the case.
A quick
Google search revealed sufficient hits to suggest that it might be a
separate language (although I didn't read the hits terribly closely).
I have looked on quite a few on those pages, and in *all* cases it was a
typo (ALOGOL 60, ALOGOL W, ALOGOL 68...).
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/
In article <bv********************@bt.com>,
Richard Heathfield <in*****@invalid.invalid> wrote: I had heard of Algol-68. What I had not heard of was Alogol-68.
I had not noticed the misspelling.
-- Richard
Richard Heathfield wrote:
pete said:
In my opinion, pretending not to understand,
seems to be one of your ways
of protesting perceived defficiencies of clarity of expression.
I don't know what you mean!
:-)
Disingenuous replies are indeed part of my stock-in-trade.
So is sticking to your story.
I almost forgot that. :)
--
pete
On Wed, 24 May 2006 12:49:04 GMT, pete <pf*****@mindspring.com> wrote: Richard Heathfield wrote:
Disingenuous replies are indeed part of my stock-in-trade.
On this occasion,
however, it was genuine ignorance. Straight up, guv!
"Alogol-68" ?!!!!!!
Nobody else even noticed that it was misspelled!
You left me out of the survey.
--
Al Balmer
Sun City, AZ
pete wrote:
In my opinion, pretending not to understand, seems to be
one of your ways of protesting perceived defficiencies of
clarity of expression.
My friend coined a word for this, a few years back:
"willencuthery" (noun). In fact it applies to any situation
of pretending not to understand (eg: Why are you left-
shifting cout?)
"Old Wolf" <ol*****@inspire.net.nz> wrote in message
news:11**********************@u72g2000cwu.googlegr oups.com... pete wrote:
In my opinion, pretending not to understand, seems to be
one of your ways of protesting perceived defficiencies of
clarity of expression.
My friend coined a word for this, a few years back:
"willencuthery" (noun). In fact it applies to any situation
of pretending not to understand (eg: Why are you left-
shifting cout?)
I would claim that willencuthery has many sources. One topical version of
it elicits comment. Another highlights what we don't understand ...yet.
joe ao******@yahoo.com wrote: This is a behavior observed in MSVC and this is predictable. The
compiler is going to give me the same result whenever I execute this
code. This is predictable. What do you mean by undefined when I am able
to define it. Do not write such irresponsible mails based on your
limitations and based on loose statements like "undefined". I do not
care what is undefined as long as it works the way it is expected to
for a specific compiler.
Then please provide your full name so I can be sure never to employ
you.
I encourage people to investigate this
behavior further and disseminate and find applications for such
expressions. I reiterate pls. do not write such replies.
I encourage people not to waste their time in such a useless and
nonsensical manner. Spend the time learning to write correct C. This thread has been closed and replies have been disabled. Please start a new discussion. |
