Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!rutgers!seismo!mcvax!diku!olamb!kimcm
From: kimcm@olamb.UUCP
Newsgroups: comp.lang.c
Subject: Re: C questions
Message-ID: <194@olamb.UUCP>
Date: Mon, 19-Jan-87 08:19:27 EST
Article-I.D.: olamb.194
Posted: Mon Jan 19 08:19:27 1987
Date-Received: Sun, 1-Feb-87 16:03:41 EST
References: <2335@brl-adm.ARPA>
Organization: AmbraSoft A/S (Denmark)
Lines: 114


> "... 95% of all C programmers couldn't give you a good
> explanation of the term lvalue..."

I don't think so, we're a software house with several *PROFESSIONAL*
C programmers (both UNIX and *DOS C compilers) and nobody has any
problems understanding lvalue and other abbreviations (technical compiler
terms). But for an introduction to C it would be a good help to explain
the meaning of such phrases.

> "... Switch/case could be classified as rarely used and should be
> kept till later.

Switch/case - should be classified as a *VERY* potent language structure,
and the usage and syntax should be laid quite clear for new C users, to avoid
pitfalls especially the default fall-through mecanism, which is unique to C.

> "... very few C programmers know much about sizeof..."

I really doubd that this is true, experienced C programmers (pro's and 
non-pro's) will quickly find this routine instead of using a machine-dependent
value of some datatype. Just consider the example:

	struct p {
		int	p_num;
		char	name[20];
		char	phone[12];
	} person;

	while (read(fd,&person,sizeof(person)) == sizeof(person)) {
		...do something to person structure...
	}

and the usage without sizeof:

	struct p {
		int	p_num;
		char	name[20];
		char	phone[12];
	} person;

	while (read(fd,&person,34) == 34) {
		...do something to person structure...
	}

And notice that the latter depends on integers being 16bit values, if you
move to another computer where integers are 32bit values you'll have to edit
and recompile your source - if using the former example you'll only need to
recompile. But that's not it the code is easier understandable than the latter.

> 
> "... 99%  of  all  professional C  programmers  have no idea
> what typedef is all about, couldn't care less and probably
> won't ever need it."

How much longer are we going to live with the myth saying that, professional
programmers, are people with no in-depth knowledge of the tool they're
using!!! You might as well say that *REAL* programmers work at the university
and don't care about getting their hands dirty by programming for money
(ie. become a profesional programmer) - BULL****!
> 
> "... 99%  of  all  professional C  programmers  have no idea
> what the comma operator is all about, couldn't care less and
> probably won't ever need it."
> 
> "... Leave the comma operator altogether. An intro book is no
> place for obscure and unmaintainable tricks..."

Might be a good idea to save the comma operator to late in the book, but
it certainly should be mentioned, since most C programmers (-; at some
point in their career will have to read other peoples C code and try
to understand it. If the comma operator are left out - the person seeing
in some code will be really puzzled by what's going on. (I've tried it myself,
but I had a wizard to train me!)

> 
> "... Pointers to functions ... few C programmers understand
> them or would ever need them..."

Ever tried to write programs that receives interrupts from user or external
devices, if so you'll probably used signal(2) which returns a pointer to a
function and takes a function as argument for action upon receival of the
interrupt.

Or to take another example try to sort a large array of structures, (actually
pointers to structures) by a field in the structure. You can either write the
sort-routine yourself or use qsort(3C) but this needs a pointer to a function
to do the comparison between two elements of the array.

OK, then you'll need only a brief understanding of what pointers to functions
are - not the semantics of them -- BUT if you were to write the qsort routine
you'd better know what pointers to functions are!
> 
> "... a C programmer never needs to know what a byte is..."

A C programmer never needs to know what ASCII is!
A C programmer never needs to know what a computer is!
A C programmer never needs to know who he is!
A C programmer never needs to know!
A C programmer never needs!
A C programmer never know!
....when will all the biased viewpoints on what a *REAL* C programmer
need to know and what he doesn't need to know stop ?

Conclusion:

	I think all of the elements of the C language should be covered
	in a teaching book. Maybe not to make the new C programmer
	familliar with them all at once, but to make him/her able to
	understand other people's C code. And later on to use the book as
	a reference work.


					Kim Chr. Madsen