Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > #define BYTES *8

Reply
Thread Tools

#define BYTES *8

 
 
Keith Thompson
Guest
Posts: n/a
 
      08-28-2012
"Scott Fluhrer" <(E-Mail Removed)> writes:
> "James Kuyper" <(E-Mail Removed)> wrote in message
> news:k1iiib$jqi$(E-Mail Removed)...
>> 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) http://www.velocityreviews.com/forums/(E-Mail Removed) <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"
 
Reply With Quote
 
 
 
 
Eric Sosman
Guest
Posts: n/a
 
      08-29-2012
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
(E-Mail Removed)d
 
Reply With Quote
 
 
 
 
Adrian Ratnapala
Guest
Posts: n/a
 
      08-30-2012

> 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.

 
Reply With Quote
 
Joe Pfeiffer
Guest
Posts: n/a
 
      08-30-2012
JohnF <(E-Mail Removed)> 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.
 
Reply With Quote
 
Eric Sosman
Guest
Posts: n/a
 
      08-31-2012
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
(E-Mail Removed)d
 
Reply With Quote
 
Ben Bacarisse
Guest
Posts: n/a
 
      08-31-2012
Eric Sosman <(E-Mail Removed)> 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.
 
Reply With Quote
 
JohnF
Guest
Posts: n/a
 
      08-31-2012
Ben Bacarisse <(E-Mail Removed)> 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: (E-Mail Removed) where j=john and f=forkosh )
 
Reply With Quote
 
BartC
Guest
Posts: n/a
 
      08-31-2012
"Ben Bacarisse" <(E-Mail Removed)> wrote in message
news:0.42024609db3e0dd44276.20120831024906BST.8739 (E-Mail Removed)...
> Eric Sosman <(E-Mail Removed)> 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

 
Reply With Quote
 
Ben Bacarisse
Guest
Posts: n/a
 
      08-31-2012
"BartC" <(E-Mail Removed)> writes:

> "Ben Bacarisse" <(E-Mail Removed)> wrote in message
> news:0.42024609db3e0dd44276.20120831024906BST.8739 (E-Mail Removed)...

<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.
 
Reply With Quote
 
88888 Dihedral
Guest
Posts: n/a
 
      08-31-2012
On Friday, August 31, 2012 4:32:57 PM UTC+8, JohnF wrote:
> Ben Bacarisse <(E-Mail Removed)> 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: (E-Mail Removed) 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.





 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Ratio of Bytes Delayed to Bytes Sent netproj Cisco 0 12-21-2005 08:08 PM
4-bytes or 8-bytes alignment? mrby C Programming 8 11-02-2004 08:45 PM
Private Bytes vs. # Bytes in all Heaps in Perfmon Jason Collins ASP .Net 3 02-18-2004 03:59 PM
Re: receiving Bytes and sending Bytes Ieuan Adams Computer Support 0 07-24-2003 07:46 PM
Re: receiving Bytes and sending Bytes The Old Sourdough Computer Support 0 07-23-2003 01:23 PM



Advertisments