[comp.lang.c] missing ->= operator

schuller@DUTIAA.TUDELFT.NL (Schuller Schuller Oijen) (04/29/91)

Hi all,
recently I've been doing a lot of C pointer programming and I came upon
a missing feature in C. Suppose you have this struct called mygod :
	typedef struct mygod
	{
		int value;
		struct mygod *next;
	} mygod_struct
What you do quite often is : mygodptr = mygodptr->next;
Now C has all these wonderful operators : a += 7, g &= 0xf, etc, etc.
But the ->= operator is missing! You cannot do mygodptr ->= next; !
All of you who want to fill this gap, please react. Flames to /dev/null.
Bye! Hildo Biersma, schuller@dutiad.tudelft.nl

jwm712@unhd.unh.edu (Jonathan W Miner) (04/30/91)

In article <9104291641.AA00534@dutiaa.tudelft.nl> schuller@DUTIAA.TUDELFT.NL (Schuller Schuller Oijen) writes:
>Hi all,
>recently I've been doing a lot of C pointer programming and I came upon
>a missing feature in C. Suppose you have this struct called mygod :
> [code deleted]
>What you do quite often is : mygodptr = mygodptr->next;
>Now C has all these wonderful operators : a += 7, g &= 0xf, etc, etc.
>But the ->= operator is missing! You cannot do mygodptr ->= next; !
>All of you who want to fill this gap, please react. Flames to /dev/null.
>Bye! Hildo Biersma, schuller@dutiad.tudelft.nl

It is my opinion that the +=, &= etc operators were implemented on systems,
such as DEC VAX that has two operand instructions.  Although it would
be nice to have a ->=, it would be a programmer convenience, and it would
still be compiled into the same code as p = p->next.  

Now for my question: how do the below operators compare speedwise?


    C                     pseudo VAX code

    a++;                  inc a;

    a += 1;               add2 1,a;

    a = a + 1;            add3 1,a,a;


Jon.



-- 
Jonathan Miner        | I won't speak for UNH, and UNH does not 
jwm712@unhd.unh.edu   | speak for me, but they'll charge me anyway! 
(603)868-3416         | Hacking to graduate this May!
Moving soon to miner@mervax.sanders.com  (I think?!)

eoo@let.rug.nl (Eize Oosting) (05/01/91)

In article <9104291641.AA00534@dutiaa.tudelft.nl> schuller@DUTIAA.TUDELFT.NL (Schuller Schuller Oijen) writes:
>Hi all,
>recently I've been doing a lot of C pointer programming and I came upon
>a missing feature in C. Suppose you have this struct called mygod :
>	typedef struct mygod
>	{
>		int value;
>		struct mygod *next;
>	} mygod_struct
>What you do quite often is : mygodptr = mygodptr->next;
>Now C has all these wonderful operators : a += 7, g &= 0xf, etc, etc.
>But the ->= operator is missing! You cannot do mygodptr ->= next; !
>All of you who want to fill this gap, please react. Flames to /dev/null.
>Bye! Hildo Biersma, schuller@dutiad.tudelft.nl

It sounds wonderfull, but it would ask for an Object Oriented style, and
C is just not OO. Maybe this would be something for C++.

What you can do is something like this:

#define NEXT(ptr)  ptr = ptr->next

It isn't the nicest solution, but it works.

  /\__________/\   /\___________________________________________________/\
 /              \ /                                                       \
|   Letteren-    |  Marvin Minsky once defined Artificial Intelligence as: |
|   Faculteit    |   '... the science of making machines do things that    |
| R.U. Groningen |   would require intelligence if done by men'.           |
| The Netherlands|                                                         |
|                |  Does this include formatting a floppy?                 |
| eoo@let.rug.nl |                                           Eize Oosting  |
 \  __________  / \  ___________________________________________________  /
  \/          \/   \/                                                   \/

henry@zoo.toronto.edu (Henry Spencer) (05/01/91)

In article <1991Apr30.165110.4165@unhd.unh.edu> jwm712@unhd.unh.edu (Jonathan W Miner) writes:
>It is my opinion that the +=, &= etc operators were implemented on systems,
>such as DEC VAX that has two operand instructions...

No; they date to B on the pdp7, which had *one*-operand instructions.
These operators (and ++ and --) were always meant primarily as programming
conveniences, with the secondary possibility of more efficient code.

>Now for my question: how do the below operators compare speedwise?
>    a++;
>    a += 1;
>    a = a + 1;

Any C compiler which compiles different code for these is pretty stupid
(assuming that the evaluation of `a' has no side effects).  Modern compilers
will give you exactly the same code, running at the same speed, for all
of them.
-- 
And the bean-counter replied,           | Henry Spencer @ U of Toronto Zoology
"beans are more important".             |  henry@zoo.toronto.edu  utzoo!henry

bhoughto@pima.intel.com (Blair P. Houghton) (05/01/91)

In article <1991Apr30.165110.4165@unhd.unh.edu> jwm712@unhd.unh.edu (Jonathan W Miner) writes:
>In article <9104291641.AA00534@dutiaa.tudelft.nl> schuller@DUTIAA.TUDELFT.NL (Schuller Schuller Oijen) writes:
>>What you do quite often is : mygodptr = mygodptr->next;
>>But the ->= operator is missing! You cannot do mygodptr ->= next; !

Although it would be nice not to have to type the
structure-pointer name twice on the same line, the
current situation is syntactically consistent.

What's happening with the assignment operators is always

	(lvalue)   (arithmetic-binary-operator)=   (rvalue);

in a structure, the member-names are not rvalues, and `->'
is not an arithmetic-binary-operator (that's "binary" as in
"with two operands" rather than "with binary-data-typed
operands", and while it is always thus binary it is never
arithmetic).

The truly easiest (and IMHO cleanest) way to handle this is:

	#define next(x) ((x)->next)
	...

	struct foo {
	    ... ;
	    struct foo *next;
	} *bar;

	...
	bar = next(bar);

and to _always_ use the word `next' as the member-name for
the next member of a singly-linked list.  Similar conventions
hold for adding a `prev' member for a doubly-linked list,
and a `name' member for structures that have names.

Even if the structures are designed to be in multiple lists,
you will often want to keep a list of them in the order in
which you allocate them, so that if an elegant method of
searching for a particular struct can't be found, you can
always go to the first-allocated struct and roll down the
allocation-list.

>Now for my question: how do the below operators compare speedwise?
>    a++;                  inc a;
>    a += 1;               add2 1,a;
>    a = a + 1;            add3 1,a,a;

Looks like you compile with the brakes (the -g flag) on.

				--Blair
				  "Ert!"
				  -Matt Feazell, "CynicalMan"

clary@iastate.edu (Clary Jeffrey Scott) (05/01/91)

In <1667@gufalet.let.rug.nl> eoo@let.rug.nl (Eize Oosting) writes:

>In article <9104291641.AA00534@dutiaa.tudelft.nl> schuller@DUTIAA.TUDELFT.NL (Schuller Schuller Oijen) writes:

[explanation of ->= operator deleted]

>>Now C has all these wonderful operators : a += 7, g &= 0xf, etc, etc.
>>But the ->= operator is missing! You cannot do mygodptr ->= next; !
>>All of you who want to fill this gap, please react. Flames to /dev/null.
>>Bye! Hildo Biersma, schuller@dutiad.tudelft.nl

>It sounds wonderfull, but it would ask for an Object Oriented style, and
>C is just not OO. Maybe this would be something for C++.

Please elaborate on why       ptr ->= next
is "object oriented" than     x += 5

Thanks, 
Jeff

[reasonable suggestion for NEXT(ptr) macro deleted]

clary@iastate.edu

gwyn@smoke.brl.mil (Doug Gwyn) (05/02/91)

In article <1991Apr30.165110.4165@unhd.unh.edu> jwm712@unhd.unh.edu (Jonathan W Miner) writes:
>It is my opinion that the +=, &= etc operators were implemented on systems,
>such as DEC VAX that has two operand instructions.  Although it would
>be nice to have a ->=, it would be a programmer convenience, and it would
>still be compiled into the same code as p = p->next.  

No, you're not supposed to be thinking about what code is going to be
generated.

The main advantage of op= occurs in situations like:

	p->link->data[BIG_ROOM].flags |= BEEN_HERE;

where it would be tedious and error-prone to have to duplicate the LHS
as an operand, which would be necessary if the op= form did not exist.

There is no such justification for ->=, which seldom would be used in
contexts more involved than

	p = p->next;

which is easy enough to code as is.

There are some other more technical reasons involving type compatibility,
etc. but the above argument shows that it is not worth doing.

ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) (05/02/91)

In article <1991Apr30.165110.4165@unhd.unh.edu>, jwm712@unhd.unh.edu (Jonathan W Miner) writes:
> It is my opinion that the +=, &= etc operators were implemented on systems,
> such as DEC VAX that has two operand instructions.

Well, of _course_ they were _implemented_ on such machines.
But it is a MYTH that they reflect the behaviour of any machine.
The designers of C have repeatedly denied this malignant rumour
(there was a letter in SigPlan Notices last year about it),
pointing out that
    -- C inherited the operations from B
    -- B was implemented as an *interpreter*, so hardware features
       weren't particularly relevant
    -- and if I remember correctly, the machine B was implemented
       on _didn't_ have such instructions.

I would point out that
    -- Algol 68 has a whole raft of operators +:=, -:=, /:=, and so on.
       It was part of the culture at the time that "update operators"
       made programs clearer.  An example from some Pascal code of mine:
	n.items[o.first + o.count] := n.items[o.first + o.count] + 1;
       Much clearer as
	n.items[o.first + o.count] +:= 1;
       The hardware very definitely did _not_ show through in Algol 68!
    -- Burroughs Extended Algol had a gimmick where the first <primary>
       following an assignment symbol could be '*', meaning "same variable
       as the one preceding the assignment symbol".  Thus the BEAlgol
       version of the assignment above would be
	n.items[o.first + o.count] := * + 1;
       A virtue of that approach was that there was nothing special about	
       binary operators:
	x := not *;
	x := - *;
        x := *.[0:8];	% extract bits
       an so on worked just fine.  I can assume you that there was
       absolutely nothing on the Burroughs machine corresponding to
       "two operand instructions".

> Although it would
> be nice to have a ->=, it would be a programmer convenience, and it would
> still be compiled into the same code as p = p->next.  

What's wrong with programmer conveniences?  What else is a 'for' loop?
Heck, _types_ in C are just a programmer convenience; C's ancestors
managed without.  (Yes, I have written BCPL programs, and yes, I have
written "+" (integer add) when I meant "#+" (floating-point add).)

-- 
Bad things happen periodically, and they're going to happen to somebody.
Why not you?					-- John Allen Paulos.

newsuser@oliver.SUBLINK.ORG (Ugo Cei) (05/03/91)

schuller@DUTIAA.TUDELFT.NL (Schuller Schuller Oijen) writes:

>What you do quite often is : mygodptr = mygodptr->next;
>Now C has all these wonderful operators : a += 7, g &= 0xf, etc, etc.
>But the ->= operator is missing! You cannot do mygodptr ->= next; !

Of course you can't: next is not an rvalue, so it cannot be on the rhs
of an assignment. Moreover, just wonder what would happen if you had
this piece of code:

	struct foo 
	  {
	    struct foo * next;
	  }
	* bar;
	int next;

	...

	bar ->= next;

Maybe you can just switch to C++ and overload the ++ operator do do
such things.

	Cheers
-- 
**************** | Ugo Cei            | home:    newsuser@oliver.sublink.org
*    OLIVER    * | Via Colombo 7      | office:  cei@ipvvis.unipv.it
**************** | 27100 Pavia ITALY  |       "Real Programs Dump Core"

eoo@let.rug.nl (Eize Oosting) (05/06/91)

In article <clary.673114059@pv031e.vincent.iastate.edu> clary@iastate.edu (Clary Jeffrey Scott) writes:
>In <1667@gufalet.let.rug.nl> eoo@let.rug.nl (Eize Oosting) writes:
>
>>In article <9104291641.AA00534@dutiaa.tudelft.nl> schuller@DUTIAA.TUDELFT.NL (Schuller Schuller Oijen) writes:
>
>[explanation of ->= operator deleted]
>
>>>Now C has all these wonderful operators : a += 7, g &= 0xf, etc, etc.
>>>But the ->= operator is missing! You cannot do mygodptr ->= next; !
>>>All of you who want to fill this gap, please react. Flames to /dev/null.
>>>Bye! Hildo Biersma, schuller@dutiad.tudelft.nl
>
>>It sounds wonderfull, but it would ask for an Object Oriented style, and
>>C is just not OO. Maybe this would be something for C++.
>
>Please elaborate on why       ptr ->= next
>is "object oriented" than     x += 5
>

It's not the left part of the assignment which would be OO, but it's the
right part. The field 'next' is completely unknown as an legal value.
But you can read all of this in article 19705 (I believe). There someone
explains exactly why 'ptr ->= next' cannot do and 'x += 5' can. Sorry guys.

  /\__________/\   /\___________________________________________________/\
 /              \ /                                                       \
|   Letteren-    |  Marvin Minsky once defined Artificial Intelligence as: |
|   Faculteit    |   '... the science of making machines do things that    |
| R.U. Groningen |   would require intelligence if done by men'.           |
| The Netherlands|                                                         |
|                |  Does this include formatting a floppy?                 |
| eoo@let.rug.nl |                                           Eize Oosting  |
 \  __________  / \  ___________________________________________________  /
  \/          \/   \/                                                   \/