| |||||||||||||
Still not clear it's betterStill not clear it's betterPosted Jan 27, 2010 21:30 UTC (Wed) by dwheeler (guest, #1216)In reply to: Syntax flubs by alextingle Parent article: GCC to merge Go support
Yes, this can make your head hurt:
*a.b->c.d->e *= *p->q.r * *x[2];
But postfix isn't really much better (using ^):
(Log in to post comments)
But you can be consistent to make it clearer Posted Jan 27, 2010 21:57 UTC (Wed) by felixfix (subscriber, #242) [Link]
a^.b^.c.d^.e *= p^^.q.r * x[2]^;
Still ugly, but then it's a twisted example meant to be ugly. That prefix * has always annoyed me.
But you can be consistent to make it clearer Posted Jan 28, 2010 0:30 UTC (Thu) by elanthis (guest, #6227) [Link]
Is it the fact that's prefix or the fact that it's a * which is the same as
another very common operator?
Think carefully Posted Jan 27, 2010 22:00 UTC (Wed) by ncm (subscriber, #165) [Link]
Postfix dereference is better precisely because dwheeler's mistaken interpretation is possible only with prefix dereference.
Relatedly, it means that the very common construction "(*ptr)->member" loses its parentheses: "ptr^->member", and there is no temptation to forget them and write something by accident that means "ptr->member^".
Think carefully Posted Jan 27, 2010 23:37 UTC (Wed) by nevyn (subscriber, #33129) [Link]
> Postfix dereference is better precisely because dwheeler's mistaken
> interpretation is possible only with prefix dereference.
You can always get it wrong:
while (*dst++ = *src++) ;
!=
while (dst^++ = src^++) ;
...and:
++*dst;
!=
++dst^;
...maybe if you are used to it, it does seem marginally better (and I guess both of the above postfix examples could give warnings). But IMO the much bigger win is to have something that 99.999% of the programmers on the planet will instantly understand (and make porting code easier), instead of having them say WTF!
Think carefully Posted Jan 28, 2010 1:36 UTC (Thu) by droundy (subscriber, #4559) [Link]
Fortunately, these examples don't apply to go, since go lacks pointer
arithmetic. Also, the ++ operator is changed to a statement in go, also to avoid this sort of confusion.
Think carefully Posted Jan 28, 2010 2:12 UTC (Thu) by viro (subscriber, #7872) [Link]
This is complete BS; *p->field and (*p)->field _never_ will be both accepted by compiler - with the former p has to be a pointer to struct or union, while with the latter it has to be a pointer to pointer to struct or union. There's no chance whatsoever that such typo will not be caught as soon as e.g. i = 2 * (3 + 4(; would be.
Get yourself a better example...
Think carefully Posted Jan 28, 2010 7:40 UTC (Thu) by ncm (subscriber, #165) [Link]
Examples are easy to concoct, but why should I have to wait for the compiler to tell me it's wrong, if a better notation means I don't get it wrong in the first place?
Think carefully Posted Jan 28, 2010 20:32 UTC (Thu) by viro (subscriber, #7872) [Link]
Care to provide any evidence supporting the claim that this kind of braino is frequent? IME it is very low-frequency and my anecdotes are worth as much as yours (i.e. nothing).
FWIW, it _is_ resolvable - comparison of frequencies of {member(deref(deref(...))), postfix increment/decrement(deref(...))} with those of deref(prefix increment/prefix decrement(...)) would make a good first approximation. And that can be measured, unlike the frequencies of brainos averaged by programmers. Feel free to take gcc (or sparse, which is easier to hack) and add tree-walker that would count such nodes in expression trees. Run it on sufficiently large and diverse codebase and report the results. Hell, extend that to other combinations of operations, add analysis of number of parens needed with different choices of precedences, prefix vs. postfix, associativity and you've got a publishable paper out of it.
Without any kind of hard data it's basically YAHolyWar and as such its proper place is in alt.sex.masturbation, not here...
Think carefully Posted Jan 28, 2010 22:32 UTC (Thu) by efexis (guest, #26355) [Link]
Here's more of a place for civilised discussion, and whilst it's obviously preferable to have subjectivity not given in the tone of objectivity (it can confuse those who are learning) it's also just as preferable to have disagreements given in a more agreeable tone than refering to someones opinions as "complete BS" :-p
Think carefully Posted Jan 29, 2010 3:19 UTC (Fri) by ncm (subscriber, #165) [Link]
I see that you are not interested in a civilized discussion. Why post at all?
Irrelevant. Posted Jan 28, 2010 8:34 UTC (Thu) by alextingle (guest, #20593) [Link] Irrelevant. I can write a compiler for any convoluted syntax I care to conceive:Just because the compiler can parse it without ambiguity, doesn't make it a good choice of syntax.
Still not clear it's better Posted Jan 28, 2010 13:13 UTC (Thu) by nlucas (subscriber, #33793) [Link]
Even better would be to do what D does. If you want a member of struct pointed by a pointer then it's no different from any other variable. Just use the . (dot).
Still not clear it's better Posted Jan 28, 2010 15:31 UTC (Thu) by zmower (subscriber, #3005) [Link]
Ada also uses dot notation. You can do A.Field to implicitly access a field or A.all to explicitly deference an access type. We prefer := for assignment and = for comparison. Thankyou Pascal.
a.b.c.d.e := a.b.c.d.e * p.q.r * x(2).all;
|
|||||||||||||