Binary File I/O and ^M

Discussion in 'C++' started by andy, Nov 19, 2005.

  1. andy

    andy Guest

    Hi,

    What are the annoying ^M put at newlines when a text file is used in
    binary mode?

    I've written a file compression / decompression program using huffman
    encodings. The algorithms work- On an input text file, It reads &
    encodes and the file produced can be decoded back into the original.
    Then I modified it to read any generic file to compress by reading in
    binary mode. It compresses and decompresses well, except that ^M comes
    after each line in the decompressed version.

    Any suggestions?

    Thanks,

    andy
     
    andy, Nov 19, 2005
    #1
    1. Advertising

  2. andy

    red floyd Guest

    andy wrote:
    > Hi,
    >
    > What are the annoying ^M put at newlines when a text file is used in
    > binary mode?
    >
    > I've written a file compression / decompression program using huffman
    > encodings. The algorithms work- On an input text file, It reads &
    > encodes and the file produced can be decoded back into the original.
    > Then I modified it to read any generic file to compress by reading in
    > binary mode. It compresses and decompresses well, except that ^M comes
    > after each line in the decompressed version.
    >


    I assume you're working on a Windows platform.

    Windows uses a CR-LF combo as its line terminator. In text mode,
    they're collapsed to a single newline (\n). But for compression, you
    *must* read in binary mode, which means that CR-LF translation doesn't
    occur.
     
    red floyd, Nov 19, 2005
    #2
    1. Advertising

  3. andy

    andy Guest

    Hi- thanks. I actually just found that out running the same code on a
    linux box. On this compression note- I'm still running into a problem I
    believe involving my buffering. To read a binary file byte-by-byte, I'm
    putting it in an unsigned char* buffer. I noticed that when the chars
    were signed, negative int values were sometimes assigned. I'm trying to
    resolve bytes to their ascii equivalent and that was causing problems.
    Will the unsigned char* fix this? I think I may be loosing some data
    somewhere. Thanks...
     
    andy, Nov 19, 2005
    #3
  4. andy

    Jim Langston Guest

    "andy" <> wrote in message
    news:...
    > Hi- thanks. I actually just found that out running the same code on a
    > linux box. On this compression note- I'm still running into a problem I
    > believe involving my buffering. To read a binary file byte-by-byte, I'm
    > putting it in an unsigned char* buffer. I noticed that when the chars
    > were signed, negative int values were sometimes assigned. I'm trying to
    > resolve bytes to their ascii equivalent and that was causing problems.
    > Will the unsigned char* fix this? I think I may be loosing some data
    > somewhere. Thanks...


    An unsigned char is 0 to 255.
    a signed char is -128 to 127
    So any char greater than 127 would show up as negative as a signed char.

    Yes, changing it to unsigned char will at least show you the values 0 to 255
    instead of negative values. Although the actual bit values won't change.
     
    Jim Langston, Nov 20, 2005
    #4
    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. Fangs
    Replies:
    3
    Views:
    9,817
    darshana
    Oct 26, 2008
  2. Marc Schellens
    Replies:
    8
    Views:
    3,026
    John Harrison
    Jul 15, 2003
  3. Ron Eggler

    writing binary file (ios::binary)

    Ron Eggler, Apr 25, 2008, in forum: C++
    Replies:
    9
    Views:
    941
    James Kanze
    Apr 28, 2008
  4. scad
    Replies:
    4
    Views:
    960
    James Kanze
    May 28, 2009
  5. Jim
    Replies:
    6
    Views:
    738
Loading...

Share This Page