Default parameters, C++ determinism and other C++ questions

As I mentioned on a previous occasion, I always welcome questions whenever I make a presentation, do a web seminar, write an article or blog post or whatever. Even very simple queries give me ideas for topics to discuss. I always take the view that, if one engineer poses a question, there are probably a bunch of guys who would also like the answer.

Once again, I am turning my attention to C++ …

What are the advantages of omitting parameters (which leads to creation of default values)?

I strongly believe that a software engineer’s primary responsibility [whatever kind of software they are developing] is to write clear, understandable and maintainable code; everything else is secondary to that goal. At first sight, it might seem that having the option of making function calls, without the requirement to include a value for every parameter, might lead to obscure code. Indeed this is certainly a way to write obfuscated code, but, used properly, default parameter values in C++ can make code easier to read.

This is particularly obvious with the API [Application Program Interface] to various types of software libraries. For embedded developers, a good example is an RTOS, which may have some very complex API calls, giving the programmer much flexibility. In many cases this is a degree of flexibility that is rarely required. For example, here is the prototype for the API call to the Nucleus RTOS to create a semaphore:

STATUS NU_Create_Semaphore(NU_SEMAPHORE *semaphore, CHAR *name, UNSIGNED initial_count, OPTION suspend_type);

The first two parameters are clearly unique to each call: pointers to the semaphore control block and its name. It is quite common for a semaphore to start off with a value of 1, which makes it a simple binary resource controller. It is also common to want the calling task to be suspended, pending semaphore availability and that suspension to respect the task priority. The prototype for a C++ Nucleus API call might look like this:

STATUS NU_Create_Semaphore(NU_SEMAPHORE *semaphore, CHAR *name, UNSIGNED initial_count=1, OPTION suspend_type=NU_PRIORITY);

The result is a simple call might look like this:

ReturnStatus = NU_Create_Semaphore(&MySemaphore, "My semaphore");

instead of:

ReturnStatus = NU_Create_Semaphore(&MySemaphore, "My semaphore", 1, NU_PRORITY);

Do you ever run into determinism as a potential roadblock to using C++ or any other OOP language?

The functionality in an object oriented programming language, that is most likely to render it non-deterministic, is garbage collection – the “tidying” of dynamic memory. There are deterministic garbage collectors, so this problem may be overcome. In C++, there is no garbage collection facility. An embedded developer should review how the memory allocation process [i.e. the new and delete operators] works, as this is commonly implemented in a non-deterministic way. Beyond this, there is no reason why C++ should present problems to real time code developers.

Is their any advantage of using C++ instead of C, for building RTOS?

Building an OS from scratch is not something that many embedded software engineers experience. It is almost always much more cost effective [in the short and long term] to use existing IP – either a commercial product or something from the open source community. However, RTOS developers do need to choose a language and have tended to go for C, with as little assembly language as possible. C++ may, however, be a good choice as it would give the opportunity to partition [=hide] the machine specific code and design the required data structures in a very clean way. The key challenge would be to ensure that dynamic memory allocation is performed in a deterministic fashion.

Do you recomend moving all C code to C++, or just new projects, keeping an ear to the maintenance group’s input?

There is no simple answer to this question – it depends on the specific circumstances. Also, the term “moving C code to C++” can mean a number of things. At the simplest level, it just means writing C carefully so that it would be acceptable to the C++ toolchain; at the other end of the scale, it could mean a complete redesign of the code to conform with object oriented programming principles.

Broadly speaking, the amount of effort worth spending on the migration of existing C code to a C++ is somewhat proportional to the extent of future work [maintenance or additional enhancements] that is anticipated on the code.