> but the program is running perfectly..
Just because it runs without crashing and produces an output file is not a sign of perfection.
You're not addressing the issues raised in my previous post.
Given 1/122/3
You need to find a way of making sure it decodes as
1/122/3
and not as
1/122/3
This is what Cactus_Hugger was talking about.
It might be easier if you always wrote the length out as 3 digits, say
1/0122/003
If you know the length is always 3 digits, it makes it easier to deal with.
If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
If at first you don't succeed, try writing your phone number on the exam paper.
plz tell me something..
say for ex : 1\125
all thses are characters.we are to print 1 125 tyms.how can we conver characters 125 into integar..??
If you write the compressor properly then you don't have to!Originally Posted by garv84
Everyone always teaches RLE compression by giving examples with text, and shows the compressed version as if it were text. Such examples always contain lots of repeated bytes too.
However that's not the reality of how anybody who knows what they're doing implements it.
You are supposed to accept binary data, and write out binary data. Every byte value between 0 and 255 should be able to be compressed from the input file, and later restored after decompression of hte compressed file. This in turn basically means that your compressed file becomes a binary format as well.
My homepage
Advice: Take only as directed - If symptoms persist, please see your debugger
Linus Torvalds: "But it clearly is the only right way. The fact that everybody else does it some other way only means that they are wrong"
