Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > New C operator -- would it be a good idea?

Reply
Thread Tools

New C operator -- would it be a good idea?

 
 
mike3
Guest
Posts: n/a
 
      09-10-2012
Hi.

I was wondering about this. I saw this posting on this site:

http://stackoverflow.com/questions/1...-this-operator

where they were mentioning a fake "operator", an artifact of how the C
language is interpreted, that looked like it caused the value of a
variable to "go to" another. Namely, "x --> 0" in the code was just
"x-- > 0", giving it the appearance of having the effect of
"incrementing x toward 0". Now, I was wondering: would this be a good
idea for a new real operator for the C language? Namely, "a -->
b" (and "b <-- a") as real operators that could increment a toward b.
Or would it be pretty worthless?

 
Reply With Quote
 
 
 
 
Kaz Kylheku
Guest
Posts: n/a
 
      09-11-2012
On 2012-09-10, mike3 <(E-Mail Removed)> wrote:
> Hi.
>
> I was wondering about this. I saw this posting on this site:
>
> http://stackoverflow.com/questions/1...-this-operator
>
> where they were mentioning a fake "operator", an artifact of how the C
> language is interpreted, that looked like it caused the value of a
> variable to "go to" another. Namely, "x --> 0" in the code was just
> "x-- > 0", giving it the appearance of having the effect of
> "incrementing x toward 0". Now, I was wondering: would this be a good
> idea for a new real operator for the C language? Namely, "a -->
> b" (and "b <-- a") as real operators that could increment a toward b.
> Or would it be pretty worthless?


I can give you five reasons why not.

1. It would be worthless because using it would make your code nonportable to all
the compilers which have decided to ignore implementing such a thing.
The best feature of C is stability, and the best dialect for that is ISO C90,
(with perhaps some very judicious use of new-fangled libraries from C99 and C11.)

2. The --> and <-- syntax has an existing meaning. It is tokenized as {--}{>}
and {<}{--}. The expression a-->b is already valid C. It means (a--) > (b).
In other words, decrement a, and test whether the prior value is greater than b.
So your proposal horribly breaks the current language, making it a complete
nonstarter.

3. Not having b <-- a, you have to write something like a = (a < b) ? a + 1 : a - 1;
This is not a big deal and you can hide it behind a macro, except that it evaluates
a twice:

#define INCTOWARD(A, B) ((A) = (A) < (B) ? (A) + 1 : (A) - 1)

See? You can implement the operator in C already, just not with the syntax you want,
and with a small semantic concession. But this means that the --> operator
does not express anything which cannot be expressed already, it just makes a
small, incremental semantic improvement over the macro. A small, incremental
improvement is harder to justify. Moreover, the syntax that you want breaks
the existing syntax (point 2 above), whereas the INCTOWARD macro doesn't.

4. There is no corresponding machine instruction in any popular machine
instruction set, so you're not going to get better code by providing an inctoward
operator in the language. And even if there is a single machine instruction
for doing (A < B ? A + 1 : A - 1), a compiler just has to recognize this
syntax tree pattern, and check a few constraints and then use the
instruction. It is not strictly necessary to have a dedicated operator.
For instance, some instruction sets have a division instruction which yields both
the quotient and the modulus. Compilers recognize code like
a = b / c; d = b % c and emit just one division instruction from which the
quotient and modulus are obtained for a and d.

5. A trivial new arithmetic operator is not going to lend expressivity to the C language.
And anyway, programmers don't need C to be expressive. By and large they
need it to be a "portable assembler". If you want expressivity, you invent
another programming language and then interpret it with C, or compile it to C.
That language can easily have an A <-- B operator, which expands into
the appropriate C (with clean evaluation semantics and everything).
 
Reply With Quote
 
 
 
 
Keith Thompson
Guest
Posts: n/a
 
      09-11-2012
"Scott Fluhrer" <(E-Mail Removed)> writes:
[...]
> However, if we have a built-in 'b <-- a' operator, well, the language has to
> specify exactly what the behavior is (and if it makes it
> unspecified/implemented-defined or undefined, well, that means that the
> programmer generally can't depend on it).

[...]

And of course we can't use that syntax for a new operator, since
b <-- a
already has a well defined meaning.

(Conceivably you could define a new "<--" operator that's 100%
compatible with all possible occurrences of "< --", but I'm skeptical
that that would be both possible and useful.)

--
Keith Thompson (The_Other_Keith) http://www.velocityreviews.com/forums/(E-Mail Removed) <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
BartC
Guest
Posts: n/a
 
      09-11-2012


"mike3" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Hi.
>
> I was wondering about this. I saw this posting on this site:
>
> http://stackoverflow.com/questions/1...-this-operator
>
> where they were mentioning a fake "operator", an artifact of how the C
> language is interpreted, that looked like it caused the value of a
> variable to "go to" another. Namely, "x --> 0" in the code was just
> "x-- > 0", giving it the appearance of having the effect of
> "incrementing x toward 0". Now, I was wondering: would this be a good
> idea for a new real operator for the C language? Namely, "a -->
> b" (and "b <-- a") as real operators that could increment a toward b.
> Or would it be pretty worthless?


Why do you need two versions? (Namely, --> and <--).

Do you mean the operator increments an lvalue so that it converges towards
another given value?

This can be done using:

a += sign(b-a);

where sign() returns (-1,0,1) depending on whether it's argument is
negative, zero or positive.

I doubt whether sign() is already lurking in the standard library somewhere
(a version that takes an integer argument), but if not, that sounds a far
more useful addition. And using function syntax, can also easily be added as
a user function without having to hang about a couple of decades until it's
part of the language (or, more likely, until it's not).

--
Bartc

 
Reply With Quote
 
Malcolm McLean
Guest
Posts: n/a
 
      09-11-2012
בתאריך יום שלישי, 11 בספטמבר 2012 22:33:30 UTC+1, מאת Bart:
> "mike3" <(E-Mail Removed)> wrote in message
>
> I doubt whether sign() is already lurking in the standard library somewhere
>

It's a missing macro. min, max, PI, uniform, clamp, lerp and round should all
have been inthe original language, along with sign.
 
Reply With Quote
 
mike3
Guest
Posts: n/a
 
      09-11-2012
On Sep 11, 1:24*pm, Kaz Kylheku <(E-Mail Removed)> wrote:
> On 2012-09-10, mike3 <(E-Mail Removed)> wrote:
>
> > Hi.

>
> > I was wondering about this. I saw this posting on this site:

>
> >http://stackoverflow.com/questions/1...name-of-this-o...

>
> > where they were mentioning a fake "operator", an artifact of how the C
> > language is interpreted, that looked like it caused the value of a
> > variable to "go to" another. Namely, "x --> 0" in the code was just
> > "x-- > 0", giving it the appearance of having the effect of
> > "incrementing x toward 0". Now, I was wondering: would this be a good
> > idea for a new real operator for the C language? Namely, "a -->
> > b" (and "b <-- a") as real operators that could increment a toward b.
> > Or would it be pretty worthless?

>
> I can give you five reasons why not.
>
> 1. It would be worthless because using it would make your code nonportable to all
> * *the compilers which have decided to ignore implementing such a thing.
> * *The best feature of C is stability, and the best dialect for that is ISO C90,
> * *(with perhaps some very judicious use of new-fangled libraries from C99 and C11.)
>


So does this mean using C99, etc. is bad, then? If not, then how come
more compiler
developers would implement C99, etc. stuff and not --> if --> became a
real part of the
C language?

> 2. The --> and <-- syntax has an existing meaning. It is tokenized as {--}{>}
> * *and {<}{--}. *The expression a-->b is already valid C. It means (a--) > (b).
> * *In other words, decrement a, and test whether the prior value is greater than b.
> * *So your proposal horribly breaks the current language, making it acomplete
> * *nonstarter.
>


So make it ==> and <==.

> 3. Not having b <-- a, you have to write something like a = (a < b) ? a+ 1 : a - 1;
> * *This is not a big deal and you can hide it behind a macro, except that it evaluates
> * *a twice:
>
> * * *#define INCTOWARD(A, B) ((A) = (A) < (B) ? (A) + 1 : (A) - 1)
>
> * *See? You can implement the operator in C already, just not with the syntax you want,
> * *and with a small semantic concession. But this means that the --> operator
> * *does not express anything which cannot be expressed already, it just makes a
> * *small, incremental semantic improvement over the macro. A small, incremental
> * *improvement is harder to justify. Moreover, the syntax that you want breaks
> * *the existing syntax (point 2 above), whereas the INCTOWARD macro doesn't.
>


True. But could the compiler optimize it better (e.g. if it's used in
a loop) if it were
a builtin?

> 4. There is no corresponding machine instruction in any popular machine
> * *instruction set, so you're not going to get better code by providing an inctoward
> * *operator in the language. *And even if there is a single machineinstruction
> * *for doing (A < B ? A + 1 : A - 1), a compiler just has to recognize this
> * *syntax tree pattern, and check a few constraints and then use the
> * *instruction. It is not strictly necessary to have a dedicated operator.
> * *For instance, some instruction sets have a division instruction which yields both
> * *the quotient and the modulus. Compilers recognize code like
> * *a = b / c; d = b % c and emit just one division instruction from which the
> * *quotient and modulus are obtained for a and d.
>


This is probably one of the best points against this. All other C
operators have some
kind of equivalent machine instruction on most machines, or close
enough. So yes, I'd
admit, this may be a downside.

> 5. A trivial new arithmetic operator is not going to lend expressivity tothe C language.
> * *And anyway, programmers don't need C to be expressive. By and large they
> * *need it to be a "portable assembler". If you want expressivity, you invent
> * *another programming language and then interpret it with C, or compile it to C.
> * *That language can easily have an A <-- B operator, which expands into
> * *the appropriate C (with clean evaluation semantics and everything)..


I thought it'd be kind of neat, but maybe it isn't really necessary.
I'd wonder, how
often does it come up that you need to increment one variable "toward"
another, i.e.
make one "go to" another? Though I haven't programmed a big diversity
of things,
it dosn't seem to be super often, unlike conventional increments.
 
Reply With Quote
 
mike3
Guest
Posts: n/a
 
      09-11-2012
On Sep 11, 1:57*pm, "Scott Fluhrer" <(E-Mail Removed)> wrote:
> "Kaz Kylheku" <(E-Mail Removed)> wrote in message
>
> news:(E-Mail Removed)...
>
>
>
> > 3. Not having b <-- a, you have to write something like a = (a < b) ?a +
> > 1 : a - 1;
> > * This is not a big deal and you can hide it behind a macro, except that
> > it evaluates
> > * a twice:

>
> > * * #define INCTOWARD(A, B) ((A) = (A) < (B) ? (A) + 1 : (A) - 1)

>
> That gives us Yet Another reason (beyond what Kaz and I already listed):
> what exactly is the desired behavior? *Specifically, what should the
> operator do if a==b initially?
>
> My longhand version assumed one behavior (a remains the same), while Kaz's
> version assumed another (a is decremented). *Which is correct? *Well,that
> depends entirely on what the original programmer meant; in longhand, he can
> easily select either behavior (or something else entirely if that's
> appropriate).
>
> However, if we have a built-in 'b <-- a' operator, well, the language hasto
> specify exactly what the behavior is (and if it makes it
> unspecified/implemented-defined or undefined, well, that means that the
> programmer generally can't depend on it).
>
> So, to that extent, this proposed built-in would have less expressiveness
> than what's already in the language.
>


What I was thinking of was that a --> b when a == b should leave a
unchanged.
Because the idea is that with repeated application, a converges to b,
or
a "goes to" b. So when a == b, a should remain unchanged, as it is
"already
there".

However, as for this "expressiveness" issue: the question comes down
to whether
or not it'd be a good idea to have certain things made into a short-
hand, easily-
available form or not. That is, is it more _convenient_ -- does it
make things
_easier_ if we had -->. Wouldn't it be nice to know it's there if you
need it,
so you don't have to code that extra macro or whatever?

I do however, wonder in light of this point, which kind of what-to-do-
when-the-
values-are-equal behavior is used most often in actual real uses of
this operation
(written without this operat_or_, of course).
 
Reply With Quote
 
mike3
Guest
Posts: n/a
 
      09-12-2012
On Sep 11, 4:27*pm, (E-Mail Removed) (Gordon Burditt) wrote:
> >http://stackoverflow.com/questions/1...name-of-this-o...

>
> > where they were mentioning a fake "operator", an artifact of how the C
> > language is interpreted, that looked like it caused the value of a
> > variable to "go to" another.

>
> You mean, like an assignment statement?
>


No, more like causing the value of one to change incrementally toward
that of another (though in this case, the second "operand" was a
constant integer literal and not a variable...).

> > Namely, "x --> 0" in the code was just
> > "x-- > 0", giving it the appearance of having the effect of
> > "incrementing x toward 0".

>
> That doesn't make a lot of sense. *What's the difference
> between "incrementing x toward 0" and "decrementing x toward 0",
> and if there is no difference, why not? *And what's the difference
> between either of them and "decrementing x toward Paris, France"?
>


True, my wording isn't quite right. Think about "stepping x closer to
0".

> > Now, I was wondering: would this be a good
> > idea for a new real operator for the C language?

>
> No. *a-->b already has a defined meaning. *An important consideration
> for standards is not breaking existing code.
>


So we could use "==>" instead.

> As far as I know, nothing conflicts with using :=: as an operator,
> as in:
> * * * * b :=: a;
> which might or might not mean to take the reciprocal of the
> base-pi logarithm of each value, then swap them. *How did we
> possibly get along without that?
>


So you've never encountered a situation in which you have to step
the value of a variable closer to that of another?

Oen situation, and the one that inspired this post, along with the
discusson on stackoverflow, is that of looping or moving between two
coordinate points. Suppose you have coordinates x0 and x1 and want to
move between them. Let x be your current position. To move in a unit
step
toward x1:

x --> x1; (or x ==> x1

To move the other way, toward x0:

x --> x0; (or x ==> x0

or, perhaps if you think of this as "backwards" movement,

x0 <-- x; (or x0 <== x

Note that with this, the order of x0 and x1 does not matter,
which is the point here. You don't have to swap them or check
their order or something like that in order to move x toward
one or the other. E.g. if x1 > x0 you can move toward x0
with the same operator as if x1 were < x0, regardless of the
value of x.

> > Namely, "a -->
> > b" (and "b <-- a") as real operators that could increment a toward b.

>
> Please define "increment a toward b", without using the phrases
> "increment toward", "decrement toward", or "crement toward" (which
> I'll assume mean "a suffusion of Ankylosaurus poop") in the
> definition. *What happens if a and b are equal? *What happens if b
> is NaN? *(I am assuming this operator can apply to floating-point
> numbers as well). *What happens if a = 1.25 and b = 1.0? *Does a
> become 0.25? *(increment a toward *and possibly past* b)? *What
> happens if b is +Inf (and floating-point) and a is INT_MAX (and
> of type int?)
>


crement a toward b

Heh. What it means is to step a by a unit step, same size as ++
or -- (i.e. by 1), in the direction that brings the value of a
closer to the value of b, or leaves a unchanged if a == b.

I suspect it wouldn't work so well for floats, and would probably
have to be limited to integer types. Though I suppose one could
make it so that in your example if we took a --> b we'd get
a = 1.0 at the end, i.e. step by 1s, but if the result is within
1 of b, then make the result equal to b. Though what to do if a
is an integer??? Perhaps make it so that a can be stepped to within
1 of b, and then it stops there just as if a == b. Though, I wonder,
how'd we handle something like b = 1.5e+9 and b is a 32-bit float?
Step to the rounded value of 1,500,000,000? And don't forget
issues related to the binary nature of the floats... Oy, this is
a problem. Perhaps it'd be best if it required a and b to be of the
same type.

And I suspect it wouldn't be as useful for floats as for integers
unless there were some way to control the size of the step.

> > Or would it be pretty worthless?

>
> There are very few places I can think I'd want to use this,
> even if it didn't break existing code.


 
Reply With Quote
 
Nick Keighley
Guest
Posts: n/a
 
      09-12-2012
On Sep 11, 11:56*pm, mike3 <(E-Mail Removed)> wrote:
> On Sep 11, 1:57*pm, "Scott Fluhrer" <(E-Mail Removed)> wrote:
> > "Kaz Kylheku" <(E-Mail Removed)> wrote in message
> >news:(E-Mail Removed)...


[the inc-toward operator]

> > > 3. Not having b <-- a, you have to write something like a = (a < b)? a +
> > > 1 : a - 1;


<snip>

> > [...] *Specifically, what should the operator do if a==b initially?


<snip>

> What I was thinking of was that a --> b when a == b should leave a
> unchanged.
> Because the idea is that with repeated application, a converges to b,
> or
> a "goes to" b. So when a == b, a should remain unchanged, as it is
> "already
> there".
>
> However, as for this "expressiveness" issue: the question comes down
> to whether
> or not it'd be a good idea to have certain things made into a short-
> hand, easily-
> available form or not. That is, is it more _convenient_ -- does it
> make things
> _easier_ if we had -->. Wouldn't it be nice to know it's there if you
> need it,
> so you don't have to code that extra macro or whatever?


but how would you use it? With an approriate return value
this:-

for (i = 0; i < 10; i++)
do_something (i);

could be

i = 0;
while (i --> 10)
do_something (i);

but I'm not sure this buys you much.

> I do however, wonder in light of this point, which kind of what-to-do-
> when-the-
> values-are-equal behavior is used most often in actual real uses of
> this operation
> (written without this operat_or_, of course.



I'm simply failign to see the point
 
Reply With Quote
 
BartC
Guest
Posts: n/a
 
      09-12-2012


"mike3" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> On Sep 11, 4:27 pm, (E-Mail Removed) (Gordon Burditt) wrote:


>> As far as I know, nothing conflicts with using :=: as an operator,
>> as in:
>> b :=: a;
>> which might or might not mean to take the reciprocal of the
>> base-pi logarithm of each value, then swap them. How did we
>> possibly get along without that?
>>

>
> So you've never encountered a situation in which you have to step
> the value of a variable closer to that of another?


Hardly ever. More common is to have to choose between ++ and -- depending on
some condition known at runtime. And it's usually treated like this:

incr = cond?1:-1;

a += incr;

Not quite the same as your operator, as it doesn't check that it's reached
some limit and so stops incrementing/decrementing. But as part of a loop
that takes care of termination, it will be faster than yours. (Your operator
will anyway still need loop control to be added.)

> Oen situation, and the one that inspired this post, along with the
> discusson on stackoverflow, is that of looping or moving between two
> coordinate points. Suppose you have coordinates x0 and x1 and want to
> move between them. Let x be your current position. To move in a unit
> step
> toward x1:
>
> x --> x1; (or x ==> x1
>
> To move the other way, toward x0:
>
> x --> x0; (or x ==> x0
>
> or, perhaps if you think of this as "backwards" movement,
>
> x0 <-- x; (or x0 <== x


It's more likely that you'd want to move between two 2D points: if you have
two points (or vectors) p and q, and want a third point r to move from p to
q, one way is:

r = p;
incr = (q-p)/nsteps; // obviously no longer C at this point

r+=incr; // repeated nsteps times

This would normally use floating point ; with integer arithmetic (discrete
pixels), then there are a bunch of other problems, because the pixel
increments will be uneven in x and y (it needs the line drawing algorithm).
That would make the use of "-->" awkward too:

r --> q; // won't work in C; q is a point

r.x --> q.x;
r.y --> q.y;

These latter two won't work, as there will be a different number of steps
for each (and r moves at 45 degree angles).

> And I suspect it wouldn't be as useful for floats as for integers
> unless there were some way to control the size of the step.


Actually it sounds like it could be more useful for floats, and vectors as
in my example. But inefficient compared with alternatives, because you'd
need to specify the step at each step.

It seems it ought to be part of a loop control, with having to specify what
looks like a terminating condition, and possibly a step, but without
actually having the power to break out of a loop. That means you'd need a
normal loop condition on top.

--
Bartc

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Would Anyone Use a _FuncRetType Operator? Shao Miller C Programming 10 02-25-2012 12:52 PM
What are the key differences between operator new and operator new[]? xmllmx C++ 6 02-03-2010 04:11 PM
an oddball scary kind of thing you would think would never happen richard Computer Support 4 01-31-2010 06:34 PM
Allocation with new operator and Destroying with free operator saikishore.vanga@wipro.com C++ 8 12-22-2005 01:35 PM
Would a ':=' operator break anything? Phil Tomson Ruby 6 04-09-2004 05:02 PM



Advertisments