BL> I thought Windows used cache as VM.

 FM> Windows uses *disk* as VM - the swap file. By rolling stuff out
 FM> to disk it looks as if you have more RAM than you have (with a
 FM> time penalty when you need to access it of course). Cache is
 FM> (in some sense) the opposite - using RAM to store bits of disk
 FM> that you might need to access again or soon.

  It uses RAM first, then hard disc which you can set to zero if you
like. I did it that way, and found to my surprise that I was getting
more GPFs. I have 16Mb of clear RAM (plus 8M that gets eaten by cache
and RAMDRVe, etc). I gave it 19Mb of hard drive as VM and the GPFs
went away again. Weird.

  But as I said, I thought it used cache when it ran out of RAM and
VM, before finally crashing or whatever it does.

 BL> It's on my list... so far I've only got the basic idea.

 FM> There are many 'basic ideas' in compression, but Huffman coding
 FM> will form a part of most schemes. And the 'basic idea' of
 FM> Huffman is very simple - just use fewer bits to represent the
 FM> more common occurrences of whatever - letters, words, phrases,
 FM> numeric values, whole records anything. Of course the
 FM> implementation isn't necessarily that simple - I know, I wrote
 FM> one once. Or twice.

  I knew that. All of that.

 BL> C for more than a month now and I can do it without thinking,
 BL> but I *still* can't make any sense of other people's code!
 BL> Dickheads! I wonder if they ever *had* the plot before they
 BL> lost it...

 FM> :-)

  It's incredible! I write *my* code longhand like Pascal, and apart
from the really awkward way to add comments (you have to do it one
line at a time on top, basically), it looks just like Pascal (apart
from the curly brackets I keep carefully aligned). Why does everyone
else write C code like dickheads? So no one else can read it? Writing
it small doesn't make it run fast... so they must all be dickheads.

 FM> Actually I do agree with Paul's portability point, it's just
 FM> not an issue for me. The ability to read, write and maintain
 FM> the code easily is much more important.

  Incredible! Paul follows a standard which surrounds every sinple
if() {}; with the curly brackets over four lines, even when it is
asingle statement best placed on one line to be read at once. This
means that a string of simple if(){}; becomes almost incomprehensible
inside a larger loop or whatever!

 FM> Speed is seldom an issue, and when it is it's usually better
 FM> addressed by algorithm selection/design.

  What I was saying is that writing the code in longhand or shorthand
makes no difference to what appears in machine code, so why write it
in shorthand? If it made faster or cleaner machine code I could go
along with it. The only point of a language is to communicate, so why
do they purposely use a language that doesn't? Wankers. It's the only
possible answer. They don't want to communicate, they'd rather diddle
themselves.

  And to prove it... adding comments in C is awkward. Borland solved
it with the one-line comment "//" but this isn't ANSI which insists on
the /*...*/ which won't nest. It's the final proof. C programmers are
all wankers. All of them.

 BL> I *finally* understand what was causing my problems with
 BL> pointers in C. It's the dickhead way they use "*"! In Pascal ^p
 BL> and p^ makes perfect sense.

 FM> I don't know what "*" means in C

  Does anyone?

 FM> , but I've never had any problem comprehending ^p & p^ either.
 FM> Of course the way Delphi does objects messes up the paradigm a
 FM> bit.

  Yes, but they're on the right track if you can put the Pascal
objects aside. I think it's a logical progression.

Regards,
Bob
 





___ Blue Wave/QWK v2.12
@EOT:

---