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 | \ __________ / \ ___________________________________________________ / \/ \/ \/ \/