Sign In
Forgot Password?
Sign In | | Create Account

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.

More Blog Posts

About Colin Walls Follow on Twitter

Colin WallsI have over thirty years experience in the electronics industry, largely dedicated to embedded software. A frequent presenter at conferences and seminars and author of numerous technical articles and two books on embedded software, I am a member of the marketing team of the Mentor Graphics Embedded Systems Division, and am based in the UK. Away from work, I have a wide range of interests including photography and trying to point my two daughters in the right direction in life. Learn more about Colin, including his go-to karaoke song and the best parts of being British: Visit The Colin Walls Blog

More Posts by Colin Walls


No one has commented yet on this post. Be the first to comment below.

Add Your Comment

Please complete the following information to comment or sign in.

(Your email will not be published)


Online Chat