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

Groups > comp.lang.c > #77164 > unrolled thread

->=

Back to article view | Back to comp.lang.c

Contents

  ->= glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-11-25 14:53 +0000
    Re: ->= Richard Heathfield <rjh@cpax.org.uk> - 2015-11-25 15:12 +0000
      Re: ->= James Kuyper <jameskuyper@verizon.net> - 2015-11-25 11:51 -0500
        Re: ->= "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-11-25 09:49 -0800
        Re: ->= supercat@casperkitty.com - 2015-11-25 09:55 -0800
      Re: ->= John Bode <jfbode1029@gmail.com> - 2015-11-25 12:24 -0800
        Re: ->= James Kuyper <jameskuyper@verizon.net> - 2015-11-25 15:40 -0500
          Re: ->= John Bode <jfbode1029@gmail.com> - 2015-11-27 17:14 -0800
            Re: ->= James Kuyper <jameskuyper@verizon.net> - 2015-11-27 20:28 -0500
    Re: ->= "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-11-25 07:35 -0800
    Re: ->= "Charles Richmond" <numerist@aquaporin4.com> - 2015-11-25 15:47 -0600
      Re: ->= James Kuyper <jameskuyper@verizon.net> - 2015-11-25 17:04 -0500
      Re: ->= Nobody <nobody@nowhere.invalid> - 2015-11-26 10:58 +0000
        Re: ->= supercat@casperkitty.com - 2015-11-26 08:55 -0800
    Re: ->= raltbos@xs4all.nl (Richard Bos) - 2015-11-26 00:48 +0000
    Re: ->= Tim Rentsch <txr@alumni.caltech.edu> - 2015-11-27 14:15 -0800
      Re: ->= supercat@casperkitty.com - 2015-11-27 14:26 -0800
        Re: ->= BartC <bc@freeuk.com> - 2015-11-27 23:38 +0000
          Re: ->= Keith Thompson <kst-u@mib.org> - 2015-11-27 19:37 -0800
            Re: ->= Tim Rentsch <txr@alumni.caltech.edu> - 2015-11-28 06:35 -0800
        Re: ->= Stephen Sprunk <stephen@sprunk.org> - 2015-11-27 17:51 -0600
        Re: ->= Tim Rentsch <txr@alumni.caltech.edu> - 2015-11-28 06:53 -0800
          Re: ->= glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-11-28 17:12 +0000
            Re: ->= Keith Thompson <kst-u@mib.org> - 2015-11-28 10:26 -0800
              Re: ->= glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-11-28 19:50 +0000
            Re: ->= BartC <bc@freeuk.com> - 2015-11-28 19:14 +0000
              Re: ->= supercat@casperkitty.com - 2015-11-28 11:48 -0800
                Re: ->= glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-11-29 22:33 +0000
              Re: ->= glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-11-28 20:18 +0000
                Re: ->= Stephen Sprunk <stephen@sprunk.org> - 2015-11-28 18:15 -0600
                  Re: ->= glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-11-29 22:44 +0000
                    Re: ->= Stephen Sprunk <stephen@sprunk.org> - 2015-11-29 18:25 -0600
                    Re: ->= raltbos@xs4all.nl (Richard Bos) - 2015-11-30 10:21 +0000
              Re: ->= Keith Thompson <kst-u@mib.org> - 2015-11-28 13:10 -0800
                Re: ->= BartC <bc@freeuk.com> - 2015-11-28 22:12 +0000
                  Re: ->= raltbos@xs4all.nl (Richard Bos) - 2015-11-29 11:42 +0000
                    Re: ->= BartC <bc@freeuk.com> - 2015-11-29 14:24 +0000
                      Re: "->=" Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-11-29 10:33 -0500
                      Re: "->=" BartC <bc@freeuk.com> - 2015-11-29 17:49 +0000
                      Re: ->= supercat@casperkitty.com - 2015-11-29 11:50 -0800
                        Re: ->= BartC <bc@freeuk.com> - 2015-11-29 22:37 +0000
                  Re: ->= Keith Thompson <kst-u@mib.org> - 2015-11-30 00:23 -0800
                Re: ->= glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-11-29 23:00 +0000
                  Re: ->= Keith Thompson <kst-u@mib.org> - 2015-11-30 00:28 -0800
                  Re: ->= Rosario19 <Ros@invalid.invalid> - 2015-12-13 16:29 +0100
    Re: ->= Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-11-28 14:59 -0500

Page 1 of 3  [1] 2 3  Next page →

#77164 — ->=

In a recent post on linked list, there was the common notation:


    p = p->next;

Though I have written it many times, this time it occured to me 
that there could have been a C operator ->= such that:

   p ->= next;

That is, similar to the way we have i += 2; instead of i=i+2; 

Strange thought for the day, back to ordinary C.

-- glen

[toc] | [next] | [standalone]

#77166

On 25/11/15 14:53, glen herrmannsfeldt wrote:
> In a recent post on linked list, there was the common notation:
>
>
>      p = p->next;
>
> Though I have written it many times, this time it occured to me
> that there could have been a C operator ->= such that:
>
>     p ->= next;

I can't think of any legal code it would break, and it seems intuitive. 
Yep, I'll buy that for a dollar. Good one. What we need now is some 
prior art, or whatever the term is, to provide some ammunition to the 
ISO folks. Perhaps Jacob Navia or Walter Banks would oblige? (Or both?)

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]

#77170

On 11/25/2015 10:12 AM, Richard Heathfield wrote:
> On 25/11/15 14:53, glen herrmannsfeldt wrote:
>> In a recent post on linked list, there was the common notation:
>>
>>
>>      p = p->next;
>>
>> Though I have written it many times, this time it occured to me
>> that there could have been a C operator ->= such that:
>>
>>     p ->= next;
> 
> I can't think of any legal code it would break, and it seems intuitive. 
> Yep, I'll buy that for a dollar.

I agree.
I suspect it's absent from the current list because it's considered a
postfix operator rather than a binary operator, since the right operand
is an identifier rather than an expression with a value.
I looked over the other postfix operators, and didn't find any others
for which this would be a reasonable thing to do. However, there's two
binary operators that seem to have been skipped: ||= and &&= could both
be convenient in some circumstances.

[toc] | [prev] | [next] | [standalone]

#77173

James Kuyper wrote:
> However, there's two binary operators that
> seem to have been skipped: ||= and &&=
> could both be convenient in some circumstances.

++James;    // :-)

Best regards,
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#77174

On Wednesday, November 25, 2015 at 10:51:47 AM UTC-6, James Kuyper wrote:
> I looked over the other postfix operators, and didn't find any others
> for which this would be a reasonable thing to do. However, there's two
> binary operators that seem to have been skipped: ||= and &&= could both
> be convenient in some circumstances.

While the language spec describes "." and "->" as operators, their linguistic
function is more like that of a syntactic element which grabs the next token
and acts together with it as an operator.  Thus, given "int i=foo.x", I would
say that the ".x" acts as an operator whose meaning is "interpret part of an
outer lvalue as an inner lvalue of a different type", and "int i=foo->x" is
syntactic sugar for "int i=(*foo).x".

I remember trying ->= as an operator back in 1990 on a Unix C compiler and
being disappointed that it didn't work.  If I were to list all the operators
I've wished C had, that one would fall somewhere in the middle with regard to
usefulness.  It would fit quite nicely with the original concept of C as a
language which should not need fancy compilation logic to yield decent code,
since its evaluation on a value in a register would simply require a single
indexed load instruction, and its evaluation on an lvalue in memory would
require computing the lvalue address and performing two loads and a store.

Still, I think some more useful operators might compute maximum, compute
minimum, yield "a ? a : b" but with the first operand evaluated only once
[and the second one conditionally], "a ? b : 0", "a & ~b" but with b
promoted to the type of a *before* the negation, etc.

[toc] | [prev] | [next] | [standalone]

#77185

On Wednesday, November 25, 2015 at 9:12:43 AM UTC-6, Richard Heathfield wrote:
> On 25/11/15 14:53, glen herrmannsfeldt wrote:
> > In a recent post on linked list, there was the common notation:
> >
> >
> >      p = p->next;
> >
> > Though I have written it many times, this time it occured to me
> > that there could have been a C operator ->= such that:
> >
> >     p ->= next;
> 
> I can't think of any legal code it would break, and it seems intuitive. 
> Yep, I'll buy that for a dollar. Good one. What we need now is some 
> prior art, or whatever the term is, to provide some ammunition to the 
> ISO folks. Perhaps Jacob Navia or Walter Banks would oblige? (Or both?)
> 
> -- 
> Richard Heathfield
> Email: rjh at cpax dot org dot uk
> "Usenet is a strange place" - dmr 29 July 1999
> Sig line 4 vacant - apply within

You'd probably want to add a `.=` operator as well. 

I guess it would be easy enough to disambiguate struct and union member
names using `->=` and `.=` as well as `.` and `->`, although to be honest
this starts crossing over into line noise IMO.  

I'd rather adopt an iterator concept similar to C++ (although then you'd
be overloading `++`, `--`, and `*` to a degree that isn't in the spirit
of C IMO).  

[toc] | [prev] | [next] | [standalone]

#77186

On 11/25/2015 03:24 PM, John Bode wrote:
> On Wednesday, November 25, 2015 at 9:12:43 AM UTC-6, Richard Heathfield wrote:
>> On 25/11/15 14:53, glen herrmannsfeldt wrote:
>>> In a recent post on linked list, there was the common notation:
>>>
>>>
>>>      p = p->next;
>>>
>>> Though I have written it many times, this time it occured to me
>>> that there could have been a C operator ->= such that:
>>>
>>>     p ->= next;
...

> You'd probably want to add a `.=` operator as well. 

For consistency with the other compound assignment operators, the expression

    s .= member;

would have to be equivalent to:

    s = s.member

That would require that s.member have a type that's compatible with the
type of s (6.5.16.1p1). How could that even be possible?

[toc] | [prev] | [next] | [standalone]

#77299

On Wednesday, November 25, 2015 at 2:40:25 PM UTC-6, James Kuyper wrote:
> On 11/25/2015 03:24 PM, John Bode wrote:
> > On Wednesday, November 25, 2015 at 9:12:43 AM UTC-6, Richard Heathfield wrote:
> >> On 25/11/15 14:53, glen herrmannsfeldt wrote:
> >>> In a recent post on linked list, there was the common notation:
> >>>
> >>>
> >>>      p = p->next;
> >>>
> >>> Though I have written it many times, this time it occured to me
> >>> that there could have been a C operator ->= such that:
> >>>
> >>>     p ->= next;
> ...
> 
> > You'd probably want to add a `.=` operator as well. 
> 
> For consistency with the other compound assignment operators, the expression
> 
>     s .= member;
> 
> would have to be equivalent to:
> 
>     s = s.member
> 
> That would require that s.member have a type that's compatible with the
> type of s (6.5.16.1p1). How could that even be possible?

Derp.

You're correct, of course.

Which introduces a bit of an assymetry.  After thinking about it some more,
I'm not sure it would be that useful an operator.  I mean, `->` is syntactic
sugar for `(*).`, but it's applicable to all struct member accesses; `->=`
would only be applicable in a very narrow domain (the member has to have
the same pointer type as the target).

[toc] | [prev] | [next] | [standalone]

#77301

On 11/27/2015 08:14 PM, John Bode wrote:
> On Wednesday, November 25, 2015 at 2:40:25 PM UTC-6, James Kuyper wrote:
>> On 11/25/2015 03:24 PM, John Bode wrote:
>>> On Wednesday, November 25, 2015 at 9:12:43 AM UTC-6, Richard Heathfield wrote:
>>>> On 25/11/15 14:53, glen herrmannsfeldt wrote:
>>>>> In a recent post on linked list, there was the common notation:
>>>>>
>>>>>
>>>>>      p = p->next;
>>>>>
>>>>> Though I have written it many times, this time it occured to me
>>>>> that there could have been a C operator ->= such that:
>>>>>
>>>>>     p ->= next;
>> ...
>>
>>> You'd probably want to add a `.=` operator as well. 
>>
>> For consistency with the other compound assignment operators, the expression
>>
>>     s .= member;
>>
>> would have to be equivalent to:
>>
>>     s = s.member
>>
>> That would require that s.member have a type that's compatible with the
>> type of s (6.5.16.1p1). How could that even be possible?
> 
> Derp.
> 
> You're correct, of course.
> 
> Which introduces a bit of an assymetry.  After thinking about it some more,
> I'm not sure it would be that useful an operator.  I mean, `->` is syntactic
> sugar for `(*).`, but it's applicable to all struct member accesses; `->=`
> would only be applicable in a very narrow domain (the member has to have
> the same pointer type as the target).

True - but it's a fairly common narrow domain. Any time you have a
navigate a network of nodes of the same type connected by pointers, this
operator could be convenient, and that's not an uncommon property for C
data structures. Linked lists are just the simplest example of such a
structure.

Note: 6.5.16.2p3 would have to be revised slightly in a way that makes
->= a special case. That clause doesn't explicitly say that E2 is an
expression, but that's clearly what was intended, and is hinted at by
the 'E', and that wouldn't be the case for pstruct->=member. Also,
defining it as equivalent to E1 = E1 op (E2) works for all of the
existing compound assignment operators, but the parenthesis would have
to be removed for ->=. I'm not sure that's sufficient reason to justify
rejecting this idea, but it is a valid thing to object to.

[toc] | [prev] | [next] | [standalone]

#77167

On Wednesday, November 25, 2015 at 9:53:38 AM UTC-5, glen herrmannsfeldt wrote:
> In a recent post on linked list, there was the common notation:
> 
> 
>     p = p->next;
> 
> Though I have written it many times, this time it occured to me 
> that there could have been a C operator ->= such that:
> 
>    p ->= next;
> 
> That is, similar to the way we have i += 2; instead of i=i+2; 
> 
> Strange thought for the day, back to ordinary C.
> 
> -- glen

++glen;  // :-)

Best regards,
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#77189

"glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message 
news:n34i16$puk$1@speranza.aioe.org...
> In a recent post on linked list, there was the common notation:
>
>
>    p = p->next;
>
> Though I have written it many times, this time it occured to me
> that there could have been a C operator ->= such that:
>
>   p ->= next;
>
> That is, similar to the way we have i += 2; instead of i=i+2;
>
> Strange thought for the day, back to ordinary C.
>

ISTM that I always thought "p->" was just shorthand for "(*p)." ... and that 
the "p->" would be replaced early on with "(*p)."   So I did *not* think 
that "->" ever rose to the level of a *real* operator.

-- 

numerist at aquaporin4 dot com

[toc] | [prev] | [next] | [standalone]

#77190

On 11/25/2015 04:47 PM, Charles Richmond wrote:
...
> ISTM that I always thought "p->" was just shorthand for "(*p)." ... and that 
> the "p->" would be replaced early on with "(*p)."   So I did *not* think 
> that "->" ever rose to the level of a *real* operator.

"->" is defined as it's own unique punctuator in 6.4.6, just like "++"
and "*=". It's more independent than a++, b*=c, or d[e], because the
descriptions of all three of those operators reference the corresponding
more fundamental operators: a=a+1; b = b*c; *(d+e). "f->g" could have
been defined as *(f).g. That identity is perfectly valid, but "f->g" is
actually defined directly without reference to the "*" or "." operators:
see 6.5.2.3p2,4.

[toc] | [prev] | [next] | [standalone]

#77209

On Wed, 25 Nov 2015 15:47:00 -0600, Charles Richmond wrote:

> ISTM that I always thought "p->" was just shorthand for "(*p)."

I always thought that "s." was just shorthand for "(&s)->".

That might be a consequence of having learned assembler before C.

[toc] | [prev] | [next] | [standalone]

#77216

On Thursday, November 26, 2015 at 4:57:54 AM UTC-6, Nobody wrote:
> I always thought that "s." was just shorthand for "(&s)->".
> 
> That might be a consequence of having learned assembler before C.

There is a fundamental difference between indirection and indexing.  Given

   struct foo
   {
     int x,y;
     struct foo *next;
     int arr[4];
     int *ints;
   } *p;

the addresses of x, y, next, arr, arr[any constant], etc. and ints are all
at fixed displacements relative to p.  The addresses of next->anything
and ints[anything], by contrast, are unrelated to p.

Personally, I think the aliasing rules of C would have been much better and
clearer if they defined a concept of "outer lvalue" which would basically
be the outermost part of the expression relative to which the lvalue being
accessed has an integer displacement, and if the rules required that, with
certain exceptions, and in the absence of directives indicating otherwise,
operations on disjoint lvalues would only be sequenced if they used the
same outer lvalue type and the same "path" from that outer lvalue to the
one being accessed.  Testing suggests that C compilers behave as though such
a rule exists, though I don't see what in the Standard would indicate that.

[toc] | [prev] | [next] | [standalone]

#77198

glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:

> In a recent post on linked list, there was the common notation:
> 
>     p = p->next;
> 
> Though I have written it many times, this time it occured to me 
> that there could have been a C operator ->= such that:
> 
>    p ->= next;

Well, of course! I even think I've seen that suggested before. And it
would fit beautifully in my favourite application of C's for statement:

  for (p=head; p; p->=next) ...

Richard

[toc] | [prev] | [next] | [standalone]

#77291

glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:

> In a recent post on linked list, there was the common notation:
>
>
>     p = p->next;
>
> Though I have written it many times, this time it occured to me 
> that there could have been a C operator ->= such that:
>
>    p ->= next;
>
> That is, similar to the way we have i += 2; instead of i=i+2; 

I'm surprised how many people responded positively to this.  At
best it's no more than syntactic saccharin.  Note also it
requires revising the rule stated in the first sentence of
6.5.16.2 p3.  Kind of sticks out like a sort thumb.

[toc] | [prev] | [next] | [standalone]

#77293

On Friday, November 27, 2015 at 4:15:37 PM UTC-6, Tim Rentsch wrote:
> I'm surprised how many people responded positively to this.  At
> best it's no more than syntactic saccharin.  Note also it
> requires revising the rule stated in the first sentence of
> 6.5.16.2 p3.  Kind of sticks out like a sort thumb.

Adding anything to the language would require revising any rule that
claims to be an exhaustive list of such things.  Further, I'm not
sure why it should necessarily be considered syntactic saccharin any
moreso than any of the other compound operators.  Just as "foo[i]+=4;"
avoids the need to evaluate its lvalue twice, so too would 
"foo->bar->boz->=next" avoid the need to either generate a temporary
pointer to hold "foo->bar->boz" or risk having the dereferencing chain
performed twice.

[toc] | [prev] | [next] | [standalone]

#77296

On 27/11/2015 22:26, supercat@casperkitty.com wrote:
> On Friday, November 27, 2015 at 4:15:37 PM UTC-6, Tim Rentsch wrote:
>> I'm surprised how many people responded positively to this.  At
>> best it's no more than syntactic saccharin.  Note also it
>> requires revising the rule stated in the first sentence of
>> 6.5.16.2 p3.  Kind of sticks out like a sort thumb.
>
> Adding anything to the language would require revising any rule that
> claims to be an exhaustive list of such things.

Still, it is a little untidy. -> was already bolted-on (or seems like 
it) so that you can write p->m instead of (*p).m. Now ->= would be 
introduced so that you can write:

   p ->= m

instead of:

   p = p->m

which is itself written instead of:

   p = (*p).m

> Further, I'm not
> sure why it should necessarily be considered syntactic saccharin any
> moreso than any of the other compound operators.  Just as "foo[i]+=4;"
> avoids the need to evaluate its lvalue twice, so too would
> "foo->bar->boz->=next" avoid the need to either generate a temporary
> pointer to hold "foo->bar->boz" or risk having the dereferencing chain
> performed twice.

Maybe. But you often have to write things twice. There are innumerable 
examples of common sub-expressions (many with undesirable side-effects 
too), and there is no special syntax to help out.

(OK, I mainly don't like it because I can't use the idea in my language 
that targets C. In that syntax it's too unwieldy.)

 >> best it's no more than syntactic saccharin.  Note also it
 >> requires revising the rule stated in the first sentence of
 >> 6.5.16.2 p3.  Kind of sticks out like a sort thumb.

I didn't understand that bit. But I can see that if a member name 
normally only follows a "." or "->" token, now it will need to be 
allowed after "->=" too. It can't just be mapped to = and ->, unless the 
implementation ensures that any side-effects occur just once.

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#77304

BartC <bc@freeuk.com> writes:
[...]
>> On Friday, November 27, 2015 at 4:15:37 PM UTC-6, Tim Rentsch wrote:
[...]
>  >> best it's no more than syntactic saccharin.  Note also it
>  >> requires revising the rule stated in the first sentence of
>  >> 6.5.16.2 p3.  Kind of sticks out like a sort thumb.
>
> I didn't understand that bit. But I can see that if a member name 
> normally only follows a "." or "->" token, now it will need to be 
> allowed after "->=" too. It can't just be mapped to = and ->, unless the 
> implementation ensures that any side-effects occur just once.

6.5.16.2p3 says:

    A compound assignment of the form E1 op = E2 is equivalent to
    the simple assignment expression E1 = E1 op (E2), except that
    the lvalue E1 is evaluated only once, and with respect to an
    indeterminately-sequenced function call, the operation of a
    compound assignment is a single evaluation.

The semantics of the `->=` operator would have to be defined
without the parentheses, since `foo->(bar)` is illegal even when
`foo->bar` is legal.  Not a fatal problem, but it would be one more
special case.

(Tim: I suggest that you'd save a some people some time if you'd quote
the sentence rather than just citing the section and paragraph number.)

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#77319

Keith Thompson <kst-u@mib.org> writes:

> (Tim:  I suggest that you'd save a some people some time if you'd
> quote the sentence rather than just citing the section and
> paragraph number.)

Yes, in retrospect I think that would have been better.  Thank
you for helping with a more complete explanation.

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.lang.c

csiph-web