The MagPi does C :-)

[PeterO]

New "MagPi Essentials" book : "Learn to code with C"
https://www.raspberrypi.org/magpi/issue ... ials-c-v1/
PeterO

[stephj]

Being a salty old ‘C’ dog myself, this book is a very nice piece of work. The original K&R “The C Programming Language” book has all you need to know about ‘C’, but it is rather terse if not outright ‘crusty’ for the beginner. This book adds proper working examples to present the topic of each chapter. A lot, but not all, of the language is covered, but by the time you have worked through and experimented with the examples given, you should have a reasonable idea of how to put a ‘C’ program together.

There’s a lot more to be had, but after this book, K&R might not seem quite as daunting.

I like it!, stephj.

[PeterO]

I asked Simon about any plans for follow on titles... I don't think he'll mind me reproducing his answer here...

"To be honest, this book only got written because I suggested to the MagPi staff that I would write one on creating GTK+ applications, and it then occurred to me that an understanding of basic C would be a prerequisite, so the GTK application guide was postponed by a year or so.

So I do already have vague plans for writing a "programming for the desktop in C" book, which would be primarily about GTK GUI code, some stuff on glade, some basic GLib stuff, that sort of thing - I probably won't be starting work on it until next year at the earliest.

He added that the MagPi people are keen to get more books and articles written on more technical subjects such as more advanced C topics.

PeterO

[jamesh]

Fortunately, Simon has not fallen into the same trap as K&R, going with offset curly brackets. That decision has made many people lives a misery. Allman style FTW!

(Let the flames commence)

[mikronauts]

K&R notation is green, saves quite a bit of paper by not wasting empty lines on the '{' bracket... and you can see more lines in an editor.

I've been programming in C for >35 years, K&R RULEZ!!!!

[jamesh]

K&R notation is green, saves quite a bit of paper by not wasting empty lines on the '{' bracket... and you can see more lines in an editor.

I've been programming in C for >35 years, K&R RULEZ!!!!

You've been doing it wrong for 35 years?

[PeterO]

K&R notation is green, saves quite a bit of paper by not wasting empty lines on the '{' bracket... and you can see more lines in an editor.

I've been programming in C for >35 years, K&R RULEZ!!!!

You've been doing it wrong for 35 years?

I'm with James. I've been writing C for ~35 years, but I never liked the K&R bracket style. Simon's layout is very clear and although I don't do it my self the use of a space before each "(" leads to a very readable presentation.
I'm a fan of long descriptive variable names so I like keep spaces to a minimum within lines otherwise lines can get too long.

PeterO

[karrika]

K&R notation is green, saves quite a bit of paper by not wasting empty lines on the '{' bracket... and you can see more lines in an editor.

I've been programming in C for >35 years, K&R RULEZ!!!!

You've been doing it wrong for 35 years?

What! I had no idea you could do it in any other style than K&R and still call yourself a C programmer!
Don't say that you also use emacs instead of vi?

[PeterO]

Don't say that you also use emacs instead of vi?

I'm ambi-editor-ous

I can cope with ":wq" and "meta X indent-region"


PeterO

[tito-t]

Didactically great structure with very easily comprehensible code examples and detailed easy-to-understand explanations, even for non-English native speakers
Clear and informative layout with code blocks, screenshots and teaching texts -

Impressive and awesome, I love it!


Hopefully there will be some extensions and follow-ups:
C for GPIOs
C for UART, i2c and SPI
C for HATs
C for graphics
C for the Pi Cam
C for audio

8)

[jojopi]

My advice to any C programmer would be always to compile with "gcc -Wall". Many of the people posting C questions on the forum would have had at least some hint to what their problem was if they had been using the diagnostics.

Unfortunately, telling people to enable warnings is incompatible with teaching them bad habits like "void main(void)". Simon Long's attempt to justify that deliberate error is also a false dichotomy. You do not have to choose between "int main(int argc, char *argv[])", and something quite wrong. Just "int main()" is valid in all C standards, and is the shortest and least "scary" option.

I wholeheartedly agree with keeping the examples as short as possible. Omitting the return statement from main() is a far lesser offence than giving it the wrong type. In C99 it even produces a defined exit status, zero.

[AndyD]

Thanks @jojopi, I was beginning to think I was the voice in the wilderness.

[ejolson]

Just "int main()" is valid in all C standards, and is the shortest and least "scary" option.

The idea that it is okay for a teacher to lie in order to make a subject easier for the students to learn seems misapplied here. It is disappointing that an otherwise nice introduction to C is spoiled by getting "hello world" wrong.

[swampdog]

Thanks @jojopi, I was beginning to think I was the voice in the wilderness.

Well, it's swings & roundabouts. Back in K&R I'd have happily written "void main(..)" because it meant you didn't care about the return value. Obviously "int main(..) {/*code*/;return 0;}" is the most portable way to proceed and because "argc,argv" can be omitted that concept does not have to be introduced until later.

IMO, it's easier to explain "int main()" - the status returned than "void main()" because in the latter case you have to introduce the concept of the runtime startup and explain possible "random" return codes to the caller.

eg: (and I dunno why I recall this but not what day it is half the time) the long defunct Mark Williams C compiler for the Atari ST (motorola 68k processor) used register d0.w to return values from functions thus this triviality..

Code: Select all

void main()
{printf("foo\n";}

..would in fact end up returning the result of printf(), as would "int main()" in fact because there was no implicit "return 0" generated. I dunno arm asm but on the face of it the same thing appears to happen.

[ejolson]

Back in K&R I'd have happily written "void main(..)"

K&R C does not include void. That came afterwards and is included in the ANSI standard.

In the years following the publication of K&R C, several features were added to the language, supported by compilers from AT&T (in particular PCC[15]) and some other vendors. These included:

. void functions (i.e., functions with no return value)

. functions returning struct or union types (rather than pointers)

. assignment for struct data types

. enumerated types

[PeterO]

If you are unhappy with some "hand waving" in an introductory book, then you've possibly not tried to teach anyone C from scratch.

I too raised the issue at the time the articles appeared in the MapPi, but accepted Simon's reasoning that since neither the return value from main, nor argc or argv were being covered, it was a reasonable compromise to make for the sake of simplicity and not overloading the reader with unnecessary details.

It is slightly disappointing to see that even by the end of the book argc and argv have still not been covered, but in a short introductory book like this many other topics that a seasoned C programmer would consider important have still not been introduced.

I think what would be really useful would be for us (the seasoned C programmers) to try and "crowd source" some follow up chapters to cover the next important topics that a new C programmer will need. I thought someone had already posted a list of possible subjects but it seems to have vanished

So how about some suggestions for follow on subjects ?

PeterO

[tito-t]

I agrre about

a reasonable compromise to make for the sake of simplicity and not overloading the reader with unnecessary details.

Both the int main() thing and the -Wall thing could be introduced in one of the more advanced chapters.

About follow-up topics, I have already posted some proposals, what about them?
They would lead to more Linux- and especially more Pi- and Debian-related C subjects and issues (in random order):

Didactically great structure with very easily comprehensible code examples and detailed easy-to-understand explanations, even for non-English native speakers
Clear and informative layout with code blocks, screenshots and teaching texts -

Impressive and awesome, I love it!


Hopefully there will be some extensions and follow-ups:
C for GPIOs
C for UART, i2c and SPI
C for HATs
C for graphics
C for the Pi Cam
C for audio

[PeterO]

I agrre about

a reasonable compromise to make for the sake of simplicity and not overloading the reader with unnecessary details.

Both the int main() thing and the -Wall thing could be introduced in one of the more advanced chapters.

About follow-up topics, I have already posted some proposals, what about them?
They would lead to more Linux- and especially more Pi- and Debian-related C subjects and issues (in random order):

Didactically great structure with very easily comprehensible code examples and detailed easy-to-understand explanations, even for non-English native speakers
Clear and informative layout with code blocks, screenshots and teaching texts -

Impressive and awesome, I love it!


Hopefully there will be some extensions and follow-ups:
C for GPIOs
C for UART, i2c and SPI
C for HATs
C for graphics
C for the Pi Cam
C for audio

Yes that is the list I was thinking about, but I've not had my first cup of tea yet Most of those could be covered by reference to existing libraries, so a prerequisite would be a chapter on how to use libraries and how to read their man pages or other API information.

PeterO

[tito-t]

yes, showing some man pages and references will be indispensible, but they wouldn't compensate for a good didactic step-by-step introduction, not overloading the reader with unnecessary details.

Just like in this great MagPi book for beginners to C:

It does not start by listing references, but by step-by-step code examples, not overloading the reader with unnecessary details, and list function and syntax references in the appendix.

[karrika]

I have been maintaining the cc65 compiler especially for Atari Lynx for many years.

Part of the fun is to be able to draw something on the screen, read inputs from joysticks or keyboards and create your own masterpiece.

In the old retro world we had a Tiny Graphics Interface library.

Code: Select all

tgi_setcolor(COLOR_RED);
tgi_bar(xmin, ymin, xmax, ymax);
tgi_goto(x, y);
tgi_lineto(x, y);
tgi_outtext(str);

For inputs old consoles used joysticks.

Code: Select all

joy = joy_read(JOY_1);
if (JOY_BTN_RIGHT(joy)) {
    steering += speed;
    if (steering > 100) steering = 100;
}
if (JOY_BTN_LEFT(joy)) {
    steering -= speed;
    if (steering < -100) steering = -100;
}

If you want to use Raspberry Pi for developing games for old consoles you can get the C-compiler and compile all the required tools from https://bitbucket.org/atarilynx/lynx.

The tutorials for developing games using these tools is at https://atarilynxdeveloper.wordpress.co ... g-started/.

We have a very nice retro gaming community writing games for old 8 bit consoles. And it would be nice to get more good new games for our beloved consoles.

You can easily develop and run all these C-games on a Raspberry Pi.


It is also possible to use C with Allegro libraries for developing for Raspberry Pi. But this is a bit more complicated than writing code for consoles. Here is my C-based board game running on PiZero and a HDMI monitor.

[tito-t]

ok, in short words, about MagPi C programming follow-up topics besides these:

C for GPIOs
C for UART, i2c and SPI
C for HATs
C for graphics
C for the Pi Cam
C for audio

now another one:

C for game programming

[PeterO]

I think we should also produce a list of "C topics" as well as "application areas" to consider.

ThreeFour that quickly come to mind are :
Processing the command line arguments (argc,argc,libpopt etc)
More examples of formatting output with printf (precision/field widths etc)
Pointers to functions (and their use as callbacks in event loops)
How to use the maths library, libm (maybe as an example for reading man pages ?).

For examples of using other libraries I would suggest:
Using Lists and Strings from glibc (I know some don't like glib but there is some useful stuff in there even if you aren't using GTK+ or gnome)

Also some simple CMake examples would be useful. Some coverage of "pkg-info" and installing "-dev" packages would help as well.

PeterO

[jahboater]

Code: Select all

void main()
{printf("foo\n";}

..would in fact end up returning the result of printf(), as would "int main()" in fact because there was no implicit "return 0" generated. I dunno arm asm but on the face of it the same thing appears to happen.

Actually it just does "b puts" so it returns whatever puts() returns, presumably gcc knows it will be zero for the standard.

[swampdog]

Back in K&R I'd have happily written "void main(..)"

K&R C does not include void. That came afterwards and is included in the ANSI standard.

In the years following the publication of K&R C, several features were added to the language, supported by compilers from AT&T (in particular PCC[15]) and some other vendors. These included:

. void functions (i.e., functions with no return value)

. functions returning struct or union types (rather than pointers)

. assignment for struct data types

. enumerated types

Wikipedia is not wholly correct unless it mentions many of the K&R compilers supported variants of the "up and coming" ansi standard for years prior to it becoming official.

[PeterO]

Can a discussion of the history of C go in another thread please ? Let's leave this one clear to discuss the content of any future tutorials or books.
PeterO