The world of embedded software development can feel like a very isolated place. Earlier in my career, when I was doing mostly embedded work, I remember often feeling jealous of my colleagues who were working on mobile and web applications. I would constantly hear them talking about exciting new libraries, frameworks, and tools with catchy names that supposedly made their lives easier. I was saddened by the lack of excitement and advancement of tools for those of us writing C. Read more on Cedux: Experimenting with the Redux Model in C…
I’ve used Make for a lot for small projects, but for larger ones, it was just too tedious. Until recently, there were four things I wanted my build system to do for me that I hadn’t figured out how to do in Make:
Read more on A Super-Simple Makefile for Medium-Sized C/C++ Projects…
The last time I looked at C++ was in 2002 when I was instrumental in convincing my co-workers to switch over to C#. Up until then, I had spent my entire college and professional career working with C++. That was eight long years. I don’t think I have used any one language for as long as I did C++.
Looking back at those times, I remember I couldn’t wait to part ways with my first language. It wasn’t that there was anything wrong with C++ (okay, maybe templates). It was just that there was this new world of other languages with all these fancy features that made my code much simpler. Read more on Rekindling an Old Flame with C++11…
Spin had a great blog post a few days ago on Mean Shift Clustering. It’s a powerful algorithm with a ton of applications, but an Achille’s heel:
The most glaring disadvantage is its slowness. …it can take a long time to execute. The one silver lining is that, while it is slow, it is also embarrassingly parallelizable.
Our tools Unity and CMock were written several years ago to fill a missing gap in testing C projects. We had developed the Ceedling build system, based on Ruby’s Rake. Nevertheless we—and more importantly our user base—would rather not have to use Rake, nor retrofit it into an existing Make build.
Well, we finally made it happen! Read more on CMock – Make Support for Easier Integration of Testing…
I’ve been working on a project with a diverse set of software components that must all work together and communicate over the network. There are separate Mac and Windows clients that must communicate with the same unix server. And while there’s already a well-defined protocol for their network communication and message passing, we also need to transmit a large stream of somewhat time-sensitive data. Read more on Multiplatform C (with Networking)…
The C language is long from dead. In fact, it is still the most popular programming language in the world. Of course, C still has those dreaded pointers that allow attempted access to arbitrary memory locations. Even though when you try to access invalid memory, things still go BOOM! Read more on byte_array – The Missing Built-in Type for C…
A couple of days ago, I read something that stuck in my mind:
“Monitoring trick: Add a line to the beginning of your runit run scripts
to bump a counter. Alert when the derivative is unreasonably high.” –
@nrr, 4:05 PM – 2 Nov 2014
Google Protocol Buffers have become a very popular serialization mechanism for simple to complex/variant data structures. Due to the variation of message formats in a given protocol, the presence and/or lack of fields on an ad-hoc basis makes implementation in the C language somewhat of a challenge.
Three Protocol Buffers Libraries for C
Thanks to the open-source world, a couple of valid options exist, but choosing the right one depends on the complexity of the protocol and memory/performance requirements.
Google Protocol Buffers for C++
The obvious first choice may seem to go right to the source. Google’s Protocol Buffer Compiler supports the generation of a C++ protocol implementation from a .proto specification. Though you are developing in C, and your complier supports C++, you could use the C++ API directly from C, or at least create a C wrapper for the target protocol.
- Pros: Formally supported by Google, bleeding edge
- Cons: Well, it’s C++ and does lots of dynamic memory allocation
While working on a library for property-based testing in C, I discovered a trick that can be used to make significantly nicer library interfaces in C99: “designated initializers”. As of C99, struct literals can have their fields set by name, in any order. The C99 standard explicitly updated the behavior for how fields in struct literals are handled:
6.7.8 point 21:
“If there are fewer initializers in a brace-enclosed list than there are elements or members of an aggregate, or fewer characters in a string literal used to initialize an array of known size than there are elements in the array, the remainder of the aggregate shall be initialized implicitly the same as objects that have static storage duration.” (emphasis mine)
Since memory with static storage duration is already initialized to zero, this means that in C99 we can finally depend on stack-allocated structs’ fields being set to zero, rather than garbage data from previous stack frames. This is a huge improvement! If pointers to structs are used as arguments for function calls, it also gives C99 a portable way of using optional and keyword arguments. Read more on Nicer C99 APIs with Designated Initializers…