Endianness and streams

Discussion in 'C++' started by kelvSYC, Jun 5, 2005.

  1. kelvSYC

    kelvSYC Guest

    This seems to be easy, and perhaps I'm overthinking it a bit.
    Anyways...

    I want to use streams to write an int in binary form as a little-endian
    byte sequence. Firstly, is the easiest way simply to put the int in a
    temporary buffer, then write() the buffer? Secondly, does this count
    as formatting (and thus using a custom fstream for binary output with a
    customized << operator is justified)?

    --
    I am only a mirage.
     
    kelvSYC, Jun 5, 2005
    #1
    1. Advertising

  2. On Sun, 05 Jun 2005 18:59:58 GMT, kelvSYC <>
    wrote:

    >This seems to be easy, and perhaps I'm overthinking it a bit.
    >Anyways...
    >
    >I want to use streams to write an int in binary form as a little-endian
    >byte sequence. Firstly, is the easiest way simply to put the int in a
    >temporary buffer, then write() the buffer? Secondly, does this count
    >as formatting (and thus using a custom fstream for binary output with a
    >customized << operator is justified)?


    It depends on sizeof(int) on your machine. At any rate, you will get
    the same results regardless of platform running the code by writing
    (n%256) first, (n/256)%256 second, etc. until you hit 0. Also, replace
    256 with 2**CHAR_BIT (using Fortran notation here) for your platform.
    If you want big-endian, you need to write the bytes the other way
    around.

    For writing using ofstream, open the stream using the
    std::ios_base::binary mode argument, fill your buffer and call
    ofsteam::write() as many times as needed.

    --
    Bob Hairgrove
     
    Bob Hairgrove, Jun 5, 2005
    #2
    1. Advertising

  3. On Sun, 05 Jun 2005 22:25:06 +0200, Bob Hairgrove
    <> wrote:

    >It depends on sizeof(int) on your machine. At any rate, you will get
    >the same results regardless of platform running the code by writing
    >(n%256) first, (n/256)%256 second, etc. until you hit 0.


    Actually, you have to write sizeof(int) bytes even if value==0 for the
    higher bytes, of course. And it's probably a good idea to cast the
    input to unsigned int before doing mod which is meaningful only for
    positive numbers.

    --
    Bob Hairgrove
     
    Bob Hairgrove, Jun 5, 2005
    #3
  4. kelvSYC

    Pete Becker Guest

    Bob Hairgrove wrote:
    >
    > Actually, you have to write sizeof(int) bytes even if value==0 for the
    > higher bytes, of course. And it's probably a good idea to cast the
    > input to unsigned int before doing mod which is meaningful only for
    > positive numbers.
    >


    The % operator is meaningful for negative numbers. It's not the same as
    mod, but there's no mod operator in C or in C++. When you have a
    negative number for the numerator and a positive number for the
    denominator you have the possibility that the result of % will be
    negative. If that happens and you want a positive value you have to add
    the denominator to the result.

    Of course, for the original problem, you're right that you should treat
    the bit pattern as an unsigned value. Not because % isn't meaningful,
    but because using it in this case is harder when you have to deal with
    negative values.

    --

    Pete Becker
    Dinkumware, Ltd. (http://www.dinkumware.com)
     
    Pete Becker, Jun 5, 2005
    #4
  5. On Sun, 05 Jun 2005 18:59:58 GMT, kelvSYC <>
    wrote:

    >This seems to be easy, and perhaps I'm overthinking it a bit.
    >Anyways...
    >
    >I want to use streams to write an int in binary form as a little-endian
    >byte sequence. Firstly, is the easiest way simply to put the int in a
    >temporary buffer, then write() the buffer? Secondly, does this count
    >as formatting (and thus using a custom fstream for binary output with a
    >customized << operator is justified)?


    BTW, what if your::sizeof(int) != other::sizeof(int) (other:: being
    the receiving end, of course)?

    We are living in a time of transition from 32-bit to 64-bit ...
    something to think about!

    --
    Bob Hairgrove
     
    Bob Hairgrove, Jun 6, 2005
    #5
  6. On Sun, 05 Jun 2005 16:49:40 -0400, Pete Becker <>
    wrote:

    >Bob Hairgrove wrote:
    >>
    >> Actually, you have to write sizeof(int) bytes even if value==0 for the
    >> higher bytes, of course. And it's probably a good idea to cast the
    >> input to unsigned int before doing mod which is meaningful only for
    >> positive numbers.
    >>

    >
    >The % operator is meaningful for negative numbers. It's not the same as
    >mod, but there's no mod operator in C or in C++. When you have a
    >negative number for the numerator and a positive number for the
    >denominator you have the possibility that the result of % will be
    >negative. If that happens and you want a positive value you have to add
    >the denominator to the result.
    >
    >Of course, for the original problem, you're right that you should treat
    >the bit pattern as an unsigned value. Not because % isn't meaningful,
    >but because using it in this case is harder when you have to deal with
    >negative values.


    Thanks, Pete ... I wasn't aware that the % operator was not the same
    as mod(ulo), although I find it obvious that it was meant to be that
    way (perhaps mistakenly so). I always took the precaution of casting
    the input to unsigned anyway, "just in case", so I never ran into
    possible differences.

    Since you say that operator % is indeed "meaningful" for negative
    numbers, can you point me to someplace in the standard where the
    meaning of this meaningfulness is defined? (this very much reminds me
    of Clinton's "definition of *is*" <g>)

    Cheers...

    --
    Bob Hairgrove
     
    Bob Hairgrove, Jun 6, 2005
    #6
  7. kelvSYC

    Pete Becker Guest

    Bob Hairgrove wrote:
    >
    > Since you say that operator % is indeed "meaningful" for negative
    > numbers, can you point me to someplace in the standard where the
    > meaning of this meaningfulness is defined?


    <g> 5.6/4.

    The definition of % is that (a/b)*b + a%b == a. When both a and b are
    non-negative the remainder is required to be non-negative. Otherwise,
    the sign is implementation-defined.

    The reason it's defined that way is to allow division and remainder to
    be done in whatever way the underlying hardware does them. When both a
    and b are positive there's no confusion. When a is negative and b is
    positive the result of a/b can be rounded up or down, and a%b has to
    match. For example, -5/3 can be -1 or -2, and 5%-3 is then -2 or +1,
    respectively.

    --

    Pete Becker
    Dinkumware, Ltd. (http://www.dinkumware.com)
     
    Pete Becker, Jun 6, 2005
    #7
  8. On Sun, 05 Jun 2005 19:59:10 -0400, Pete Becker <>
    wrote:

    >When a is negative and b is
    >positive the result of a/b can be rounded up or down, and a%b has to
    >match. For example, -5/3 can be -1 or -2, and 5%-3 is then -2 or +1,
    >respectively.


    Absolutely mind-boggling ... I had no idea ... I wonder how much code
    out there depends on this (implementation-defined) behavior??

    Thanks, Pete.

    --
    Bob Hairgrove
     
    Bob Hairgrove, Jun 6, 2005
    #8
  9. kelvSYC

    Pete Becker Guest

    Bob Hairgrove wrote:
    >
    > Absolutely mind-boggling ... I had no idea ... I wonder how much code
    > out there depends on this (implementation-defined) behavior??
    >


    None, I hope. <g>

    --

    Pete Becker
    Dinkumware, Ltd. (http://www.dinkumware.com)
     
    Pete Becker, Jun 6, 2005
    #9
    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. pramod
    Replies:
    22
    Views:
    1,972
    Lew Pitcher
    Jan 6, 2004
  2. pramod

    endianness and sscanf/sprintf

    pramod, Dec 31, 2003, in forum: C Programming
    Replies:
    22
    Views:
    810
    Lew Pitcher
    Jan 6, 2004
  3. Case

    memcpy() and endianness

    Case, May 10, 2004, in forum: C Programming
    Replies:
    26
    Views:
    1,948
    Dan Pop
    May 12, 2004
  4. gamehack

    Bit shifts and endianness

    gamehack, Jan 5, 2006, in forum: C Programming
    Replies:
    72
    Views:
    6,998
    Dave Thompson
    Jan 11, 2006
  5. endianness and 64-bit machines

    , May 17, 2006, in forum: C Programming
    Replies:
    7
    Views:
    497
    Richard Heathfield
    May 20, 2006
Loading...

Share This Page