Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #25200 > unrolled thread

#define BYTES *8

Back to article view | Back to comp.lang.c

Contents

  #define BYTES *8 JohnF <john@please.see.sig.for.email.com> - 2012-08-28 07:44 +0000
    Re: #define BYTES *8 Mark Bluemel <mark_bluemel@pobox.com> - 2012-08-28 09:07 +0100
    Re: #define BYTES *8 Keith Thompson <kst-u@mib.org> - 2012-08-28 01:38 -0700
      Re: #define BYTES *8 JohnF <john@please.see.sig.for.email.com> - 2012-08-28 09:21 +0000
        Re: #define BYTES *8 "BartC" <bc@freeuk.com> - 2012-08-28 12:34 +0100
          Re: #define BYTES *8 JohnF <john@please.see.sig.for.email.com> - 2012-08-28 12:23 +0000
      Re: #define BYTES *8 Kenneth Brody <kenbrody@spamcop.net> - 2012-08-29 11:10 -0400
        Re: #define BYTES *8 Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-08-29 11:36 -0400
          Re: #define BYTES *8 Adrian Ratnapala <raka@scooter.fritz.box> - 2012-08-30 04:01 +0000
          Re: #define BYTES *8 Kenneth Brody <kenbrody@spamcop.net> - 2012-08-30 19:08 -0400
            <OT> Re: #define BYTES *8 Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-08-30 21:30 -0400
              Re: <OT> Re: #define BYTES *8 Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-08-31 02:49 +0100
                Re: <OT> Re: #define BYTES *8 JohnF <john@please.see.sig.for.email.com> - 2012-08-31 08:32 +0000
                  Re: <OT> Re: #define BYTES *8 88888 Dihedral <dihedral88888@googlemail.com> - 2012-08-31 03:55 -0700
                Re: <OT> Re: #define BYTES *8 "BartC" <bc@freeuk.com> - 2012-08-31 10:58 +0100
                  Re: <OT> Re: #define BYTES *8 Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-08-31 11:53 +0100
                    Re: <OT> Re: #define BYTES *8 "BartC" <bc@freeuk.com> - 2012-08-31 12:39 +0100
                      Re: <OT> Re: #define BYTES *8 Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-08-31 15:35 +0100
                        Re: <OT> Re: #define BYTES *8 "BartC" <bc@freeuk.com> - 2012-08-31 19:15 +0100
                          Re: <OT> Re: #define BYTES *8 Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-08-31 14:39 -0400
              Re: <OT> Re: #define BYTES *8 Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2012-09-06 15:14 +0300
    Re: #define BYTES *8 "Scott Fluhrer" <sfluhrer@ix.netcom.com> - 2012-08-28 12:24 -0400
      Re: #define BYTES *8 "BartC" <bc@freeuk.com> - 2012-08-28 17:44 +0100
      Re: #define BYTES *8 Keith Thompson <kst-u@mib.org> - 2012-08-28 14:42 -0700
    Re: #define BYTES *8 pete <pfiland@mindspring.com> - 2012-08-28 23:47 -0400
    Re: #define BYTES *8 Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2012-08-29 22:20 -0600
    Re: #define BYTES *8 John Bode <jfbode1029@gmail.com> - 2012-09-06 15:32 -0700
      Re: #define BYTES *8 pete <pfiland@mindspring.com> - 2012-09-06 20:58 -0400
        Re: #define BYTES *8 Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-09-06 21:13 -0400
        Re: #define BYTES *8 Öö Tiib <ootiib@hot.ee> - 2012-09-07 03:00 -0700
          Re: #define BYTES *8 pete <pfiland@mindspring.com> - 2012-09-08 10:00 -0400
      Re: #define BYTES *8 "BartC" <bc@freeuk.com> - 2012-09-07 02:22 +0100
        Re: #define BYTES *8 John Bode <jfbode1029@gmail.com> - 2012-09-07 05:55 -0700
    Re: #define BYTES *8 Tim Rentsch <txr@alumni.caltech.edu> - 2012-09-07 14:20 -0700

Page 2 of 2 — ← Prev page 1 [2]

#26002 — Re: <OT> Re: #define BYTES *8

Eric Sosman <esosman@ieee-dot-org.invalid> writes:
> <super-off-topic>

Nope, not gonna work.
 
>      Every now and then -- not often, but every now and then --
> I find myself longing for the good old three-way IF.

It might get a little clumsy, but there's a compromise
The <=> operator which yields -1, 0, or 1. Your 3-way if 
would be a switch on the outcome of that <=>.

I want that in C. Have done for years. Decades, even.

Phil
-- 
Regarding TSA regulations:
How are four small bottles of liquid different from one large bottle?
Because four bottles can hold the components of a binary liquid explosive,
whereas one big bottle can't. -- camperdave responding to MacAndrew on /.

[toc] | [prev] | [next] | [standalone]

#25255

"James Kuyper" <jameskuyper@verizon.net> wrote in message 
news:k1iiib$jqi$1@dont-email.me...
> 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.

-- 
poncho

[toc] | [prev] | [next] | [standalone]

#25260

"Scott Fluhrer" <sfluhrer@ix.netcom.com> wrote in message 
news:1346170970.561767@rcdn-nntpcache-2...
>
> "James Kuyper" <jameskuyper@verizon.net> wrote in message 
> news:k1iiib$jqi$1@dont-email.me...
>> 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.

Apparently he wants to apply a scale factor to a quantity, by using the 
macro as a suffix to the quantity.

-- 
bartc 

[toc] | [prev] | [next] | [standalone]

#25316

"Scott Fluhrer" <sfluhrer@ix.netcom.com> writes:
> "James Kuyper" <jameskuyper@verizon.net> wrote in message 
> news:k1iiib$jqi$1@dont-email.me...
>> 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-u@mib.org  <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"

[toc] | [prev] | [next] | [standalone]

#25351

JohnF wrote:
> 
> 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)*8) 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"?

#include <stdio.h>
#include <stdlib.h>
#include <limits.h>

#define BITS(X)  ((X) * CHAR_BIT)

int 
main (int argc, char *argv[]) 
{
    unsigned bytes = argc < 2 ? 1 : atoi(argv[1]);
    unsigned bits  = BITS(bytes);

    printf("%u bytes = %u bits\n", bytes, bits);

    return 0; 
}

-- 
pete

[toc] | [prev] | [next] | [standalone]

#25496

JohnF <john@please.see.sig.for.email.com> 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)*8) 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.

[toc] | [prev] | [next] | [standalone]

#26021

On Tuesday, August 28, 2012 2:44:24 AM UTC-5, JohnF wrote:
> Anything wrong with that, i.e., with  #define BYTES *8
> to multiply by 8? 

It doesn't read well in the context of regular C code.  
Consider:

    int x = 10 BYTES;

This scans as "I'm assigning 10 bytes to x"; it does not
scan (at least to me) as "I'm multiplying 10 by 
the number of bits in a byte (more correctly, an octet)
and assigning the result to x".  I read it as a 
descriptive label, not a pseudo-postfix operator.   
 
This simply isn't how C code normally behaves, and
I feel it will be *surprising* (in the bad sense) 
to anyone reading it the first time.

If you need to do conversions from one unit to another,
create a function or function-like macro with a name
that *clearly* conveys the nature of the conversion:

#define TO_BITS(x)  ( sizeof (x) * CHAR_BIT )
#define TO_BYTES(x) ( (x) / CHAR_BIT )

int x = TO_BITS(10);

It's not pretty, but there's no question of what's 
happening here.  I'm all for making code scan
more easily, but not at the cost of masking
the underlying operation.  

In general, I'm not fond of attempts to use the
preprocessor to fake redefining elements of C
syntax; I've been in that movie more than once,
and it always, always ends in tears.  

Will it bite you in the ass from a technical 
standpoint?  Well, you've already pointed out 
the issue with something like 

   int x = 2 + 2 BYTES;

which, for *this specific conversion*, is probably
the extent of the heartburn you're going to encounter.
It depends on how complex the conversion needs to be,
really.  

[toc] | [prev] | [next] | [standalone]

#26024

John Bode wrote:
 
> If you need to do conversions from one unit to another,
> create a function or function-like macro with a name
> that *clearly* conveys the nature of the conversion:
> 
> #define TO_BITS(x)  ( sizeof (x) * CHAR_BIT )
> #define TO_BYTES(x) ( (x) / CHAR_BIT )

I might be inclined to go a little further.

#define BYTES_TO_BITS(x)  ( sizeof (x) * CHAR_BIT )
#define BITS_TO_BYTES(x)  ( (x) / CHAR_BIT )

-- 
pete

[toc] | [prev] | [next] | [standalone]

#26025

On 9/6/2012 8:58 PM, pete wrote:
> John Bode wrote:
>
>> If you need to do conversions from one unit to another,
>> create a function or function-like macro with a name
>> that *clearly* conveys the nature of the conversion:
>>
>> #define TO_BITS(x)  ( sizeof (x) * CHAR_BIT )
>> #define TO_BYTES(x) ( (x) / CHAR_BIT )
>
> I might be inclined to go a little further.
>
> #define BYTES_TO_BITS(x)  ( sizeof (x) * CHAR_BIT )
> #define BITS_TO_BYTES(x)  ( (x) / CHAR_BIT )

     ... which illustrates one of the fundamental problems with
over-enthusiastic abstraction: "I have a three-bit field, so
it occupies BITS_TO_BYTES(3) bytes, right?"

-- 
Eric Sosman
esosman@ieee-dot-org.invalid
"The speed at which the system fails is usually not important."

[toc] | [prev] | [next] | [standalone]

#26030

On Friday, September 7, 2012 3:58:20 AM UTC+3, pete wrote:
> John Bode wrote:
> > If you need to do conversions from one unit to another,
> > create a function or function-like macro with a name
> > that *clearly* conveys the nature of the conversion:
> > 
> > #define TO_BITS(x)  ( sizeof (x) * CHAR_BIT )
> > #define TO_BYTES(x) ( (x) / CHAR_BIT )
> 
> I might be inclined to go a little further.
> 
> #define BYTES_TO_BITS(x)  ( sizeof (x) * CHAR_BIT )

It is misleading name, should be something like:

#define SIZE_IN_BITS_OF(x)  ( sizeof(x) * CHAR_BIT )


> #define BITS_TO_BYTES(x)  ( (x) / CHAR_BIT )

That is correct name.

[toc] | [prev] | [next] | [standalone]

#26140

Öö Tiib wrote:
> 
> On Friday, September 7, 2012 3:58:20 AM UTC+3, pete wrote:
> > John Bode wrote:
> > > If you need to do conversions from one unit to another,
> > > create a function or function-like macro with a name
> > > that *clearly* conveys the nature of the conversion:
> > >
> > > #define TO_BITS(x)  ( sizeof (x) * CHAR_BIT )
> > > #define TO_BYTES(x) ( (x) / CHAR_BIT )
> >
> > I might be inclined to go a little further.
> >
> > #define BYTES_TO_BITS(x)  ( sizeof (x) * CHAR_BIT )
> 
> It is misleading name, should be something like:
> 
> #define SIZE_IN_BITS_OF(x)  ( sizeof(x) * CHAR_BIT )

Either that or I should have read the definition first.
I was thinking of it as though it had been ( (x) * CHAR_BIT )

-- 
pete

[toc] | [prev] | [next] | [standalone]

#26026

"John Bode" <jfbode1029@gmail.com> wrote in message 
news:4f46c814-7397-40f9-8c60-c24578e2eec1@googlegroups.com...

> If you need to do conversions from one unit to another,
> create a function or function-like macro with a name
> that *clearly* conveys the nature of the conversion:
>
> #define TO_BITS(x)  ( sizeof (x) * CHAR_BIT )
> #define TO_BYTES(x) ( (x) / CHAR_BIT )
>
> int x = TO_BITS(10);

This sets x to 32 on my machine. I think it ought to be 80:

#define TO_BITS(x) ((x)*CHAR_BIT)

> Will it bite you in the ass from a technical
> standpoint?  Well, you've already pointed out
> the issue with something like
>
>   int x = 2 + 2 BYTES;

What's wrong with that? It's 2, plus whatever 2 BYTES is. Just like in 
maths.

-- 
Bartc  

[toc] | [prev] | [next] | [standalone]

#26041

On Thursday, September 6, 2012 8:22:42 PM UTC-5, Bart wrote:
> "John Bode" <jfbode1029@gmail.com> wrote in message 
> 
> news:4f46c814-7397-40f9-8c60-c24578e2eec1@googlegroups.com...
> 
> > If you need to do conversions from one unit to another,
> > create a function or function-like macro with a name
> > that *clearly* conveys the nature of the conversion:
> >
> > #define TO_BITS(x)  ( sizeof (x) * CHAR_BIT )
> > #define TO_BYTES(x) ( (x) / CHAR_BIT )
> >
> > int x = TO_BITS(10);
> 
> This sets x to 32 on my machine. I think it ought to be 80:
> 
> #define TO_BITS(x) ((x)*CHAR_BIT)
> 

This is what I get for posting while working on
something else.  Of course, you are correct.

> > Will it bite you in the ass from a technical 
> > standpoint?  Well, you've already pointed out
> > the issue with something like
> >
> >   int x = 2 + 2 BYTES;
> 
> What's wrong with that? It's 2, plus whatever 2 BYTES is. Just like in 
> maths.
> 

Because the multiplication operation is hidden 
behind the macro, it's not immediately clear
that there's a precedence issue here.  Again,
a casual scan of the code implies that you're
interested in (2 + 2) BYTES, not 2 + (2 BYTES).

[toc] | [prev] | [next] | [standalone]

#26089

JohnF <john@please.see.sig.for.email.com> 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)*8) 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"?

Better:

   #define BITS_PER_BYTE 8

   bits = bytes * BITS_PER_BYTE;

(with the obvious possible improvement involving CHAR_BIT).

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.c

csiph-web