Re: huffman encoder




<aarklon@xxxxxxxxx> wrote in message
news:1135306561.078291.197850@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> Hi all,
>
> this is the program which I saw in my colleagues book. the program was
> run on turbo C++ 3.0 compiler
>
<snip>
this was imo very inefficient code...

>
> now my questions are
>
> 1) how can the function freetree be implemented properly.
>
as written, it should work, but I have (personally) had some bad experiences
with malloc/free's behavior in the past.

imo, a better alternative is that of not using malloc/free on each node,
instead allocating an array of nodes (for 256 leaves, only 255 extra nodes
are needed, this pattern holds with larger numbers, eg, n-1 extra are
needed). on can, however, use a full 256 to make things more even.

when building a new tree, one starts at the start of the array and uses up
the nodes in the array.

(some implementations may not even build a tree of nodes, as I imagine is
possibly the case with deflate).

> 2) can anybody explain refreshbuffer funcion
> i mean refresh buffer function writes the encoded bit pattern
> using
> fputc function.
>
> the function of fputc function is as follows
>
> int fputc(int ch, FILE *stream);
>
> Writes a character (an unsigned char) specified by the argument ch
> to the specified stream and advances the position indicator for the
> stream.On success the character is returned. If an error occurs,
> the error indicator for the stream is set and EOF is returned.
>
> now my question is how compression is achieved,if we are writing ints
>
errm...

the total number of fputc's is a smaller that the total number of fgetc's...
not like you can read or write bits to the file directly...

the whole damn int does not go to the file, only the byte value of the int.
ints free one from having to worry about signed/unsigned issues in these
cases, and also allow things like fgetc to return -1 on error.

> 3) what exactly is the purpose served by these two statements in this
> program???
>
> fputc(getoddchar(),fq);
> fputc(bc,fq);
>
flushing the (incomplete last bits), eg, so the last char is not truncated.

next one, maybe a sanity check, or a means of indicating eof, but I am
unsure (it is unclear how the decoder will know exactly when the eof is).

guess:
it reads in the input size, gets the last char;
it decodes characters so long as there are more input bits related.

or:
it reads values into the decode buffer, also reading in the next byte;
on eof it knows it has reached the end of the stream, maybe only decoding
chars so long as bits are left.

or something like that...


.



Relevant Pages

  • Re: scanf behaviour
    ... char, i have to reread the input until I get the needed pos. ... user input a number that's too large to be stored in an integer. ... static int ignoreblks ... which may be \n or EOF ...
    (comp.lang.c)
  • Re: memory leak?
    ... char, short, int are all 16 bits. ... them rely on EOF being returned by the function. ... value distinct from all unsigned char values. ...
    (microsoft.public.vc.mfc)
  • Re: Is there any GENRIC MACROS in c for INTEGERS,CHARACTERS ?
    ... >> The descriptions of the ctype functions all take int values. ... >> that char is converted to int in this case and that if char is signed ... What is EOF for in this context? ... the 'space' characters and so 0 must be the result. ...
    (comp.lang.c)
  • Re: huffman encoder
    ... > to the specified stream and advances the position indicator for the ... > the error indicator for the stream is set and EOF is returned. ... the whole damn int does not go to the file, only the byte value of the int. ... flushing the, eg, so the last char is not truncated. ...
    (comp.compression)
  • Re: Discarding unread data after scanf()
    ... You need to test for EOF. ... stream, so there's no risk of discarding any more than needed. ... getchar() returns EOF on failure or end of file. ... int skip2nl ...
    (comp.lang.c)

Quantcast