Hi Frank
When you suggest to use small fragments, I think you are on the right
way... but for me, this is independant of the language...
I try to never write a program/sub program/subroutine/paragraph/function
longer than 20 lines... (my guideline is "do not use roll up/PageDown
key")
and I do not spare computer time : I invoke the compiler at every new
routine... It ensures that any syntax problem is is my last 20 lines of
code....
of course when you write very low level code (drivers, encryption, etc...
) performance must be considered ,but optimization is a next step.
Kind Regards, thank you,
Paul
From: frank kolmann <fkolmann@xxxxxxxxx>
To: c400-l@xxxxxxxxxxxx
Date: 20/01/2014 10:43
Subject: [C400-L] C syntax errors
Sent by: c400-l-bounces@xxxxxxxxxxxx
Hi Mark
I much appreciate your reply.
I do understand it because in fact i have learnt what you so well detail.
Largely I understand what is written on this site
http://condor.cc.ku.edu/~grobe/intro-to-C.shtml. Instantaneous guide to
C.
But when it comes to practically coding there is a big learning jump and
C compilers are useless as a tool for learning.
I even saw studies that show that putting extra checks in compiler code
does not help beginner programmers.
http://crpit.com/confpapers/CRPITV20Kummerfeld.pdf
The study implies C Syntax error messages being a field to be researched,
I beg to differ with the study I think it is a case of once upon a time C
compilers had good syntax error messages but then along came YACC .
If the precise code errors are identified , like gud ole RPG then one
has a fighting chance to fix the error.
I have read of the influence of YACC
http://research.swtch.com/yyerror
,and the initial hopes of using YACC to have compiler messages with
more accuracy greatly dashed and the compiler errors become
even more obtuse. This site has research on how YACC can be improved.
The goal of reducing keystrokes comes at a high price, one needs to
effectively learn a whole new meaning to the special characters C uses
together with the Precedence rules that apply.
I am not sure that C achieves the low level flexibility of assembler,
mainly what was achieved is to allow the introduction of the most
difficult to detect coding errors.
The necessity of coding at a character level causes C programmers
to constantly to resort to tricks, I am compiling for myself a list of
these tricks.
for example this code moves one alpha field to another, go figure,
{while ( *s++ = *t++) ; } ( actually I understand this code , I am
learning, yea!!)
In K&R is some code that tries to do what you describe
(Exercise 5.20) 'How to read C declarations'
I was trying to write this code (and failing) when I decided to get a
working
example, I figure it will be help to read C code and also check what I had
written.
What baffles me is how can C be held in such esteem and why would
anyone would consider using C as a Business Language,
but thats the PC world for you.
I was asking how you guys handle C syntax errors, strategies and tactics,
editors, coding tricks, and so on.
For example one suggestion I had was code small fragments (functions)
that compile then piece it all together.
Another suggestion , do your code in PYTHON then convert the
PYTHON code to C, but then I need to know PYTHON.
Thanks
Frank Kolmann
date: Sat, 18 Jan 2014 15:08:46 -0500
from: Mark S Waterbury <mark.s.waterbury@xxxxxxxxxxxxx>
subject: Re: [C400-L] C syntax errors
Hi, again, Frank:
Setting aside the apparent "bad examples" on that web site ...
Responding to your original questions about how to read and understand C
syntax, the following might help you to comprehend it better.
When Dennis Ritchie first designed C, it was not meant to be a "general
purpose" programming language for all sorts of applications; it was
meant as a "systems programming language' for use in developing the Unix
operating system. As such, it was intended to be much closer to a
traditional "assembler language" than most other higher-level
languages. Like most assemblers, this included the idea of a "macro
processor" to make certain coding tasks easier.
Since it was not meant for a general audience, but was intended
originally for their own use internally within Bell Labs, they did not
have the goals of making it easy to read or understand for ordinary
mortals. They wanted to create a concise notation that would be easy for
the C compiler to parse and "understand". Much of the terseness of C,
such as the use of special characters like "{" and "}" instead of more
traditional "begin" and "end" keywords was due to the equipment used at
that time -- in the late '60s and early '70, they were using actual
teletypes and similar low-speed terminals to interact with these
minicomputers. So, the goal was to reduce the number of keystrokes
needed to represent a given statement.
All of the early C compilers written by Dennis Ritchie were developed
using "top-down, recursive descent" parsing techniques. This in part
influenced the language design (syntax) and those early compilers gave
reasonable "readable" syntax errors. With Unix Version 7, for greater
"portability," AT&T switched over to the new "Portable C Compiler" (PCC)
developed using YACC and LEX (compiler writing tools). YACC is a
"bottom-up" LALR parser generator. LALR table-driven parsers and the
grammars they accept are notorious for generating syntax errors that
often "make no sense" to humans looking at the compiler generated source
listing.
How to read C declarations
=====================
With the C language, "declarations" are probably the most difficult part
of the language to comprehend (for most people). A long time ago, I
learned this heuristic ("trick") to aid in understanding C
declarations: Read them "from the middle out." What do I mean by this?
Consider the following snippet of C code:
int a[10];
First, we find the "middle" -- the name of what is being declared, in
this case, "a" -- then we look to the right and see that it is an array,
as denoted by the presence of square brackets, and we see it is defined
with 10 elements. Then, from the "a", we look to the left to see that
this is an array of integers.
Now, consider the following:
char *c;
First, we find that "c" is what is being declared; next, we look to the
right -- nothing there -- so looking to the left, we see that "c" is a
pointer to character(s). (Note that in C, a character string is
represented by a pointer to the first character, and the "string" is
terminated by a "null" character, x'00').
Next, consider:
char name[10] = "Waterbury";
This declares name to be a 10 character array initialized to the string
"Waterbury" (C automatically adds the null x'00' character to the end).
Note that in early K&R C, this could also be declared as:
char *name = "Waterbury";
There is intentional ambiguity between arrays and pointers. The name of
the array denotes the address of the first position of the array. These
ambiguities were chosen intentionally, to provide the same kind of
low-level flexibility available to assembler language programmers of
that day, and to try to allow programmers to squeeze as much performance
out of the computers of that day as possible. So, the following
statement could be used to print the value of name:
printf(name);
with either definition of name.
Now, consider:
char *name[10];
Here, we find "name" to be an array of 10 elements each of which
contains a pointer to characters.
One more example:
char *month[] = { "January", "February", "March", "April",
"May", "June",
"July", "August", "September", "October", "November",
"December"};
Here, we have an array named "month" of pointers to characters, and the
array elements are initialized (as seen to the right of the "="). So,
this defines an array of 12 elements, each initialized to the name of
each month, e.g. month[3] = "March".
I hope this helps a little ...
All the best,
Mark S. Waterbury
midrange.com
