Frank,
I learnt programming C more than 20 years ago - and I used solely K&R book.
Just start from the beginning and do all excercises without exceptions - this is how I did it.
Of course there is one little thing to mention - you also occasionally need someone who is ready to act as a tutor.
This is for 2 major issues:
1. You must get familiar with the particular programming environment/compiler. This is not covered in the Book so you will need external help.
2. You will need that "someone" to prevent you from spending hours on stupid problems, like, for example one { missing in the source example.
Then I have one comment to an earlier letter stating that a code
while(ns --> 0)
will never compile.
That is not true, of course, as this is quite normal C-style code. Can be transalated to human language like this:
while ((ns - 1) > 0)
or
while (ns > 1)
Now in general.
As far as I understand, there is such a thing like "C-style".
Some people are proud that they are writing C using "C-style".
This "while (ns-->0) is very C-style. Your example with double * is also C-style.
C-style assumes using lots of *, &, -> and mixing them in all possible combination making it close to impossible for anyone (including yourself after a month) to understand the code.
But you can also write clearly understandable code - and not take care of minimizing keystrokes, which indeed is a very bad practice.
Another thing - there is no such thing like: you MUST write short functions. One simple reason - it is always easier to read consecuent row of source code lines than to jump permanentlly from one function to another, then from there further (deeper) and again and again. So my advise - write the way YOU like, the way YOU feel convinient with. And luckily for us - C allows you to do it.
And one last thing - from an old-style programmer. Do not start to write code before you have a more or less (at least high-level) understanding of what you are writing.
Good luck!
Jevgeni.
PS. ILE-C compiler accepts C++ style comment mark "//". You should not necessarily use /* */
-----Original Message-----
From: c400-l-bounces@xxxxxxxxxxxx [mailto:c400-l-bounces@xxxxxxxxxxxx] On Behalf Of frank kolmann
Sent: Monday, January 20, 2014 11:42 AM
To: c400-l@xxxxxxxxxxxx
Subject: [C400-L] C syntax errors
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
--
This is the Bare Metal Programming IBM i (AS/400 and iSeries) (C400-L) mailing list To post a message email: C400-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/c400-l
or email: C400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives at
http://archive.midrange.com/c400-l.
midrange.com
