Can you make some small changes for C++ compatibility.

[Phil Young]

I had to modify the 0.10 mesh / rf sdk's to integrate them into a C++ environment and have now to do the same again with the latest SDK's due to some coding issues in the supplied FW

All of our code is written in C++ and my mesh application code also gets compiled into a simulation environment, switching to C is a more difficult option than switching to an alternative BT device supplier.

The issue for me since we use the Keil environment is mainly an issue with incomplete parameter specifications, many functions take an array of undefined length as their final parameter, this is not compatible with C++, but the ARM compilers allow it using the --gnu switch.

This however causes some compatiblity issues with other files which check for the definition of __GNUC_ causing conflicts, for example the assert definitions in app_util.h

A simple fix for this in these and simpler definitions would help greatly, make the test for __GNU_C conditional on __CC_ARM not being defined, this would have no impact on users of GCC, but would avoid users of ARM compilers needing to modify the source files when using C++

Better still, avoid the use of undefined length arrays, it is not necessary as defining them as length 1, or better still a pointer would resolve the C++ compatibility, after all you are actually passing a pointer anyway,

[awneil]

Have you seen this thread: https://devzone.nordicsemi.com/f/nordic-q-a/39234/why-isn-t-the-sdk-written-in-c ?

[Phil Young]

Thanks, interesting reading but they have not addressed any of the issues at Nordic.

I'm not asking them to write it in C++, simply to avoid using constructs that do not compile with the ISO/ANSI C++ compiler modes.

I've written all my embedded code in "C++" for over 20 years and can't understand why anybody would choose to start a new development in "C", but for me it's a bigger issue since I instantiate hundreds of instances of my code in a simulation environment for system level modelling and C++ provides the encapsulation to do that easily and efficiently ( and also produces significantly more efficient object code ).

The Nordic code is totally incompatible with this technique as it is not possible when using any globals as they cannot be distinguished between multiple instantiations of the device an a model.

one reason for the increased efficiency of C++ is that writing object oriented code makes you group data into objects that are related and operated on by the same functions thereby providing much better localization of data which greatly simplifies effective address calculation, i.e. the compiler gets to use a single pointer ( this,  generally R0 ) with short immediate offsets for accessing data a lot more often and  that reduces code size and increases execution efficiency significantly.

Look at any compiled code and the bulk of the instructions are for effective address computation when data is too far apart to be accessed in this manner.

Frankly the structure of the data in the Nordic code is really badly managed and inefficient but I can live with that provided I can write my code in C++.