Hi, Bob.

BL>  BL> I thought Windows used cache as VM.

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

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

Windows. :-)

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

No, cache stores stuff from disk in RAM which you have accessed recently
or might access soon (depending on the particular implementation). VM
uses disk to store stuff which won't fit in RAM.

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

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

BL>   I knew that. All of that.

Good. I didn't know I told you I'd written one. :-)

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

BL>  FM> :-)

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

I can't think of another explanation.

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

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

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

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

Yes, to me readability is *the* most important issue.

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

As Paul said to you "//" is C++ not Borland. And you could still use
"/*...*/" as a one-line comment, as you to with "{...}"
in Pascal. But
it's the nestability thing which is such a big advantage. I comment my
code a lot, with {}, and it's just so easy while debugging to surround
some bits you don't want to use in that test with (*...*).

But I think that's an accident in Pascal anyway. Early keyboards didn't
have []{} and another pair which I can't remember, so (. .) (* and *)
were defined as equivalent. Fortunately (for us nesters) Borland (at
least) didn't implement the lex scanner to return (* and *) exactly
equivalent to [ and ]. I wonder if you could declare...

var X: array (.1..10] of integer?

Yes, you can.

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

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

BL>   Does anyone?

:-)

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

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

I think I don't, but I'm not rabid about it.

Regards, fIM.

 * * To know the road ahead, ask those coming back.
@EOT:

---