#define BYTES *8

Discussion in 'C Programming' started by JohnF, Aug 28, 2012.

  1. JohnF

    JohnF Guest

    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"?
    --
    John Forkosh ( mailto: where j=john and f=forkosh )
    JohnF, Aug 28, 2012
    #1
    1. Advertising

  2. JohnF

    Mark Bluemel Guest

    On 28/08/2012 08:44, 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"?
    >


    I hate the name - it doesn't actually convey the intent to my mind.
    Mark Bluemel, Aug 28, 2012
    #2
    1. Advertising

  3. 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)*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"?


    I'd say it violates the principle of least surprise. Seeing an
    identifer used that way, effectively as a postfix unary operator, is
    confusing; it's very difficult to understand unless you examine the
    definition of the macro.

    Most macros can be understood, in terms of their meaning if not their
    implementation, by looking at their names and arguments.

    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.

    And as Mark Bluemel indicates, the name doesn't convey the meaning well.
    It says that you're working with bytes somehow, but it doesn't imply
    anything about a conversion to bits.

    If you want to compute the number of bits in a given number of bytes,
    and you're using the word "byte" as it's defined by the C standard, then
    you need to multiply by CHAR_BIT, defined in <limits.h>:

    bits = bytes * CHAR_BIT;

    That's clear enough that no additional macro is needed.

    --
    Keith Thompson (The_Other_Keith) <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"
    Keith Thompson, Aug 28, 2012
    #3
  4. JohnF

    JohnF Guest

    Keith Thompson <> wrote:
    > 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)*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"?

    >
    > I'd say it violates the principle of least surprise. [...]
    > [...] If you want to compute the number of bits in a given
    > number of bytes,
    > bits = bytes * CHAR_BIT;
    > That's clear enough that no additional macro is needed.


    My bad. The actual app involves physical units. I just used
    bits/bytes as an example for the post. Moreover, the actual
    program is user-modifiable at compile time by way of an
    #include "userformulas.h" in the middle of the code (not as
    a header) containing stuff like length=10 feet; width=3 inches;
    height=4 meters; etc; (And please don't tell me that
    should be input as data. The alternatives were considered
    and the decision's been made.) So you can see why I want
    to do this. And the aspect of the semantics you're talking
    about isn't really relevant. The only question I'm asking
    is about any straightforward semantic problems arising from
    the funky-looking syntactic construction.
    --
    John Forkosh ( mailto: where j=john and f=forkosh )
    JohnF, Aug 28, 2012
    #4
  5. JohnF

    BartC Guest

    "JohnF" <> wrote in message
    news:k1i2i2$6k6$...

    > My bad. The actual app involves physical units. I just used
    > bits/bytes as an example for the post. Moreover, the actual
    > program is user-modifiable at compile time by way of an
    > #include "userformulas.h" in the middle of the code (not as
    > a header) containing stuff like length=10 feet; width=3 inches;
    > height=4 meters; etc;


    I use the same thing elsewhere:

    x = 3m+50cm

    so x ends up as 3500 when the basic unit is mm (m scales by 1000, and cm by
    10).

    So it sounds reasonable enough and using #define as you have sounds like the
    closest you might get in C source code.

    However:

    o I only use such a suffix after a constant
    o It only applies to the immediately preceding constant

    So your 2+2 BYTES example elsewhere would need to be written as 2 BYTES + 2
    BYTES, which makes more sense anyway.

    > The only question I'm asking
    > is about any straightforward semantic problems arising from
    > the funky-looking syntactic construction.


    Without proper language support, your macro could be used in ways that were
    not intended (2 BYTES BYTES BYTES for example).

    --
    Bartc
    BartC, Aug 28, 2012
    #5
  6. JohnF

    JohnF Guest

    BartC <> wrote:
    > JohnF <> wrote
    >> stuff like length=10 feet; width=3 inches;
    >> height=4 meters; etc;

    >
    > I use the same thing elsewhere: x = 3m+50cm
    > so x ends up as 3500 when the basic unit is mm
    > (m scales by 1000, and cm by 10).
    > So it sounds reasonable enough and using #define as you have
    > sounds like the closest you might get in C source code.


    Thanks, Bart. I figured it would work because I tested it
    and it worked. But I still wanted to double-check becuase
    it looked strange, and I'd never used that kind of #define
    construction before, nor seen similar stuff used.
    In fact, full disclosure, it would never have occurred
    to me except I saw /mm {2.834646 mul} def in some
    postscript code (who knew there were 2.83 seventy-seconds
    of an inch in a mm?).

    > However:
    > o I only use such a suffix after a constant
    > o It only applies to the immediately preceding constant
    > So your 2+2 BYTES example elsewhere would need to be written
    > as 2 BYTES + 2 BYTES, which makes more sense anyway.
    >
    >> The only question I'm asking
    >> is about any straightforward semantic problems arising from
    >> the funky-looking syntactic construction.

    >
    > Without proper language support, your macro could be used
    > in ways that were not intended (2 BYTES BYTES BYTES for example).


    --
    John Forkosh ( mailto: where j=john and f=forkosh )
    JohnF, Aug 28, 2012
    #6
  7. JohnF

    James Kuyper Guest

    On 08/28/2012 03:44 AM, 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"?


    It's a bad idea because it works in a way very different from C
    identifiers that are not macros. The best uses of macros always mimic
    other kinds of identifiers syntactically. 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
    --
    James Kuyper
    James Kuyper, Aug 28, 2012
    #7
  8. JohnF

    tom st denis Guest

    On Aug 28, 3:44 am, 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


    As others pointed out the name is a bit confusing as "bytes" is not
    what it counts but bits.

    But more so it's probably better to have something like

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

    Which is both named correctly, uses the correct bit definition, and
    doesn't have unintended side effects.

    Tom
    tom st denis, Aug 28, 2012
    #8
  9. JohnF

    BartC Guest

    "Scott Fluhrer" <> wrote in message
    news:1346170970.561767@rcdn-nntpcache-2...
    >
    > "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.


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

    --
    bartc
    BartC, Aug 28, 2012
    #9
  10. JohnF

    ImpalerCore Guest

    On Aug 28, 10:31 am, tom st denis <> wrote:
    > On Aug 28, 3:44 am, 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

    >
    > As others pointed out the name is a bit confusing as "bytes" is not
    > what it counts but bits.
    >
    > But more so it's probably better to have something like
    >
    > #define OBJ_TO_BITS(x) (sizeof(x) * CHAR_BIT)
    >
    > Which is both named correctly, uses the correct bit definition, and
    > doesn't have unintended side effects.


    I prefer 'c_sizeof_bits' (the 'c_' is the prefix I use for my stuff),
    which helps remind me that the macro is an extension of the sizeof
    operator. I use 'c_sizeof_array' for similar reasons. I was tempted
    to use all caps, but I wanted to adopt the same case-style as 'sizeof'
    for these two macros.

    Best regards,
    John D.
    ImpalerCore, Aug 28, 2012
    #10
  11. "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) <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"
    Keith Thompson, Aug 28, 2012
    #11
  12. JohnF

    Eric Sosman Guest

    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
    Eric Sosman, Aug 29, 2012
    #12

  13. > 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.
    Adrian Ratnapala, Aug 30, 2012
    #13
  14. JohnF

    Joe Pfeiffer Guest

    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)*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.
    Joe Pfeiffer, Aug 30, 2012
    #14
  15. JohnF

    Eric Sosman Guest

    <OT> Re: #define BYTES *8

    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, Aug 31, 2012
    #15
  16. Re: <OT> Re: #define BYTES *8

    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, Aug 31, 2012
    #16
  17. JohnF

    JohnF Guest

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

    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 )
    JohnF, Aug 31, 2012
    #17
  18. JohnF

    BartC Guest

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

    "Ben Bacarisse" <> wrote in message
    news:...
    > 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, Aug 31, 2012
    #18
  19. Re: <OT> Re: #define BYTES *8

    "BartC" <> writes:

    > "Ben Bacarisse" <> wrote in message
    > news:...

    <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.
    Ben Bacarisse, Aug 31, 2012
    #19
  20. Re: <OT> Re: #define BYTES *8

    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.
    88888 Dihedral, Aug 31, 2012
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Jason Collins
    Replies:
    3
    Views:
    5,992
    Jason Collins
    Feb 18, 2004
  2. mrby

    4-bytes or 8-bytes alignment?

    mrby, Nov 2, 2004, in forum: C Programming
    Replies:
    8
    Views:
    402
    Mark McIntyre
    Nov 2, 2004
  3. Replies:
    5
    Views:
    515
    Flash Gordon
    Apr 9, 2006
  4. Yandos
    Replies:
    12
    Views:
    5,096
    Pete Becker
    Sep 15, 2005
  5. Replies:
    8
    Views:
    481
    Bob Hairgrove
    Apr 10, 2006
Loading...

Share This Page