This is my series of posts on C. The aim is to document techniques for writing medium- to high-level programs. Modern C programming has moved away from the focus in absolute efficiency, and there are many large programs solving problems where abstraction is necessary. Efficiency is still important; but it’s often satisfactory to run 20% slower if it means the code is easier to maintain!
As I write posts I’ll add them to this brief table of contents. You can also see a list of the posts in the category.
Note that I do not get a lot of feedback before posting. I would be interested in any criticism, and am happy to expand a post if a reader suggests it; or to correct a post where an error is pointed out to me. :-)
Introduction
- The initial post on Higher-level C in which I lament the scarcity of C programming books.
Objects in C
- The basic technique of using a struct to create a user-defined type (a class).
- How to encapsulate methods with data.
- And how to use method polymorphism using function pointers.
Code organisation
- Simulating namespaces with structs.
Possibly forthcoming
Memory Management: malloc/free; Problem of computing optimal destruction of object; Pools; GC, E.g. Beohm; Pre-allocated and stack-based memory
Data structures: Strings; Collections; Generic data structures; Type safety; polymorphism.
Classes: Common base object; Interfaces; Multiple-inheritance (possible?); Multiple-interface implementation (possible?)
Functional programming: Laziness; Closures; Callbacks
Introspection and reflection: E.g. Printing an object
Exception handling: setjmp/longjmp; Exception as return value; Macro misuse
Code organisation: Dependency Injection
EJRH 
Pingback: Higher-level C | EJRH
Pingback: Low-level priority queue optimisations | EJRH
Pingback: Project summary | EJRH
I really like this.
It’s nice to know I’m not completely nuts, when I try and explain my reasoning for using pointers and pseudo-OOP in c.
Someday I hope to be able to make statements about topics such as these without having to use an “I think” or “It’s my opinion” prefix.
Do you, or does anybody have any recommendations for using these techniques in an embedded environment; where malloc might not always be available or even desired?
Hi Grit, it seems most of the advice on memory management is about using malloc/free at least, or something even more heavyweight! I can’t give you any real recommendations myself. Perhaps there is open source embedded code you can look at for examples? I’m guessing a lot of what runs on arduino and similar is written without malloc. Depending on what you’re trying to program, it might just be easy to allocate a fixed pool of object slots, and manage them yourself in the code (a lot of the complexity of memory management is supporting the allocation of different sized objects in the same space; if all your objects fit into only a few sizes then you can avoid that).