«

"Scott Fluhrer" <> writes:
> "James Kuyper" <> wrote in message
> news:k1iiib$jqi$...
>> On 08/28/2012 03:44 AM, JohnF wrote:
>>> #define BYTES *8
>>
>> However, there's another issue
>> as well, even if we accept the the way you want to use this macro, it's
>> defined wrong. It should, for the sake of portability, be
>>
>> #include <limits.h>
>> #define BYTES *CHAR_BIT
>
> Whether this last part is good advice depends on what the original
> programmer is trying to do. If he really does mean 'the number of bits in
> the platform-dependent char type', then yes, this works well. However, if
> he mearns 'the number of bits within a platform-independent octet' (for
> example, what's actually transmitted over TCP), this is less good.
>
> Remember, the meaning that C assigns to the word 'byte' isn't the only
> meaning that word can have.

Then calling it OCTETS rather than BYTES would improve clarity.

--
Keith Thompson (The_Other_Keith) kst- <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

On 8/29/2012 11:10 AM, Kenneth Brody wrote:
> On 8/28/2012 4:38 AM, Keith Thompson wrote:
> [...]
>> Something similar: Years ago, I thought that this:
>>
>> #define EVER (;
>>
>> was clever, because I could write:
>>
>> for EVER {
>> /* ... */
>> }
>>
>> I still think it's clever. I just no longer think that's a good thing.
>
>
>
> Perhaps:
>
> #define FOREVER for(;
>
> Not that I'd ever use such a thing, of course. Still clever. Still
> "not really a good thing to do".

In my own young and foolish days, I used

#define until(x) while(!(x))

believing it improved readability. Foolishness never leaves us
altogether, but youth and inexperience do -- and clevernesses of
this kind went into my personal "Wish I'd never done that" file
long ago. (Right next to the FORTRAN II code that avoided an IF
by using a computed GOTO.)

--
Eric Sosman
d

> In my own young and foolish days, I used
>
> #define until(x) while(!(x))
>
> believing it improved readability. Foolishness never leaves us

I wouldn't do that in C, but the "until" is one of the things that I did
enjoy about Perl.

JohnF <> writes:

> Anything wrong with that, i.e., with #define BYTES *8
> to multiply by 8? It looked a little weird to me, but
> the more obvious #define BYTES(x) ((x)* isn't what
> I wanted to write. This was to express units of measurement,
> e.g., int bits = so_many BYTES; rather than
> int bits=BYTES(so_many); . I just wanted to read and write
> it the first way, and my test program
> #define BYTES *8
> #include <stdio.h>
> int main ( int argc, char *argv[] ) {
> int bytes=(argc<2?1:atoi(argv[1])),
> bits = bytes BYTES;
> printf("%d bytes = %d bits\n",bytes,bits);
> return(0); }
> works fine (and compiles with no -pedantic warnings).
> But that #define BYTES *8 still looks a little funky to me.
> I realize 2+2 BYTES must be written (2+2)BYTES, but is there
> any other kind of "gotcha"?

That way lies madness. Using macroes to invent new syntax for C is a
Bad Idea. It looks good when you come up with it, it looks good when
you first code it up, it turns out to be a disaster some time down the
road when you're maintaining it. There's nothing particularly wrong
with the specific macro you're suggesting (except possible surprises
with operator precedence), but typically when people do that they also
define a bunch of other similar macroes that turn into a nightmare.

Yes, I did once define a macro

#define EVER (;

but I was much, much younger then.

On 8/30/2012 7:08 PM, Kenneth Brody wrote:
> On 8/29/2012 11:36 AM, Eric Sosman wrote:
>> On 8/29/2012 11:10 AM, Kenneth Brody wrote:
> [...]
>>> Perhaps:
>>>
>>> #define FOREVER for(;
>>>
>>> Not that I'd ever use such a thing, of course. Still clever. Still
>>> "not really a good thing to do".
>>
>> In my own young and foolish days, I used
>>
>> #define until(x) while(!(x))
>>
>> believing it improved readability. Foolishness never leaves us
>> altogether, but youth and inexperience do -- and clevernesses of
>> this kind went into my personal "Wish I'd never done that" file
>> long ago. (Right next to the FORTRAN II code that avoided an IF
>> by using a computed GOTO.)
>
> Ah. You must have read that famous article "If Considered Harmful".

<off-topic>

Perhaps you overlooked the Roman numeral. In those days,
FORTRAN's only IF had the form

IF ( expression ) n1, n2, n3

.... with the meaning: "GOTO statement number `n1', `n2', or `n3'
as `expression' is negative, zero, or positive." Thus

IF (X) 1, 2, 1

.... was a zero/nonzero test,

IF (X) 1, 2, 2

.... was a negative/nonnegative test, and so on. IF(X) 1,1,1
was a plain old unconditional GOTO 1 in disguise.

FORTRAN IV added an alternate kind of IF that was closer to
what we find in C -- but only a little bit closer.

<super-off-topic>

Every now and then -- not often, but every now and then --
I find myself longing for the good old three-way IF. A binary
search needs two of these newfangled two-way `if' tests where
one three-way test would suffice, and a similar situation crops
up in the inner loop of Heapsort. Ah, well: Change (even change
for the better) always involves loss.

</super-off-topic>
</off-topic>
</maudlin-reminiscence>

--
Eric Sosman
d

Eric Sosman <> writes:
Borrowing your off-topicality...
> <off-topic>
>
> Perhaps you overlooked the Roman numeral. In those days,
> FORTRAN's only IF had the form
>
> IF ( expression ) n1, n2, n3
>
> ... with the meaning: "GOTO statement number `n1', `n2', or `n3'
> as `expression' is negative, zero, or positive." Thus
>
> IF (X) 1, 2, 1
>
> ... was a zero/nonzero test,
>
> IF (X) 1, 2, 2
>
> ... was a negative/nonnegative test, and so on. IF(X) 1,1,1
> was a plain old unconditional GOTO 1 in disguise.
>
> FORTRAN IV added an alternate kind of IF that was closer to
> what we find in C -- but only a little bit closer.
>
> <super-off-topic>
>
> Every now and then -- not often, but every now and then --
> I find myself longing for the good old three-way IF. A binary
> search needs two of these newfangled two-way `if' tests where
> one three-way test would suffice, and a similar situation crops
> up in the inner loop of Heapsort. Ah, well: Change (even change
> for the better) always involves loss.

I, too, missed it on occasion, but then I got it back! In Haskell, any
type that "inherits" from Ord (all ordered things, in effect) provides a
'compare' function that returns EQ, LT or GT. You then "switch" on the
result. (Scare quotes because Haskell names everything differently.)

Given that C's comparisons (struggling to get topical again) already
produce ints, it would not have seemed odd to have provided, say, <>
that yields -1, 0 or 1 in the expected way. If strcmp and friends had
been similarly constrained, these value could have been sensible named
CMP_LT, CMP_EQ and CMP_GT (or whatever) and we could switch on them with
no magic numbers in sight.

> </super-off-topic>
> </off-topic>
> </maudlin-reminiscence>

--
Ben.

Ben Bacarisse <> wrote:
> ...struggling to get topical again...
I, the op, hereby grant dispensation to all persons
in this thread to get as far off-topic as they like.
--
John Forkosh ( mailto: where j=john and f=forkosh )

"Ben Bacarisse" <> wrote in message
news:0.42024609db3e0dd44276.20120831024906BST.8739 ...
> Eric Sosman <> writes:

> A binary
>> search needs two of these newfangled two-way `if' tests where
>> one three-way test would suffice

(But sounds like an extra subtraction is needed to yield a single 3-way
value.)

>, and a similar situation crops
>> up in the inner loop of Heapsort. Ah, well: Change (even change
>> for the better) always involves loss.
>
> I, too, missed it on occasion, but then I got it back! In Haskell, any
> type that "inherits" from Ord (all ordered things, in effect) provides a
> 'compare' function that returns EQ, LT or GT. You then "switch" on the
> result. (Scare quotes because Haskell names everything differently.)
>
> Given that C's comparisons (struggling to get topical again) already
> produce ints, it would not have seemed odd to have provided, say, <>

<> sometimes means 'not-equal' in other syntaxes.

> that yields -1, 0 or 1 in the expected way.

Such a compare could equally usefully provide an 8-way result: 3 bits that
represent (LT,EQ,GT), giving a value 000B to 111B. With the 3-way scheme,
you can't then feed the result to a switch that wants to deal with LT and
LE, for example, in separate branches.

Not-equal is also badly defined in the 3-way result (either -1 or 1), but is
101B in the 8-way one.

And if you needed to encode the desired comparison itself, to send to a
function for example, then the 8-way code allows you to represent all six
comparisons (000B and 111B are no-ops), instead of just three.

--
Bartc

"BartC" <> writes:

> "Ben Bacarisse" <> wrote in message
> news:0.42024609db3e0dd44276.20120831024906BST.8739 ...
<snip>
>> I, too, missed it on occasion, but then I got it back! In Haskell, any
>> type that "inherits" from Ord (all ordered things, in effect) provides a
>> 'compare' function that returns EQ, LT or GT. You then "switch" on the
>> result. (Scare quotes because Haskell names everything differently.)
>>
>> Given that C's comparisons (struggling to get topical again) already
>> produce ints, it would not have seemed odd to have provided, say, <>
>
> <> sometimes means 'not-equal' in other syntaxes.
>
>> that yields -1, 0 or 1 in the expected way.
>
> Such a compare could equally usefully provide an 8-way result: 3 bits
> that represent (LT,EQ,GT), giving a value 000B to 111B. With the 3-way
> scheme, you can't then feed the result to a switch that wants to deal
> with LT and LE, for example, in separate branches.
>
> Not-equal is also badly defined in the 3-way result (either -1 or 1),
> but is 101B in the 8-way one.
>
> And if you needed to encode the desired comparison itself, to send to
> a function for example, then the 8-way code allows you to represent
> all six comparisons (000B and 111B are no-ops), instead of just three.

Ha! You nearly got me! I'll be honest with you -- I'd commented on
three points before I got that you were joking. If I'd seen it before
my coffee, you'd probably have had a straight answer to chuckle over.

--
Ben.

On Friday, August 31, 2012 4:32:57 PM UTC+8, JohnF wrote:
> Ben Bacarisse <> wrote:
>
> > ...struggling to get topical again...
>
> I, the op, hereby grant dispensation to all persons
>
> in this thread to get as far off-topic as they like.
>
> --
>
> John Forkosh ( mailto: where j=john and f=forkosh )

Well, for an ordered set with comparison operations,

I'll use non-zero, less than for the signed , and smaller
for the unsigned, and just test whether the compiler is
stupid or smart to chunk out results with some goto, i.e. jump
in the final instructions.