Syntax for union parameter

[Rick C. Hodgin]

Suppose that array int a[] contains { 1, 2, 3 }, and int i is 0.
After the execution of a = a[i++], what should be the values in a[]?
Why?

I think a[0] contains 'U' and a[1] contains 'B'.

UB3...

After a = a[i++], the correct answer will always be:

a[0] is 1
a[1] is 1
a[2] is 3

The reasoning is the sequence of operations:

// a = a[i++];
t1 = i; // i of "i++"
i = i + 1; // ++ of "i++"
t2 = a[t1]; // value of "a[i++]"
a = t2; // stored into "a"

If C does not define this behavior to be exactly this, shame on C.

RDC defines this behavior to be exactly this ... it is ALWAYS the order of
operations as is being computed. I provide a syntax to access in-flight
values as well, through casks, so their values can be referenced later on
in the same line.

a[ti] = a[((|ifp|ti||)i)++];

Make heads or tails of that without a GUI IDE! LOL! Here it is broken
out with spacing so you can see it more clearly:

a[ti] = a[( (|ifp|ti||) i) ++];

In this case, the original value of i is intercepted by the "in flight
parameter" cask, and it is assigned to the variable name "ti". This is
the value of i before it is incremented.

Casks allow code to be injected in the middle of otherwise syntatically
correct statements, yet without affecting their syntax, hence the RDC
mandate of things always being determined as per their order of operation.

http://www.visual-freepro.org/wiki/index.php/VXB++#Introducing_the_Cask

Best regards,
Rick C. Hodgin

 

[BartC]

Suppose that array int a[] contains { 1, 2, 3 }, and int i is 0.
After the execution of a = a[i++], what should be the values in
a[]?
Why?

I think a[0] contains 'U' and a[1] contains 'B'.

UB3...

After a = a[i++], the correct answer will always be:

a[0] is 1
a[1] is 1
a[2] is 3

The reasoning is the sequence of operations:

// a = a[i++];
t1 = i; // i of "i++"
i = i + 1; // ++ of "i++"
t2 = a[t1]; // value of "a[i++]"
a = t2; // stored into "a"

Or you could just specify that the right-hand-side is evaluated first.

If C does not define this behavior to be exactly this, shame on C.

I /think/ the problem here is that the order of evaluation was unspecified.
Which later became difficult to specify because implementations already
existed that did it both ways.

(I've just tried four C compilers: 2 gave 1,1,3; the others gave 1,2,3;
while two of my own languages (the ones responsible for their own code) also
give 1,1,3 as I evaluate the right-side first.)

So it is easier to just have a rule in place saying don't do this!

This can be an advantage in fact because the compiler can choose the order
of evaluation that is most efficient, and can do certain optimisations that
might otherwise not practical.

a[ti] = a[((|ifp|ti||)i)++];

Make heads or tails of that without a GUI IDE! LOL!

Not being able to understand what should be a trivial piece of code is not a
great advert for a new language!

(By contrast, I've seen fragments of pseudo-code - made-up language designed
to express things in a clear manner and free of irrelevant detail - that
were almost identical to actual code in my languages!)

 

[James Kuyper]

On 30/01/14 07:22, Kaz Kylheku wrote:
I again apologize for my ignorance with regards to what is C and
what is C++, or what is a C standard, and what is an extension
as per Microsoft's extensions in Visual C++.

Pop quiz.

Suppose that array int a[] contains { 1, 2, 3 }, and int i is 0.

After the execution of a = a[i++], what should be the values in a[]?

Why?

Well I'm new here so I fully expect I'm setting myself up for some kind
of 'humorous aside' but ...

[i++] no change, postfix increment operator

however

[++i] also no change. prefix increment operator ... but ... but ... %-}

Your answer leaves me uncertain whether or not you understood the point
Kaz was making. Explaining a joke ruins the joke, so I apologize for the
following.

Of course I didn't understand it, obviously (!)

It wasn't obvious - I couldn't figure out what you meant, but I did get
a sense of confusion from whatever it was you were trying to say.

Interesting 'sense of humor' though.

It's not mine.

In Java

public static void main(String args[]){
int a[] = {1, 2, 3};
int i = 0;

a = a[i++];
System.out.print(a[0]);
}

prints 1

whereas

a = a[++i];
System.out.print(a[0]);

prints ... yep, 2.

Now why, given the semantics of the pre and postfix increment operators
should I have expected anything different in C. The semantics are the
same but in C the results are 'undefined'

If the results you got from Java are in fact guaranteed by the Java
standard, then it needn't be due to a difference in the semantics of the
increment operator - it could be due to a difference in the assignment
operator.

In C, i++ is an expression which has the side-effect of incrementing the
value of i, and has a value which is the same as that of i before the
increment occurred. Those two aspects of i++ are NOT perfectly
synchronized; the increment can be rearranged to occur at any time
between the previous and following sequence points. There are no
sequence points anywhere in that expression, which means that it could
occur either before or after evaluation of the value of 'i' for the
purposes of evaluating a. If the semantics of Java were the same as C
in that regard, then you would not be justified in assuming that you
would get the results you got above.

However, even if the increment and the determination of the value of
'i++' were strictly synchronized, there's another issue which would have
precisely the same effect: in C, assignment operators are allowed to
evaluate their left and right operands in either order, just like most
of the other binary operators. The only exceptions to this rule are the
||, &&, and comma operators. Function call operators are also free to
evaluate their operands in any order, but must do so prior to executing
the function call itself. On the other hand, the only trinary operator
in C, the ?: operator, is strictly ordered.

Evaluating a means something quite different from evaluating a[i++,
because they are on different sides of the assignment operator.
Evaluation of a means "determination of the location of a, so the
assignment operator knows where to store it's result", while evaluation
of a[i++] means "determination of the value stored in that location".
Those two evaluations can occur in any order, so in particular, the i++
in a[i++] might be evaluated either before or after evaluation of the
'i' in a. If Java had the same semantics, you would still not be
justified in the assumptions you made about the results of that expression.

For either of these reasons, there's two (but only two) possible results
of executing that particular piece of code. The reason for leaving these
things unspecified is to give implementations the freedom to reorder the
code, if necessary, for greater efficiency on a particular machine. One
consequence of this decision was that when the side-effect of one
sub-expression could affect the value of another sub-expression, it's
unspecified (but only unspecified) which order they occur in. Code
affected by such issues was considered too inherently confusing to
justify protecting such code


So why did the committee chose to add the following rule, making the
behavior undefined in such cases, rather than merely unspecified?

"If a side effect on a scalar object is unsequenced relative to either a
different side effect on the same scalar object or a value computation
using the value of the same scalar object, the behavior is undefined."
(6.5p2)

i++ has the side-effect of incrementing the value of the scalar object
i. Determining the value of i in a requires performing a value
computation using the value of that same scalar object. There are no
sequence points in that expression, and neither of the two
sub-expressions involving i is a sub-expression of the other, so they
are unsequenced relative to each other. Therefore, the behavior is
undefined.

As a result, there is no such thing as any particular values that
"should be" in a[]. It could contain any values whatsoever, include 3.21
or "'a' no longer has the type int[3]".

One key reason for that rule is that, depending upon the target machine,
many simple C expressions can require multiple assembly language
instructions to implement. As a result, if an optimizer is free to
intermingle instructions corresponding to one C expression with
instructions corresponding to another C expression, they could interfere
with each other. Since the committee felt that code which could be
affected by such optimizations was inherently confusing, and should
therefore be discouraged, they decided to not mandate that
implementations detect and avoid such situations.

If you care about the order in which the sub-expressions occur, split
the statement so that the order is explicitly specified. Either:

a[i+1] = a;
i++

or
temp = a;
a[i++] = temp;

One can only assume that this apparent reluctance to cause a compiler to
indicate when something is or maybe undefined ...

Often, when the C standard leaves the behavior undefined, rather than
making it a constraint violation, it was because the committee believed
that at least some of the cases covered by the rule were either
impossible to detect, or excessively difficult to detect, at compile
time. In many cases, you can show that 100% correct detection of a
violation would be equivalent to solving the halting problem. I'm not
sure if that applies here, but I wouldn't be surprised, either.

That doesn't mean that they're all impossible; many might be trivial to
detect. But if it were a constraint violation, detection in all cases
would be mandatory, even in the excessively difficult/impossible cases.
Implementations are still free to detect and warn about the cases that
are easy to detect, and many of them do so.

... is a result of the
apparent ethos of the C community that doing such a thing would impinge
on the freedom of the individual to do anything they like regardless of
how stupid it may be.

No, it's actually about giving the compiler the freedom to implement
optimizations without having to worry about whether it messes up
expressions like this. That's because, in the opinion of the committee,
writing such confusing expressions is a bad idea.

 

[Rick C. Hodgin]

a[ti] = a[((|ifp|ti||)i)++];
Make heads or tails of that without a GUI IDE! LOL!

Not being able to understand what should be a trivial piece of code is
not a great advert for a new language!

Practice, Bart. You'll get it. And don't give up so easily. Maybe you
need to wait for the GUI IDE to see understand it in the new light of
computer graphics. This is a fairly recent invention which makes it
easier for humans to relate to complex things, by using multiple colors,
shapes, and layers, assisting man by using the 35% of his brain devoted to
processing visual images. Or, we could just stick with text-based-only
languages (because those are always easy to understand, and you can do
them on a phosphorous monochrome monitors, or an ssh remote session).

Best regards,
Rick C. Hodgin

 

[James Kuyper]

Suppose that array int a[] contains { 1, 2, 3 }, and int i is 0.
After the execution of a = a[i++], what should be the values in a[]?
Why?

I think a[0] contains 'U' and a[1] contains 'B'.

UB3...

After a = a[i++], the correct answer will always be:

a[0] is 1
a[1] is 1
a[2] is 3

Not in C.

The reasoning is the sequence of operations:

// a = a[i++];
t1 = i; // i of "i++"
i = i + 1; // ++ of "i++"
t2 = a[t1]; // value of "a[i++]"
a = t2; // stored into "a"

The flaw in that reasoning is that C gives implementations greater
freedom in the order of evaluation than that. It also allows for the
possibility that some operations might involve multiple assembly
language statements (I know that you don't believe in such things, but
the C committee does) which might interfere with each other if
intermingled. Disapproving of such code, the C committee chose to allow
implementations to simplify their optimizers by not having to worry
about such issues.

....

RDC defines this behavior to be exactly this ... it is ALWAYS the order of
operations as is being computed. I provide a syntax to access in-flight
values as well, through casks, so their values can be referenced later on
in the same line.

a[ti] = a[((|ifp|ti||)i)++];

Make heads or tails of that without a GUI IDE!

That is a prime example of why the C committee didn't feel that such
code deserved protection.

 

[Rick C. Hodgin]

After a = a[i++], the correct answer will always be:
a[0] is 1
a[1] is 1
a[2] is 3

Not in C.

Representative exactly of why I'm moving to RDC.

The reasoning is the sequence of operations:
// a = a[i++];
t1 = i; // i of "i++"
i = i + 1; // ++ of "i++"
t2 = a[t1]; // value of "a[i++]"
a = t2; // stored into "a"

The flaw in that reasoning is that C gives implementations greater
freedom in the order of evaluation than that.

That is a flaw in C. If a different order is required, it should be coded
explicitly by the developer in source code. The compiler should always
do things in an explicit order, and at all times.

RDC will not allow optimizations which substitute printf() with puts(),
for example, but only ways to accomplish the exact (as indicated) steps,
as per the source code, with alternative mechanics. Still, every byte,
every function, every everything will be touched as indicated by the
developer.

It also allows for the
possibility that some operations might involve multiple assembly
language statements (I know that you don't believe in such things, but
the C committee does) which might interfere with each other if
intermingled. Disapproving of such code, the C committee chose to allow
implementations to simplify their optimizers by not having to worry
about such issues.

Hence my use of the cask. If you need an intermediate values, use the cask
to explicitly obtain exactly what you need, and don't rely on a wonky
compiler flexibility/liability which may/or-may-not work as you expect
from one version to another. D'oh! That's a no-brainer!

a[ti] = a[((|ifp|ti||)i)++];
Make heads or tails of that without a GUI IDE!

That is a prime example of why the C committee didn't feel that such
code deserved protection.

The C committee considered casks? AWESOME! I thought they were an
invention. Parallel discoveries! I love it!

Best regards,
Rick C. Hodgin

 

[Rick C. Hodgin]

[snip]
James Kuyper

When I read your posts, I'm reminded of the Voyager episode entitle, "Death
Wish," the scene where they go into a representation of the Q Continuum,
which is a little place in the middle of nowhere, yet there we see people
flipping through magazines entitled, "The Old," and "The New."

http://en.memory-alpha.org/wiki/Death_Wish_(episode)

I would welcome your experience on my project, James, but you have to
ditch the aging, legacy mindset related to the way things are in C, or
even in C++ because ... the times, they are a-changin' ...

Best regards,
Rick C. Hodgin

 

[David Brown]

Suppose that array int a[] contains { 1, 2, 3 }, and int i is 0.
After the execution of a = a[i++], what should be the values in a[]?
Why?

I think a[0] contains 'U' and a[1] contains 'B'.

UB3...

After a = a[i++], the correct answer will always be:

a[0] is 1
a[1] is 1
a[2] is 3

The reasoning is the sequence of operations:

// a = a[i++];
t1 = i; // i of "i++"
i = i + 1; // ++ of "i++"
t2 = a[t1]; // value of "a[i++]"
a = t2; // stored into "a"

If C does not define this behavior to be exactly this, shame on C.

C does not define such behaviour. By specifically saying that such code
is undefined, the C specifications give the compiler (or compiler
implementer) more leeway to generate better code.

And what would a specific definition of "a = a[i++]" give to a
language? It's a construct that would rarely be used, if ever. The
result of such an operation is not going to be clear to either the
writer or other readers - even if it were defined, it would be
obfuscated code. Anyone wanting to get the same effect would be better
off writing explicitly "temp = a[i++]; a = temp;". It would be
clearer, well-defined, and work as expected.

RDC defines this behavior to be exactly this ... it is ALWAYS the order of
operations as is being computed. I provide a syntax to access in-flight
values as well, through casks, so their values can be referenced later on
in the same line.

a[ti] = a[((|ifp|ti||)i)++];

What an extraordinarily pointless idea!

Instead of an absurdly ugly and non-intuitive syntax for something that
is almost never going to be useful, the programmer can just write out
the 3 or 4 statements explicitly.

Make heads or tails of that without a GUI IDE! LOL!

Are you are planning on entering the OCC, or aiming for an entry in

Here it is broken
out with spacing so you can see it more clearly:

a[ti] = a[( (|ifp|ti||) i) ++];

Yeah, clear as mud.

In this case, the original value of i is intercepted by the "in flight
parameter" cask, and it is assigned to the variable name "ti". This is
the value of i before it is incremented.

Casks allow code to be injected in the middle of otherwise syntatically
correct statements, yet without affecting their syntax, hence the RDC
mandate of things always being determined as per their order of operation.

Mandating the order of operations is fine in a language design - Java
has such rules, and is constructed so that there is no possibility of
undefined behaviour (for syntactically legal code, of course). C
specifically allows for undefined behaviour. There are advantages and
disadvantages of both - avoiding the possibility of undefined behaviour
can have quite significant overheads, and limits the freedom of the
language, but it can reduce some types of error.

Your "casks", however, are totally unnecessary for the aim of specifying
the order of everything.

http://www.visual-freepro.org/wiki/index.php/VXB++#Introducing_the_Cask

I looked at the page, which confirmed my first impressions from your
post. Nothing on that page gives the slightest suggestion that "casks"
could have any use, or would ever be a good choice of style.

 

[Rick C. Hodgin]

And what would a specific definition of "a = a[i++]" give to a
language? It's a construct that would rarely be used, if ever.

It's the idea that the language always processes data in a particular
way, as is applied to this one example. The bigger point is that the
data is always processed in a particular way.

a[ti] = a[( (|ifp|ti||) i) ++];

Yeah, clear as mud.

Don't use it, it's not for you.

Best regards,
Rick C. Hodgin

 

[David Brown]

After a = a[i++], the correct answer will always be:
a[0] is 1
a[1] is 1
a[2] is 3

Not in C.

Representative exactly of why I'm moving to RDC.

The reasoning is the sequence of operations:
// a = a[i++];
t1 = i; // i of "i++"
i = i + 1; // ++ of "i++"
t2 = a[t1]; // value of "a[i++]"
a = t2; // stored into "a"

The flaw in that reasoning is that C gives implementations greater
freedom in the order of evaluation than that.

That is a flaw in C. If a different order is required, it should be coded
explicitly by the developer in source code. The compiler should always
do things in an explicit order, and at all times.

Repeating a claim does not make it true.

The compiler must do what the specification says it must do for
specified behaviour, and should generate the best code it can for
implementation dependent behaviour. It can do what it likes for
undefined behaviour.

The programmer should learn to use the language and the tools.


There are many reasons why C is the language of choice when you want to
write small and fast code. The undefined behaviour and
implementation-defined behaviour in the standards is part of the reason
for that - it lets the compiler generate smaller and faster code.

RDC will not allow optimizations which substitute printf() with puts(),
for example, but only ways to accomplish the exact (as indicated) steps,
as per the source code, with alternative mechanics. Still, every byte,
every function, every everything will be touched as indicated by the
developer.

You are free to pick the constraints for your own language. But don't
expect other languages to have the same limitations, and don't be so
arrogant as to think that you know all there is to know about
programming language design and that any design decision that does not
agree with yours must be wrong.


There /are/ parts of the design of the C language that are arguably
wrong, and would not be part of a modern language design. But the
concept of undefined behaviour, and the unspecified order of events
between sequence points, are not such features.

Hence my use of the cask. If you need an intermediate values, use the cask
to explicitly obtain exactly what you need, and don't rely on a wonky
compiler flexibility/liability which may/or-may-not work as you expect
from one version to another. D'oh! That's a no-brainer!

An overly complex "solution" to a non-existent problem can well be
called a "no-brainer", but not in the sense /you/ mean.

If you need the intermediate values, do the calculation in appropriate
parts.

a[ti] = a[((|ifp|ti||)i)++];
Make heads or tails of that without a GUI IDE!

That is a prime example of why the C committee didn't feel that such
code deserved protection.

The C committee considered casks? AWESOME! I thought they were an
invention. Parallel discoveries! I love it!

No, the C committee considered specifying the execution order of code
like "a = a[i++];", and concluded that the order should /not/ be
specified in C. They did not consider "casks", or anything similar.


I have used, at least briefly, about two dozen programming languages
over the years - and I have read information about at least as many
others. The only /real/ (as distinct from "toy" languages) programming
languages I know of that have such ugly syntax are APL and Clarion.

 

[David Brown]

And what would a specific definition of "a = a[i++]" give to a
language? It's a construct that would rarely be used, if ever.

It's the idea that the language always processes data in a particular
way, as is applied to this one example. The bigger point is that the
data is always processed in a particular way.

What makes you think "casks" have any connection to this idea? I can
see that "casks" could only work if statements were processed in a
particular order - but defining the order of operations does not imply
that "casks" are needed or useful.

Note that I am not against defining the order of operations - that's a
perfectly reasonable design decision. The C designers decided against
that, in order to allow for more optimisation in the language, but you
are free to choose differently. It is only the pointless and ugly
"casks" that I think are a bad idea.

a[ti] = a[( (|ifp|ti||) i) ++];

Yeah, clear as mud.

Don't use it, it's not for you.

I cannot imagine anyone, other than yourself of course, thinking that
RDC is a good idea, so of course "casks" are not for me. The whole
"RDC" concept is just an ego boost - it is not something that will be
used by anyone else (assuming it ever gets finished). You are not
qualified to design a serious programming language, and as long as you
are so determined to reject other people's advice, you never will be.
Of course, as long as you are enjoying working on it, that's fine - we
all need a hobby.

 

[Keith Thompson]

a[ti] = a[((|ifp|ti||)i)++];
Make heads or tails of that without a GUI IDE! LOL!

Not being able to understand what should be a trivial piece of code is
not a great advert for a new language!

Practice, Bart. You'll get it. And don't give up so easily. Maybe you
need to wait for the GUI IDE to see understand it in the new light of
computer graphics. This is a fairly recent invention which makes it
easier for humans to relate to complex things, by using multiple colors,
shapes, and layers, assisting man by using the 35% of his brain devoted to
processing visual images.

[...]

So you're inventing a language that can't be used by color-blind
programmers.

 

[David Brown]

On 30/01/14 07:22, Kaz Kylheku wrote:
I again apologize for my ignorance with regards to what is C and
what is C++, or what is a C standard, and what is an extension
as per Microsoft's extensions in Visual C++.

Pop quiz.

Suppose that array int a[] contains { 1, 2, 3 }, and int i is 0.

After the execution of a = a[i++], what should be the values in
a[]?

Why?

Well I'm new here so I fully expect I'm setting myself up for some kind
of 'humorous aside' but ...

[i++] no change, postfix increment operator

however

[++i] also no change. prefix increment operator ... but ... but ... %-}

Your answer leaves me uncertain whether or not you understood the point
Kaz was making. Explaining a joke ruins the joke, so I apologize for the
following.

Here's another thing.

Let's imagine that I didn't understand what a sequence point is.
Actually I didn't but wikipedia explained it in common English rather
than some incomprehensible technobabble and now I do.

The reason that i=i++ is undefined in C is because the language
definition doesn't (apparently) specify one of the possible behaviors
preferring instead to leave it undefined. What possible reason could
there be for this? It's a well known and understood paradigm in other
languages but apparently not in C.

Some languages define the order of such statements, some do not (and
some explicitly disallow such statements at all). In no language, and
no program, is something like "i = i++" a /useful/ statement. It is
very rare that code is actually affected by such rules - and extremely
rare for clear, sensible code to be affected.

However, it is quite easy to make code where there /might/ be a hidden
dependency like this. For example, try this variation:

int a[10];
void foo(int * p, int * q) {
a[*p] = a[(*q)++];
}

As long as p and q point to different ints, the ordering does not
matter. But if q points to the same int as p, or to part of a[], then
the order /does/ matter. Such situations are extremely unlikely to
occur intentionally. By saying that the order is undefined, the
compiler can generate code that assumes the order does not matter, thus
perhaps getting faster code (it can read "*p" earlier on - on many
processors, this will give better pipelining). But if the order were
defined, then it would have to generate slower code just in case the
programmer was doing something /really/ weird.

But I've learned something, which is the whole object of the exercise so
all I can say is 'result'

If you have learned something from all this, then that's great!

 

[Rick C. Hodgin]

So you're inventing a language that can't be used by color-blind
programmers.

Sure they can use it ... it will just be more difficult (I would imagine
more or less like the way the world is for them today -- "You mean you're
inventing a traffic control system, one which will determine whether the
3,000 pound vehicle you're in should stop or not, very likely resulting
in collisions and death, and you're using red and green for your colors?
Are you serious? What about the color blind people? Have you forgotten
about them?).

Best regards,
Rick C. Hodgin

 

[Keith Thompson]

On 06/02/14 14:23, Rick C. Hodgin wrote: [...]

After a = a[i++], the correct answer will always be:

a[0] is 1
a[1] is 1
a[2] is 3

The reasoning is the sequence of operations:

// a = a[i++];
t1 = i; // i of "i++"
i = i + 1; // ++ of "i++"
t2 = a[t1]; // value of "a[i++]"
a = t2; // stored into "a"

If C does not define this behavior to be exactly this, shame on C.

It's interesting that Java, which as I recall requires strict
left-to-write evaluation and makes `a = a[i++]` well defined,
gives a different result. I'm not saying that Java gets it right
(or even that C gets it right), but even if you think the behavior
should be well defined, it's not obvious *how* it should be defined.

C does not define such behaviour. By specifically saying that such code
is undefined, the C specifications give the compiler (or compiler
implementer) more leeway to generate better code.

And what would a specific definition of "a = a[i++]" give to a
language? It's a construct that would rarely be used, if ever. The
result of such an operation is not going to be clear to either the
writer or other readers - even if it were defined, it would be
obfuscated code. Anyone wanting to get the same effect would be better
off writing explicitly "temp = a[i++]; a = temp;". It would be
clearer, well-defined, and work as expected.

Or, even better:

a = a[i+1];
i++;

(assuming that that was the intent).

[snip]

 

[Keith Thompson]

Sure they can use it ... it will just be more difficult (I would imagine
more or less like the way the world is for them today -- "You mean you're
inventing a traffic control system, one which will determine whether the
3,000 pound vehicle you're in should stop or not, very likely resulting
in collisions and death, and you're using red and green for your colors?
Are you serious? What about the color blind people? Have you forgotten
about them?).

No, that's why traffic lights are always ordered red/yellow/green from
top to bottom (at least in the US).

 

[Keith Thompson]

The reason that i=i++ is undefined in C is because the language
definition doesn't (apparently) specify one of the possible behaviors
preferring instead to leave it undefined. What possible reason could
there be for this? It's a well known and understood paradigm in other
languages but apparently not in C.

That particular example:

i=i++;

is more clearly written as:

i++;

(assuming the intent is to increment i). There's no point in assiging
the result of `i++` back to i, even if the behavior were well defined.

 

[Rick C. Hodgin]

a = a[i++];
It's interesting that Java, which as I recall requires strict
left-to-write evaluation and makes `a = a[i++]` well defined,
gives a different result. I'm not saying that Java gets it right
(or even that C gets it right), but even if you think the behavior
should be well defined, it's not obvious *how* it should be defined.

My position is this: it's patently exactly obvious.

For example, you have to compute something before you can assign it. As
a result, when the assignment time of the calculation arises, whatever
value is in i at that time is what's used.

No ambiguity whatsoever. It always works properly in all cases.

Or, even better:
a = a[i+1];
i++;
(assuming that that was the intent).

Yes. This is how such a questionable line of source code should be written.

Best regards,
Rick C. Hodgin

 

[Rick C. Hodgin]

No, that's why traffic lights are always ordered red/yellow/green from
top to bottom (at least in the US).

Not exactly, Mr. Thompason.

http://www.city-data.com/forum/general-u-s/666062-traffic-lights-pictures-your-states-region.html

In Indianapolis where I live, there is a low underpass bridge used by
trains. It is a tight, confusing intersection when all is well. Add
a little rain and it starts to flood, a little snow and people get
killed at that intersection. It has horizontal traffic lights because
it cannot take up so much space vertically and still meet height
requirements.

They are typically oriented vertically. But they are not. And I'm
sure if I was making the case for the red/green system, someone named
Keith Thompson or James Kuyper would point out that I have not
considered the times where vertical placement just isn't possible or
practical.

Best regards,
Rick C. Hodgin

 

[BartC]

a[ti] = a[((|ifp|ti||)i)++];
Make heads or tails of that without a GUI IDE! LOL!

Not being able to understand what should be a trivial piece of code is
not a great advert for a new language!

Practice, Bart. You'll get it. And don't give up so easily. Maybe you
need to wait for the GUI IDE

I read that as GUIDE. Which probably wasn't too far from what you meant.

to see understand it in the new light of
computer graphics. This is a fairly recent invention which makes it
easier for humans to relate to complex things, by using multiple colors,
shapes, and layers, assisting man by using the 35% of his brain devoted to
processing visual images. Or, we could just stick with text-based-only
languages (because those are always easy to understand,

Yes, we've only been using text-based information for a thousand years or
so, and the verbal equivalent for considerably longer.

I admit I'm biased against GUI interfaces; they're OK, but they are not that
much more sophisticated than a monkey pointing with a stick, really. Compare
with an advanced text interface (eg. English), which is vastly more capable
at expressing abstract ideas.

With GUI, you also end up doing things yourself (drag a file to waste-bin)
instead of asking the computer to do it ('del filename'). A subtle
difference because the computer will end up doing the work in both cases,
but the command version is like telling a secretary to do all the work: try
telling it instead to delete the file after noon next Friday subject to A, B
and C, then you will start to appreciate the superiority of using language!