Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #26231

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

Show all headers | View raw

On 12/09/2012 00:25, mike3 wrote:
> On Sep 11, 1:24 pm, Kaz Kylheku <k...@kylheku.com> wrote:
>> On 2012-09-10, mike3 <mike4...@yahoo.com> wrote:
>>
>>> Hi.
>>
>>> I was wondering about this. I saw this posting on this site:
>>
>>> http://stackoverflow.com/questions/1642028/what-is-the-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?
>

People (compiler users, compiler writers, and language standards 
committees) do move towards newer language features.  But there is a 
very high threshold before new features are added to the language.  Just 
look at the recent discussions about adding C features to C++ or C++ 
features to C - this is a tough processes even when the features are of 
obvious benefit to users, are already implemented by the compilers, are 
familiar to many users (since many people are fluent in C /and/ C++), 
and are documented in similar types of standards.

So for a nonsensical operator with poorly specified semantics, rare use 
cases, and a syntax that conflicts with existing standards, I would not 
be optimistic...

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

Why do you think that?  I don't know what you mean by "the" compiler 
here, but many C compilers are very good at optimising, and they don't 
need builtins to do it.  In this particular case, I'd expect a compiler 
to produce better code with macro version - in many cases, a compiler 
could hoist the initial comparison to the top of the loop, statically 
identify the result of the comparison, and replace the inner loop with a 
simple ++ or -- and comparison.

And in general, /if/ there were significant use cases for such a 
construction, and /if/ there were significant gains to be made by 
treating it specially, then compilers could include the pattern in the 
pattern matching machinery and optimise specifically for it.

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

No, many operators do not equate to a machine instruction on most 
targets.  There are a few cpu targets that have hardware support for 
things like division - a great many cannot even do a 16-bit increment in 
a single instruction.  There are also many machine instructions that do 
not correspond to a single C construct - the most obvious one being that 
on most targets, a "comparison" operation gives flags for greater than, 
less than, equal to, and combinations thereof, while in C you can only 
test for one at a time.  It is up to compilers to spot patterns like "if 
(a > b) { .. } else if (a < b) { ... }" and generate a single comparison.

Arguing based on target machine instructions and/or compiler 
implementations is best done when you have experience of a wide range of 
target architectures and of compiler functionality.

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

I just cannot see a point in this operator.  The nearest I can think of 
that would actually be useful would be "if (x) x--;".

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

New C operator -- would it be a good idea? mike3 <mike4ty4@yahoo.com> - 2012-09-10 12:48 -0700
  Re: New C operator -- would it be a good idea? "Scott Fluhrer" <sfluhrer@ix.netcom.com> - 2012-09-11 14:27 -0400
    Re: New C operator -- would it be a good idea? "christian.bau" <christian.bau@cbau.wanadoo.co.uk> - 2012-09-11 16:53 -0700
  Re: New C operator -- would it be a good idea? Kaz Kylheku <kaz@kylheku.com> - 2012-09-11 19:24 +0000
    Re: New C operator -- would it be a good idea? "Scott Fluhrer" <sfluhrer@ix.netcom.com> - 2012-09-11 15:56 -0400
      Re: New C operator -- would it be a good idea? Keith Thompson <kst-u@mib.org> - 2012-09-11 14:15 -0700
      Re: New C operator -- would it be a good idea? mike3 <mike4ty4@yahoo.com> - 2012-09-11 15:56 -0700
        Re: New C operator -- would it be a good idea? Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-09-12 00:56 -0700
          Re: New C operator -- would it be a good idea? "BartC" <bc@freeuk.com> - 2012-09-12 10:55 +0100
            Re: New C operator -- would it be a good idea? "io_x" <a@b.c.invalid> - 2012-09-13 07:47 +0200
              Re: New C operator -- would it be a good idea? "BartC" <bc@freeuk.com> - 2012-09-13 10:47 +0100
    Re: New C operator -- would it be a good idea? mike3 <mike4ty4@yahoo.com> - 2012-09-11 15:25 -0700
      Re: New C operator -- would it be a good idea? David Brown <david@westcontrol.removethisbit.com> - 2012-09-12 09:39 +0200
        Re: New C operator -- would it be a good idea? mike3 <mike4ty4@yahoo.com> - 2012-09-12 08:33 -0700
          Re: New C operator -- would it be a good idea? David Brown <david@westcontrol.removethisbit.com> - 2012-09-13 09:53 +0200
    Re: New C operator -- would it be a good idea? falk@rahul.net (Edward A. Falk) - 2012-09-12 17:43 +0000
      Re: New C operator -- would it be a good idea? mike3 <mike4ty4@yahoo.com> - 2012-09-12 15:35 -0700
      Re: New C operator -- would it be a good idea? Ike Naar <ike@iceland.freeshell.org> - 2012-09-13 06:34 +0000
        Re: New C operator -- would it be a good idea? "BartC" <bc@freeuk.com> - 2012-09-13 11:47 +0100
      Re: New C operator -- would it be a good idea? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-09-13 23:52 -0700
        Re: New C operator -- would it be a good idea? Ike Naar <ike@iceland.freeshell.org> - 2012-09-14 07:53 +0000
          Re: New C operator -- would it be a good idea? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-09-14 11:46 +0100
            Re: New C operator -- would it be a good idea? JohnF <john@please.see.sig.for.email.com> - 2012-09-14 13:17 +0000
          Re: New C operator -- would it be a good idea? John Bode <jfbode1029@gmail.com> - 2012-09-14 11:35 -0700
        Re: New C operator -- would it be a good idea? Keith Thompson <kst-u@mib.org> - 2012-09-14 02:04 -0700
        Re: New C operator -- would it be a good idea? Kaz Kylheku <kaz@kylheku.com> - 2012-09-14 21:11 +0000
      Re: New C operator -- would it be a good idea? Ben Pfaff <blp@cs.stanford.edu> - 2012-09-14 11:39 -0700
  Re: New C operator -- would it be a good idea? "BartC" <bc@freeuk.com> - 2012-09-11 22:32 +0100
    Re: New C operator -- would it be a good idea? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-09-11 15:19 -0700
  Re: New C operator -- would it be a good idea? gordonb.22y0w@burditt.org (Gordon Burditt) - 2012-09-11 17:27 -0500
    Re: New C operator -- would it be a good idea? mike3 <mike4ty4@yahoo.com> - 2012-09-11 18:51 -0700
      Re: New C operator -- would it be a good idea? "BartC" <bc@freeuk.com> - 2012-09-12 10:49 +0100
      Re: New C operator -- would it be a good idea? Greg Martin <greg@softsprocket.com> - 2012-09-12 23:23 -0700
        Re: New C operator -- would it be a good idea? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-09-13 12:08 +0100
          Re: New C operator -- would it be a good idea? Keith Thompson <kst-u@mib.org> - 2012-09-13 15:20 -0700
      Re: New C operator -- would it be a good idea? gordonb.h093l@burditt.org (Gordon Burditt) - 2012-09-14 15:13 -0500
  Re: New C operator -- would it be a good idea? Rui Maciel <rui.maciel@gmail.com> - 2012-09-14 20:38 +0100

csiph-web