C for high level programmers (slides)

    void foo (char bar [42]) {
        // ...
    }

    void foo (char (*bar) [42]) {
        // ...
    }

C does some very strange things. There usually is (or at least was) a good reason for it to do so, but especially if you're a beginner, you need to be on your toes if you really want to use it well.

On the other hand, I downloaded the CUDA SDK. I couldn't even figure out where the GPU compiled code even resided. I suppose I was just supposed to take it as it "just works" (and it did), but it all left me highly uncomfortable.

Trying to figure out how Grunt/Gulp/Broccoli, LESS/SASS/Stylus/Jade, Coffeescript, Uglify, Bower, Browserify, Require.js, AMD/CommonJS, NPM etc all work together is a nightmare.

It's all too hard, so people added Yeoman, Brunch, or other things to generate application configs - but now you need to decide which skeleton/generator you want, which takes you down the JS and CSS framework rabbithole.

Of course the only sane response to all this is to write another build system that doesn't repeat everybody else's mistakes.

In comparison, Makefiles are remarkably usable.

Before C, I was pampered and took everything for granted. Now I appreciated my life more after C and feel blessed every time my IDE gives me a warning.

GNU coreutils (and in general, a lot of the GNU projects) are rather excessively complex and certainly not what I'd advocate "learning by example" from. Take a look at the BSDs' standard utilities for simpler, more straightforward code.

But even if I can eventually understand what some code does, how do I learn why it does it that way?

I believe that the best way to learn "why" is to ask "why not". You will see that a lot of programmers, IMHO unfortunately really don't know why and are just doing what they were taught to. If you don't do X, then either [1] it doesn't matter and you don't actually need to, or [2] it does and you realise the reason why, when you see how X makes things simpler/more efficient for either the programmer or the machine, or both.

* Head First C - David Griffiths

* Expert C Programming: Deep C Secrets - Peter Van Der Linden

Make is fairly easy to learn, at least in its basic form. Autoconf is horrendous.

As for compiler flags, the only ones I ever worry about are `-O`, `-g`, `-c`, CFLAGS and LDFLAGS.

What I've learned is that the way C includes other files/libs is extremely simple. The header files are simply a simple mapping of the code in the `.so` or `.a`. If it's a n `.so`, you can't make it a static executable and if it's `.a` you have to.

I've never worked directly with low-level microcontroller programming, and the extent of my electronics knowledge is some fiddling with arduino. When I did that I used ino (http://inotool.org/) to compile and upload code to the board.

EDIT:

Projects that have good C code include: http://suckless.org/ and the linux kernel (and other stuff by Linus Torvalds). Avoid anything with GNU (most of it's over-engineered)

http://shop.oreilly.com/product/0636920033677.do

I used http://remarkjs.com/ to make the slides. All you have to do is include the script, add a textfield with your content in markdown and it automatically converts to a slide show.

For domain specific stuff you use domain specific stuff. For generic stuff, well, you tend not to want generic data structure libs that come with other languages stdlibs because its hard to do those both efficiently and cleanly (you can only pick one). Its easy enough to hack up a dynamic array or a hash table with a fixed capacity that can only insert and get, maybe delete, so you tend to do this when you need it. (Also, a sorted array usually does very well in place of a hash table with not much code)

Memory managment it depend what your doing. I use a lot of arenas, and pools, and as a result very rarely have to worry too much about memory management. Some things become harder here like dynamically sized arrays, but you can do this with chunks of fixed length arrays. (or whatever)

I have to do very little string processing most of the time (and when i do they usually have small, known maximum lengths), and i imagine this memory management technique would work less well for that.

Unix system programming in OCaml - https://ocaml.github.io/ocamlunix/

Compiled - source files are run through a compiler which produce some output file that's then run. With C or Java you run the .c or .java file. C compiles to an executable, Java compiles to byte code.

Interpreted - source is fed to an interpreter which typically turns it into some kind of representation that's immediately run with no intermediary step on the part of the user/programmer. Perl, PHP, Ruby, Python, JS, TCL, etc. are typically run this way.

The terms are inherently a little muddy, since you can compile some interpreted languages to bytecode (common in PHP, and how JRuby/Jython are often run), and in theory could write a dynamic loader for C / Java to run them as interpreted - no idea if someone has been so perverse as to do it.

The behavior of a JRE or other runtime in loading bytecode/whatever to execute - JIT, AOT, or whatever has to do with how a runtime handles bytecode that's already been compiled from source and turns it to machine code to execute. The terms show up there also, but have a different meaning.

That's not what people are typically discussing when they talk about a compiled vs. interpreted language, and the author was correctly using the terms when referring to languages to draw the distinction in what a developer does (rather than what a runtime does, which is basically irrelevant to C).

When using preprocessor macros in C/C++, these only make sense with a compilation step. But they are part of the language, are they not?

In interpreted languages, you generally have an eval function/command that lets the interpreter execute any dynamically constructed code. That eval function arguably is percieved as part of the language, but only works in an interpreted environment.

The things I've seen people do to avoid a goto are pretty awful though. If you ever use a 'do {} while (0)' just to break out of it, you should feel bad. Goto is much clearer and cleaner than nonsense like that.

Gotos are a specialised tool that many misuse, especially historically, but when you need them, you need them.

https://github.com/zedshaw/mongrel2/blob/master/src/http11/h...

A nicer example of the use of goto's in Mongrel2 is the check macro:

https://github.com/zedshaw/mongrel2/blob/a884aef0f4a460e130d...

The convention of the project is that every function that has to deal with an error condition has an "error" label. These macro a used to jump to that label to clean up the function before returning. Here's an example:

https://github.com/zedshaw/mongrel2/blob/a884aef0f4a460e130d...

I think that this use of gotos is more clear than the alternative of a lot of nested if statements checking for success or having the clean up logic duplicated in a lot of places.

    status_t foo (result_t (*result))
    {
        status_t status = good;

        resource1_t r1;
        if (failed (status = get_r1 (&r1)))
            goto end;

        resource2_t r2;
        if (failed (status = get_r2 (&r2)))
            goto cleanup_r1;

        resource3_t r3;
        if (failed (status = get_r3 (&r3)))
            goto cleanup_r2;

        status = get_result (result, r1, r2, r3);

    cleanup_r3:
        release_r3 (r3);
    cleanup_r2:
        release_r2 (r2);
    cleanup_r1:
        release_r1 (r1);
    end:
        return status;
    }

    result_t foo ()
    {
        // Allow exceptions to propagate
        auto r1 = get_r1 ();
        auto r2 = get_r2 ();
        auto r3 = get_r3 ();

        return get_result (r1, r2, r3);
    }

[0] http://c.learncodethehardway.org/book/

Also, suppose you want to pass a variable of a large data type, like an image, to a function. Instead of copying the entire variable, just pass the cheap pointer. The analogy is giving someone an URL vs the source code of the site for them to paste in the browser (You can't fit the latter onto a QR code, for instance, but you can the former).

Some architectures try to have a more sophisticated approach and have some sort of 'fat pointer' in which pointer values have a special tag and are subject to special rules so they can only point to valid objects. The exact rules used and what constitutes 'valid' is specific to the architecture. Intel has introduced mpx on newer processors to check array bounds with such a scheme, and older processors such as LISP machines have much stronger (but less efficient) schemes.

What a pointer does is add a level of indirection: so instead of having a value "an integer" you can have a value which is "the location of an integer". A variable holding such a value can be assigned the location of any integer variable, and importantly can also be reassigned the location of a different integer variable.

The additional indirection also means that you can link one data structure to another without including one as an integral part of the other.

Copying an object around all over the place (into functions, out of them) would be expensive. It would be like copying an entire ledger every time you wanted to make a change to the ledger. Far better would be to hand the ledger around, or when looking for it ask "where is it?" and be pointed to where it is now.

It also makes it simpler to make sure all your data is in one place, which is a good thing for program design.

Quite often, C is the right tool for the job. That isn't likely to change.

LINQ is neat, of course.

On Linux, malloc will appear to give you memory even if there is none left to give, so checking the error is not important.