🚀 go-pugleaf

tmkk@uiuc.edu (Khan) writes:


>In article <cg.0afn@ami-cg.UUCP> cg@ami-cg.UUCP (Chris Gray) writes:
>>In article <1992Jul22.000454.24871@ccu1.aukuni.ac.nz> stuartw@ccu1.aukuni.ac.nz
>>writes:
>>>	base_ptr[offset]=value;
>>>
>>>	or
>>>
>>>	*base_ptr+offset=value;
>>
>>He he! I just love it when someone saying how great C is messes up with a
>>common C error! The above two are of course not equivalent - extra parentheses
>>are needed around the 'base_ptr+offset' in the second form.
>>
>>I've been skipping through these articles on 'TP or C', not realizing I've
>>been missing the glorious fun of putting C down!

try it.. it works on MY C compiler !!
( how would you interpret (*base_ptr)+offset=value anyway?? )
ie:(*base_ptr)+offset is NOT a lvalue, as base_ptr=unsigned char * )

>May I point out that you're not putting down C, you're putting down a
>PERSON who *uses* C.

or he would be, except it works.... B-)
	( ps: it's not ANSI, but I use K&R ! less unrequired checking B-)

>>C is one of the unfriendliest languages I've come in contact with, especially
>>in the ways it is used by far too many people.

>You know, I always suspected that most of the C bashers in the world
>hate the language because they aren't posessed of the intellectual
>capacity to understand how to use it. People who think a for loop in C
>is confusing, for example. Based on your experience in writing an ANSI C
>compiler, I see that you are an exception to this rule. ;-)

>Personally, I'd rather be "confused" by a C for loop than be genuinely
>confused at all the bizarre dialects that call themselves Pascal. I can
>port a Borland C program to Unix C or VAX C or even Atari 8-bit C with
>little trouble. The same can *not* be said of a Turbo Pascal program!

>Face it, ugly spaghetti code can be written in ANY language. Don't try
>to blame the language for a lack of skill on the part of the programmer.

INTERCAL !!!!!!!!! B-)

>>Folks! Use full prototypes. Turn on all possible warning flags. Make your
>>code compile clean. Use some fairly standard programming style. Make your
>>file global variables instantly distinguishable from your local ones. Avoid
>>inter-file globals (externs) like the plague. Don't overuse macros. Make
>>ALL macro names in all upper case (except perhaps true/false).
>>
>>Anyone (including yourself after a few years) who has to work with your code
>>will greatly thank you.

what I want added to C:
add scope control with '.' ie:
int a;
blort()
	{
	int a;
	a=1;	/* set LOCAL A=1 */
	.a=1;	/* set GLOBAL A=1 */
	}

B-)
(ever tried thinking of new and interesting names for x and y when
	programming graphics B-< )

>Agreed 100% - and don't forget *thorough* internal documentation! At the
>very least, the header comments for a function should identify all
>parameters and explain their use. Local variables should also have a
>brief comment next to their declarations. Finally, each block of code
>within the function should have its own small comment block.

------------------------------------------------------------------------------
stuartw@ccu1.aukuni.ac.nz


		     >>>>In TECO Where No VI Available<<<<
------------------------------------------------------------------------------