{"id":7039,"date":"2014-09-01T09:44:35","date_gmt":"2014-09-01T08:44:35","guid":{"rendered":"https:\/\/blogs.mentor.com\/colinwalls\/?p=7039"},"modified":"2026-03-26T16:44:07","modified_gmt":"2026-03-26T20:44:07","slug":"default-parameters-c-determinism-and-other-c-questions","status":"publish","type":"post","link":"https:\/\/blogs.sw.siemens.com\/embedded-software\/2014\/09\/01\/default-parameters-c-determinism-and-other-c-questions\/","title":{"rendered":"Default parameters, C++ determinism and other C++ questions"},"content":{"rendered":"

As I mentioned on a previous occasion<\/a>, 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.<\/p>\n

Once again, I am turning my attention to C++ …<\/p>\n

What are the advantages of omitting parameters (which leads to creation of default values)?<\/h3>\n

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.<\/p>\n

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:<\/p>\n

STATUS NU_Create_Semaphore(NU_SEMAPHORE *semaphore, CHAR *name, UNSIGNED initial_count, OPTION suspend_type);\n\n<\/pre>\n
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:<\/p>\n
STATUS NU_Create_Semaphore(NU_SEMAPHORE *semaphore, CHAR *name, UNSIGNED initial_count=1, OPTION suspend_type=NU_PRIORITY);\n\n<\/pre>\n
The result is a simple call might look like this:<\/p>\n
ReturnStatus = NU_Create_Semaphore(&MySemaphore, \"My semaphore\");\n\n<\/pre>\n
instead of:<\/p>\n
ReturnStatus = NU_Create_Semaphore(&MySemaphore, \"My semaphore\", 1, NU_PRORITY);\n\n<\/pre>\n
Do you ever run into determinism as a potential roadblock to using C++ or any other OOP language?<\/h3>\n
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.<\/p>\n
\n
<\/div>\n<\/p>\n
#508476361<\/a> \/ gettyimages.com<\/a><\/div>\n<\/div>\n
<\/p>\n
Is their any advantage of using C++ instead of C, for building RTOS?<\/h3>\n
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.<\/p>\n
Do you recomend moving all C code to C++, or just new projects, keeping an ear to the maintenance group’s input?<\/h3>\n
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.<\/p>\n
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.<\/p>\n","protected":false},"excerpt":{"rendered":"
As I mentioned on a previous occasion, I always welcome questions whenever I make a presentation, do a web seminar,…<\/p>\n","protected":false},"author":71677,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"spanish_translation":"","french_translation":"","german_translation":"","italian_translation":"","polish_translation":"","japanese_translation":"","chinese_translation":"","footnotes":""},"categories":[1],"tags":[313,334,300,304,374,378,340,309],"industry":[],"product":[],"coauthors":[],"class_list":["post-7039","post","type-post","status-publish","format-standard","hentry","category-news","tag-c","tag-dynamic-memory","tag-embedded-software","tag-nucleus","tag-nucleus-os","tag-nucleus-rtos","tag-programming-languages","tag-rtos"],"_links":{"self":[{"href":"https:\/\/blogs.sw.siemens.com\/embedded-software\/wp-json\/wp\/v2\/posts\/7039","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blogs.sw.siemens.com\/embedded-software\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blogs.sw.siemens.com\/embedded-software\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blogs.sw.siemens.com\/embedded-software\/wp-json\/wp\/v2\/users\/71677"}],"replies":[{"embeddable":true,"href":"https:\/\/blogs.sw.siemens.com\/embedded-software\/wp-json\/wp\/v2\/comments?post=7039"}],"version-history":[{"count":1,"href":"https:\/\/blogs.sw.siemens.com\/embedded-software\/wp-json\/wp\/v2\/posts\/7039\/revisions"}],"predecessor-version":[{"id":10298,"href":"https:\/\/blogs.sw.siemens.com\/embedded-software\/wp-json\/wp\/v2\/posts\/7039\/revisions\/10298"}],"wp:attachment":[{"href":"https:\/\/blogs.sw.siemens.com\/embedded-software\/wp-json\/wp\/v2\/media?parent=7039"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blogs.sw.siemens.com\/embedded-software\/wp-json\/wp\/v2\/categories?post=7039"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blogs.sw.siemens.com\/embedded-software\/wp-json\/wp\/v2\/tags?post=7039"},{"taxonomy":"industry","embeddable":true,"href":"https:\/\/blogs.sw.siemens.com\/embedded-software\/wp-json\/wp\/v2\/industry?post=7039"},{"taxonomy":"product","embeddable":true,"href":"https:\/\/blogs.sw.siemens.com\/embedded-software\/wp-json\/wp\/v2\/product?post=7039"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/blogs.sw.siemens.com\/embedded-software\/wp-json\/wp\/v2\/coauthors?post=7039"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}