DB> while( (ch = fgetc(FIN)) != EOF )
DB> fprintf( FOUT, "character %d: %x\n", count++, ch );

DB> rather than this:

DB> ch = fgetc(FIN);
DB> while( ch != EOF )
DB> {
DB> fprintf( FOUT, "character %d: %x\n", count, ch );
DB> count = count + 1;
DB> ch = fgetc(FIN);
DB> }

DB> then that's my choice - but at least I can make that choice,
DB> rather than being forced into writing that loop in only one style.

BL> I know the appeal of writing C in shorthand, but it makes it
BL> hard to *READ*. There are two purposes in writing code: firstly
BL> the obvious one, and secondly so you (or someone else) can come
BL> back later and change it.

Still mangling the story. Yes, that consideration is vital. *BUT* the
point with C is that you can write succinctly and STILL have the code
very readable to someone who can read C fluently. *AND* C allows you to
go much further and write some of the most impenetrable code ever seen.

The point with C and maintainability is to be writing it succinctly
AND readably. With many of the other modern more long winded languages
you are FORCED to write it in a more long winded way and you CAN write
it so succinctly and readably as you can with C. *THATS* the difference.

BL> The formal languages like VB and Pascal are a drag at
BL> first, but they swap that initial nuisance for readability.

Nope, you have only half understood the problem. They are mostly
rather more rigid to protect you from yourself, catch more at the
compile time. They arent intrinsically more readable than C is.
AND you can always write in the same style in C as you do with
the others if you want to. With the others you have no choice.

BL> After a while, my clever fingers can write all the printf("%s %d",
BL> etc); without even thinking about it, and the same applies to the VB
BL> "IF what THEN crlf" At first it is a nuisance to always add the THEN
BL> and the new line, or to end every DO loop with an UNTIL or whatever,
BL> but you get used to it and it does make it easier to find the ends...
BL> much easier than C's }}}}}} at the end of a complex loop, or an
BL> if(((((            )))); statement with one missing because you can't
BL> work out where it goes!

Thats wrong too, tho you certainly do need to be more careful
with the layout of C code to get the same readability. But again,
that becomes automatic once you are fluent with it if you want
to do it like that and many editors assist with the more routine
stuff. Or you pass the code thru a prettyfier if you want to.

Its not actually a fundamental of the language and you can in
fact argue that the use by C of symbols like { } dont clutter
up the code with words for the block structure stuff.

BL> I much prefer to WRITE C because I can make the page
BL> aesthetically pleasing, but it's a mongrel to read.

Nope, you have to write it so its readable. Yes, C allows you
to not do that much more than many other modern languages, but
thats just the C philosophy, you have much more freedom to do
what you want, and that includes doing it the readable way too.

In fact the succinctness of C allows MORE readability often.

The main qualification is that C has a MUCH richer symbol set
than most modern high level languages, so it take more time
before you are fluent with them. The ++ and >> style stuff.

BL> As for hiding my ignorance of C - are you kidding? ROFL!!
BL> I revel in it. The less I know, the more I learn.

You still really havent managed to grasp much of its advantage tho.

DB> You said that you were trying to figure out how C
DB> is meant to be used; Bob, if you ignore this *very*
DB> fundamental element, then you'll *never* "get" C

He's right. You are a classic example of a person
who lets his nutty ideas cloud his vision.

BL> Bullshit, Dave. You gave me one very useful tip right at the
BL> beginning: that every function returns something. Why didn't
BL> you tell me that I *always* had to make sure that memory exists
BL> for the stuff I'm working with? That's all there is to it. All
BL> this crap about the language not getting in the way is to hide
BL> the fact that the language simply doesn't do memory - it only
BL> does pointers and it isn't real fussy where they point.

And this is more of the same silly stuff.

BL> Do you realise that K&R's first mention of memory allocation is
BL> on page 140 (out of 239). I think I'd have put it on the first page.

Pity your loopy story on memory allocation is a loopy story.
Its only true of some work, particularly that stuff you are
doing. You havent even noticed that yet.

BL> I amy be wrong (time will tell) but I think I've found
BL> the key to C already. This is the fundamental element,

Nope, its actually crap.

BL> not meaningless gubbage about the language "getting in the way."

Obviously more silly coat trailing, but it is actually one of the
most fundamental differences between C and most modern languages.

BL> I'm still testing C as a tool, Dave. Whether
BL> I use it or not will depend on what I find.

And if you cant even grasp the basic stuff,
it really doesnt matter too much what you 'find'

Just like it doesnt with the stuff about wealth distribution.

--- PQWK202