Countdown "operator"
Beej Jorgensen
I found it on a web page of Javascript hacks, here converted to C:
------------------------ 8< ------------------------
#include <stdio.h>
int main (void)
{
int i = 10;
while (i --> 0) {
printf("i = %d\n", i); // 9...0
}
return 0;
}
------------------------ >8 ------------------------
But I admit it made me laugh, so I'm sharing it. Apologies if this is a
well-known gimmick that I just missed all these years.
-Beej
Albert
> Let me preface this by saying that I strongly disapprove of it. :-)
What part(s) of it do you disapprove?
???
Albert
Beej Jorgensen
> What part(s) of it do you disapprove?
I disapprove of the non-idiomatic usage of the --> operator. Er,
"operators".
-Beej
James Dow Allen
> Let me preface this by saying that I strongly disapprove of it. :-)
> while (i --> 0) /* Countdown */
And who said C wasn't "readable"? :-)
(I'm kidding, I'm kidding! I'd be laughing, but dragging the coder
offstage with a hook *while* laughing.)
Thank you for posting this, Beej. C can be fun and interesting to
read even when it doesn't involve some esoteric compliance question.
As an example of recently posted interesting-looking code
where *no one* actually answered the implicit question,
I'd again ask c.l.c'ers to state their opinion on which of
Fragment A or Fragment B is "better":
Fragment A:
switch (color) {
...
case ORANGE:
yellowish_stuff();
goto reddish;
case PURPLE:
purplish_stuff();
case RED:
reddish:
reddish_stuff();
break;
...
}
Fragment B:
switch (color) {
...
case ORANGE:
yellowish_stuff();
if (0) {
case PURPLE:
purplish_stuff();
}
case RED:
reddish_stuff();
break;
...
}
(I wish there was gambling going on here! I'd bet there are more
responses of the form "I don't like *either* fragment" than there
are responses from people willing to state an A vs B preference. :-)
James Dow Allen
Nick
Here we go!
for(;;) {
switch(colour) {
case ORANGE:
yellowish_stuff();
colour = RED;
continue;
case PURPLE:
purplish_stuff();
colour = RED;
continue;
case RED:
reddish_stuff();
break;
case NIGHTMARE_GREEN:
strossian_stuff();
break;
...
}
break;
}
I can't decide if this is a monstrosity or has something going for it.
It does make clear that ORANGE and PURPLE are the same, in that they
both then call red. The first does this after a little bit of thought.
The second I really hate. So my vote is for the explicit gotos rather
than the implicit ones and the executed code within if(0), if I have to
choose between the two.
--
Online waterways route planner | http://canalplan.eu
Plan trips, see photos, check facilities | http://canalplan.org.uk
Christopher Bazley
Nick <3-no...@temporary-address.org.uk> wrote:
> Here we go!
Normally I like to use 'continue' a lot, but I can't help feeling that
you are abusing it here. I doubt that all C compilers would be clever
enough to optimise the loop away entirely.
> It does make clear that ORANGE and PURPLE are the same, in that they
> both then call red.
Of course, your version isn't quite equivalent because you might want
to retain the knowledge that ORANGE and PURPLE are distinct from RED.
> The first does this after a little bit of thought.
> The second I really hate. So my vote is for the explicit gotos rather
> than the implicit ones and the executed code within if(0), if I have to
> choose between the two.
I concur, although personally I would have done it like this:
switch (colour)
{
...
case ORANGE:
yellowish_stuff();
reddish_stuff();
break;
case PURPLE:
purplish_stuff();
/* FALL THROUGH */
case RED:
reddish_stuff();
break;
...
}
--
Chris Bazley
Star Fighter 3000: http://starfighter.acornarcade.com/
Christopher Bazley
Beej Jorgensen <be...@beej.us> wrote:
I am going through a phase of using 'unsigned int' for all variables
which can never have valid negative values. (I would be interested in
people's thoughts on that, although I think I'm aware of most of the
potential pitfalls.)
Anyway, I find the idiom that you highlighted useful for counting down
to 0 without looping forever due to unsigned integer underflow:
unsigned int i = 10;
while (i-- > 0)
{
...
}
However, I would never space it as your Javascript hacker did. :-)
I usually cast the return value of the standard library function
'rand' to 'unsigned int' so that I can get the remainder of an
unsigned division by a constant power of two (signed division would be
slower because a raw bitwise shift has the wrong rounding behaviour).
Often I wish that 'rand' returned 'unsigned int' rather than 'int'!
Beej Jorgensen
> However, I would never space it as your Javascript hacker did. :-)
I do find it a little weird that my only complaint about it is the
spacing--seems kind of petty. But I suppose there are holy wars about
brace styles, so maybe I shouldn't feel too bad. :)
-Beej
Ben Pfaff
> while (i --> 0) {
> printf("i = %d\n", i); // 9...0
> }
It makes me laugh too. Thanks for sharing it--this is the first
time I've seen it.
--
"If I've told you once, I've told you LLONG_MAX times not to
exaggerate."
--Jack Klein
Seebs
Lemme go for both of those: I don't like either, but A's (IMHO) clearly less
awful.
-s
--
Copyright 2010, all wrongs reversed. Peter Seebach / usenet...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
Richard Harter
Given the choice between A, B, and committing suicide, I would
choose A, but it's a close call.
As a followup, what about using two switches:
switch (colour) {
case YELLOW:
yellowish_stuff();
break;
case PURPLE:
purplish_stuff();
break;
case NIGHTMARE_GREEN:
strossian_stuff();
break;
}
switch (colour) {
case YELLOW:
case PURPLE:
case RED:
reddish_stuff();
break;
)
Richard Harter, c...@tiac.net
http://home.tiac.net/~cri, http://www.varinoma.com
Infinity is one of those things that keep philosophers busy when they
could be more profitably spending their time weeding their garden.
Alan Curry
Richard Harter <c...@tiac.net> wrote:
>
>As a followup, what about using two switches:
>
> switch (colour) {
> case YELLOW:
> yellowish_stuff();
> break;
> case PURPLE:
> purplish_stuff();
> break;
> case NIGHTMARE_GREEN:
> strossian_stuff();
> break;
> }
So far so good.
>
> switch (colour) {
> case YELLOW:
> case PURPLE:
> case RED:
> reddish_stuff();
> break;
> )
If the numbers are chosen wisely, that can be reduced to
if(colour & REDDISH)
reddish_stuff();
For example,
enum { YELLOW_=1, PURPLE_, RED_, NIGHTMARE_GREEN }
#define REDDISH 0x80000000
#define YELLOW (YELLOW_|REDDISH)
#define PURPLE (PURPLE_|REDDISH)
#define RED (RED_|REDDISH)
"reddish" is a boolean component, so it *should* be a single bit.
--
Alan Curry
Nick
I was lying in bed thinking of that one, along with some simple "call
two others" functions and a function table.
It really depends on how many you've got, how many multiple cases etc.
James Dow Allen
> Given the choice between A, B, and committing suicide, I would
> choose A, but it's a close call.
It *appears* there's a c.l.c consensus against the
ridiculous "if (0)" construct, but I'm not sure how to
score Mr. Harter's response.
Richard, would your preference change if the suicide method
involved you and Elin Nordegren beating each other to
death with feather boas?
One solution I might argue against (though I'm sure I've
used it myself) is the one based on
> case ORANGE:
> yellowish_stuff();
> reddish_stuff();
> break;
> case PURPLE:
> purplish_stuff();
> /* FALL THROUGH */
> case RED:
> reddish_stuff();
> break;
FALL THROUGH is a (very mild) form of 'goto', right?
The details of "reddish_stuff();" matter (is it just
a function, or a bunch of in-line code?) but if duplicating
it seems convenient, why not just duplicate it *both*
places?
BTW, while I'll confess to goto'ing inside switches,
hither and yon like a drunken frog, that device is *not*
one I'd pick for a "Gotos are Good" essay.
James Dow Allen
John Bode
Never seen it before, but if I do in the future, I'll treat it the
same way as I treat preprocessor abuse; beat the offender about the
head and shoulders with a first-edition copy of "C: The Complete
Reference" because it's big and heavy and absolutely useless as
anything other than a bludgeon.
Tim Rentsch
Just a minor correction... Using '-->' as an "operator" is
in fact idiomatic. It is not a _common_ idiom, but still it
is an idiom.
Keith Thompson
It's idio-something.
--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Richard Tobin
Tim Rentsch <t...@alumni.caltech.edu> wrote:
>Just a minor correction... Using '-->' as an "operator" is
>in fact idiomatic. It is not a _common_ idiom, but still it
>is an idiom.
How rare does something have to be to not be idiomatic?
-- Richard
--
Please remember to mention me / in tapes you leave behind.
John Bode
Ugh. A is ever so slightly less horrible than B (B bypasses a control
structure, which to me is a bigger no-no than using a goto), but both
are grounds for a beating AFAIC.
I'd throw both of them out and rely on a table:
void (*combinations[NUM_COLORS][NUM_PRIMARIES])(void) = {
{ /* RED */ reddish_stuff, NULL, NULL, ... },
{ /* YELLOW */ yellowish_stuff, NULL, NULL, ... },
{ /* BLUE */ bluish_stuff, NULL, NULL, ... },
{ /* ORANGE */ yellowish_stuff, reddish_stuff, NULL, ... },
{ /* PURPLE */ bluish_stuff, reddish_stuff, NULL, ... },
...
};
...
for (;;)
{
size_t i;
for (i = 0; i < NUM_PRIMARIES; i++)
{
if (combinations[color][i] != NULL)
(*combinations[color][i])();
}
}
so, thinking about it, I'm probably *not* one to talk about ugly code.
Mixing subscripts with a function pointer dereference is bound to get
at least a few heads scratching (at least it's not a nested function
pointer dereference, which is even uglier). And if the order of the
function calls is important, then that information is hidden in the
table instead of made explicit in the loop. But I still prefer a
method like this over a big switch, *especially* if cases in the
switch are dependent on each other.
Richard Harter
Tobin) wrote:
>In article <kfnfx5gyi...@x-alumni2.alumni.caltech.edu>,
>Tim Rentsch <t...@alumni.caltech.edu> wrote:
>
>>Just a minor correction... Using '-->' as an "operator" is
>>in fact idiomatic. It is not a _common_ idiom, but still it
>>is an idiom.
>
>How rare does something have to be to not be idiomatic?
Rarity is not to the point. It is the usage that makes it an
idiom.
Ben Bacarisse
<snip>
> I'd throw both of them out and rely on a table:
>
> void (*combinations[NUM_COLORS][NUM_PRIMARIES])(void) = {
> { /* RED */ reddish_stuff, NULL, NULL, ... },
> { /* YELLOW */ yellowish_stuff, NULL, NULL, ... },
> { /* BLUE */ bluish_stuff, NULL, NULL, ... },
> { /* ORANGE */ yellowish_stuff, reddish_stuff, NULL, ... },
> { /* PURPLE */ bluish_stuff, reddish_stuff, NULL, ... },
> ...
> };
> ...
> for (;;)
> {
> size_t i;
> for (i = 0; i < NUM_PRIMARIES; i++)
> {
> if (combinations[color][i] != NULL)
> (*combinations[color][i])();
The star and the first pair of brackets are not needed nowadays --
leaving them off tidies things up to my mind. In "old" C you needed
the *, but function calling is now defined as happening through a
pointer. Names of functions get converted to pointers (rather like
arrays do) to make named_function() mean what it should.
> }
> }
<snip>
--
Ben.
Richard Tobin
Richard Harter <c...@tiac.net> wrote:
>>>Just a minor correction... Using '-->' as an "operator" is
>>>in fact idiomatic. It is not a _common_ idiom, but still it
>>>is an idiom.
>>How rare does something have to be to not be idiomatic?
>Rarity is not to the point. It is the usage that makes it an
>idiom.
The fact that something is used by someone does not make it idiomatic.
A use of language is usually called idiomatic if it's one which
speakers of the language commonly use. It may be contrasted with
grammatical use (which obviously doesn't apply in the case of
programming languages - ungrammatical C will normally not compile), or
with grammatical but but less natural use. Of course something may be
idiomatic within a subset of the speakers of a language, but find one
or two people who use it doesn't make it idiomatic. Otherwise every
phrase that has ever been used would be idiomatic, making the term
useless.
For example, in C "for(i=0; i<n; i++)" is idiomatic, while
"for(i=0; n>i; i++)" is not.
Writing "-->" as if it were an operator is certainly not idiomatic C.
Richard Tobin
Stefan Ram <r...@zedat.fu-berlin.de> wrote:
> In the field of natural languages,
> it is required that the meaning cannot be derived in a
> regular manner from the meaning of its constituents:
>
> [A]n idiom is an expression, word, or phrase whose sense
> means something different from what the words literally imply.
>
>http://en.wikipedia.org/wiki/Idiom
You don't want to believe everything you read in Wikipedia, though
no doubt in some contexts it is used with that implication.
Look up "idiom" in Fowler's Modern English Usage. (Strangely
I can't find a free online version - I would have expected it
to be available, as he died in 1933.)
Richard Harter
Tobin) wrote:
>In article <4b6c3255....@text.giganews.com>,
>Richard Harter <c...@tiac.net> wrote:
>
>>>>Just a minor correction... Using '-->' as an "operator" is
>>>>in fact idiomatic. It is not a _common_ idiom, but still it
>>>>is an idiom.
>
>>>How rare does something have to be to not be idiomatic?
>
>>Rarity is not to the point. It is the usage that makes it an
>>idiom.
>
>The fact that something is used by someone does not make it idiomatic.
>
>A use of language is usually called idiomatic if it's one which
>speakers of the language commonly use. It may be contrasted with
>grammatical use (which obviously doesn't apply in the case of
>programming languages - ungrammatical C will normally not compile), or
>with grammatical but but less natural use. Of course something may be
>idiomatic within a subset of the speakers of a language, but find one
>or two people who use it doesn't make it idiomatic. Otherwise every
>phrase that has ever been used would be idiomatic, making the term
>useless.
Idiomatic has more than one meaning. Thus, idiomatic C is C that
is written using the commonly occurring idioms in C code. On the
other hand it can also refer to idioms used in writing by an
individual, a group of people, a school of writing, etc.
An idiom, on the hand, is an stylistic convention within a body
of writing. It can be a dead metaphor, e.g., kick the bucket, or
simply a special way of saying something. You and I probably
each have our own idioms, both in our written language and in our
code. Idioms that are peculiar to a small group or a single
person are idiosyncratic.
Your argument that "every phrase that has been used would be
idiomatic" is not correct; neither is your distinction between
grammatical use and idiomatic use.
>
>For example, in C "for(i=0; i<n; i++)" is idiomatic, while
>"for(i=0; n>i; i++)" is not.
The former is idiomatic C, the latter is not. Unless there is
some benighted soul who regularly uses the latter form, it is not
idiomatic at all.
>
>Writing "-->" as if it were an operator is certainly not idiomatic C.
Indeed. On the other hand it appeals to anyone with a puckish
sense of humor.
Tim Rentsch
> In article <kfnfx5gyi...@x-alumni2.alumni.caltech.edu>,
> Tim Rentsch <t...@alumni.caltech.edu> wrote:
>
>>Just a minor correction... Using '-->' as an "operator" is
>>in fact idiomatic. It is not a _common_ idiom, but still it
>>is an idiom.
>
> How rare does something have to be to not be idiomatic?
My goodness, "idiom" is such a charming word. It has a variety
of different meanings, some distinctly at odds with others.
"Idiom" can mean constructions limited to a particular group of
people, or local dialect. Or it can mean the sets and types of
constructions generally used in the language. "Idiom" can mean a
phrase in one language that suffers upon translation to another
language. Related to that, it can mean a construction that is
taken to mean something different than what it literally says
(eg, "kick the bucket"). "Idiom" can refer to the style of
language particular to even a single individual ("the idiom of
Hemingway"). Needless to say I have cribbed from several online
dictionaries to get these various definitions.
The online Merriam-Webster has this definition (among others):
an expression in the usage of a language that is peculiar to
itself grammatically
It is in this sense that I referred to '-->' as idiomatic.
Sometime in (I think) the 1960's or 1970's the word "idiom"
started being applied to forms (often non-obvious) of expressing
particular computations in programming languages. I have fond
memories of Alan Perlis lecturing on idioms in APL (where the
word idiom was first applied to computer programs? I'm not
sure)... Of course, as different people in a programming
community discovered these (or were told them), many of these
idioms became fairly widespread, thus strengthening another sense
of the word idiom. My recollection, however, from now so many
years ago, is that originally "idiom" in programming language was
used in this sense of a phrasing for accomplishing something that
wasn't immediately obvious in its meaning; hence, idiom. The
commonality came later as the more useful or more appealing
idioms were picked up by the programming community as a group.
None of the foregoing is meant to dispute the notion that "idiom"
usually means something fairly common or widespread. I'm just
trying to explain the sense of my previous comment.
Tim Rentsch
> [snip]
>
> Writing "-->" as if it were an operator is certainly not idiomatic C.
It is not common C idiom (in one sense of the word idiom).
But it is idiomatic (in another sense of the word idiom).
Tim Rentsch
> ric...@cogsci.ed.ac.uk (Richard Tobin) writes:
>>A use of language is usually called idiomatic if it's one which
>>speakers of the language commonly use.
>
> In computer programming. In the field of natural languages,
> it is required that the meaning cannot be derived in a
> regular manner from the meaning of its constituents:
>
> >>[A]n idiom is an expression, word, or phrase whose sense
> means something different from what the words literally imply.<<
>
> http://en.wikipedia.org/wiki/Idiom
>
> . For example, one might say, that the meaning of >>--<< is
> idiomatic, because it is composed of two >>-<< >>words<< but
> it's meaning cannot be derived from the meaning of >>-<<.
>
> However, this is not the usual meaning of >>idiomatic<<
> in programming languages.
>
> In programming, it simply means a common combination of
> language elements. (As you wrote.)
Certainly there are common idioms. However an idiomatic
construction need not be widespread to qualify as an idiom.
The wikipedia article
http://en.wikipedia.org/wiki/Programming_idiom
mentions "recurring" but not "common" or "widespread".
If I were to use '-->' all over my own code (which I
don't, by the way) then that by itself would qualify
it as an idiom.
James Dow Allen
> On Jan 30, 2:13 am, James Dow Allen <jdallen2...@yahoo.com> wrote:
> > I'd again ask c.l.c'ers to state their opinion on which of
> > Fragment A or Fragment B is "better":
> > Fragment A:
> > [snip]
> > goto reddish;
> .
> Ugh. A is ever so slightly less horrible than B (B bypasses a control
> structure, which to me is a bigger no-no than using a goto), but both
> are grounds for a beating AFAIC.
> .
> I'd throw both of them out and rely on a table:
> void (*combinations[NUM_COLORS][NUM_PRIMARIES])(void) = {
> { /* RED */ reddish_stuff, NULL, NULL, ... },
> { /* YELLOW */ yellowish_stuff, NULL, NULL, ... },
> { /* BLUE */ bluish_stuff, NULL, NULL, ... },
> { /* ORANGE */ yellowish_stuff, reddish_stuff, NULL, ... },
> { /* PURPLE */ bluish_stuff, reddish_stuff, NULL, ... },
> ...
I wonder if you and I have different ideas of what "readability"
is, or what big software programs are like. I imagined the
purple/orange branchout as a tiny part of a big system.
I would *hate* to try to follow a program with dozens of
tables like the one you outline.
James
Seebs
> Sometime in (I think) the 1960's or 1970's the word "idiom"
> started being applied to forms (often non-obvious) of expressing
> particular computations in programming languages.
Amusingly, that usage is now idiomatic among programmers.
Tim Rentsch
> On 2010-02-06, Tim Rentsch <t...@alumni.caltech.edu> wrote:
>> Sometime in (I think) the 1960's or 1970's the word "idiom"
>> started being applied to forms (often non-obvious) of expressing
>> particular computations in programming languages.
>
> Amusingly, that usage is now idiomatic among programmers.
Not idiomatic exactly (though it is idiom in one sense
of the word idiom); more like part of the argot of
the programming community.
Flash Gordon
I've worked on systems where there were massive tables of stuff. Whether
those tables are part of the code or in separate files they can often be
a good way of dealing with things. Of course, they need to be documented
and an appropriate set of structures used.
--
Flash Gordon
Kaz Kylheku
> In article <4b6c3255....@text.giganews.com>,
> Richard Harter <c...@tiac.net> wrote:
>
>>>>Just a minor correction... Using '-->' as an "operator" is
>>>>in fact idiomatic. It is not a _common_ idiom, but still it
>>>>is an idiom.
>
>>>How rare does something have to be to not be idiomatic?
>
>>Rarity is not to the point. It is the usage that makes it an
>>idiom.
>
> The fact that something is used by someone does not make it idiomatic.
>
> A use of language is usually called idiomatic if it's one which
> speakers of the language commonly use.
An idiom is some phrase that has is not rooted in normal syntax and
semantics. Idioms may be rare (e.g. particular to a regional dialect).
Example: ``Don't try to pick that phrase apart logically; it's an
idiom!''
Since there is no shortage of words denoting frequent use, like
``commonplace'', ``cliche'' or ``hackneyed'', there is no need to extend
``idiom'' into this territory.
> For example, in C "for(i=0; i<n; i++)" is idiomatic, while
This is a C programming cliche.
Its meaning follows properly from its constituent elements; therefore it
is not an idiom.
Some of the special exception hacks in the C language might be called
idioms, like an integral zero constant denoting a null pointer, even
though the general rule is that integers and pointers are incompatible.
Richard Tobin
Kaz Kylheku <kkyl...@gmail.com> wrote:
>An idiom is some phrase that has is not rooted in normal syntax and
>semantics. Idioms may be rare (e.g. particular to a regional dialect).
[...]
>Since there is no shortage of words denoting frequent use, like
>``commonplace'', ``cliche'' or ``hackneyed'', there is no need to extend
>``idiom'' into this territory.
[...]
>This is a C programming cliche.
>
>Its meaning follows properly from its constituent elements; therefore it
>is not an idiom.
I'm afraid all your comments on what these words mean in English
disagree with my experience of them. "Idiom" does not necessarily
imply (or exclude) non-grammaticality or illogicality. It may simply
be a particular choice of expression preferred over equivalent ones.
Nor does it have the implications of the other words you mention. In
particular "cliche" and "hackneyed' have a negative connotation not
present in "idiom".
Again, I refer you to the article in Fowler.
Beej Jorgensen
> What part(s) of it do you disapprove?
Man, look where 5 days in Seattle gets me. I'll try again:
I disapprove of the [INSERT ADJECTIVE THAT MAKES SENSE HERE] usage of
the --> operator. Er, "operators".
I hope that is an acceptable solution to all involved. ;-)
-Beej
John Bode
>
> - Show quoted text -
Well, like I said in the post immediately after that example, I'm
probably not the best authority on what constitutes readable code. I
admit that I use LUTs of function pointers a *lot*, probably more than
most people, which makes my code a little harder for others to
follow. For me they tend to be the most straightforward solution to a
lot of problems, especially state-driven stuff.