Why isn’t the SDK written in C++?

[Jeffrey Haynes]

This may be an unpopular question but the Nordic SDK seems to go to great length to perform what is effectively object-oriented programming while still avoiding c++. This leads to, among other things, an overly complex sdk rife with macro string concatenation and other evils. In our project we spent the first six months wrapping every part of the sdk into a coherent object model. The wrapping was painful but paid off dividends when we went to actually do the real work. 

Hopefully I don’t need to extol the virtues of c++ in embedded systems. Others have already done that for years: https://www.embedded.com/design/programming-languages-and-tools/4438660/Modern-C--in-embedded-systems---Part-1--Myth-and-Reality

Has Nordic considered this?  It would make your products much more attractive, at least to us. 

[ovrebekk]

Hi Jeff

We don't have any plans to rewrite the SDK in C++, no, but in general we try to make sure it is compliant. 

Then you can choose to write the application in C++, even if the lower level drivers and libraries are written in C. 

Best regards
Torbjørn

[Nguyen Hoan Hoang]

Really?! 

These kind of defines bellow are not compilable in C++ and there are tons of them in the SDK.

#define BLE_DB_DISCOVERY_DEF(_name)                                                                 \ 
static ble_db_discovery_t _name = {.discovery_in_progress = 0,                                      \ 
                                   .discovery_pending     = 0,                                      \ 
                                   .conn_handle           = BLE_CONN_HANDLE_INVALID};               \ 
NRF_SDH_BLE_OBSERVER(_name ## _obs,                                                                 \ 
                     BLE_DB_DISC_BLE_OBSERVER_PRIO,                                                 \ 
                     ble_db_discovery_on_ble_evt, &_name)

[Jeffrey Haynes]

Good to hear :) 

I can only speak for our team but we essentially spent the first six months of our project “prettifying” the API so it was more approachable.

I personally like “Qt-style” C++, so as examples we have classes with names like BluetoothService, Twi, TwiDevice, Storage, Spi, QuadSpi, Random, Uart, Power, etc. 

The biggest payoffs come in areas of the SDK where it is necessary (in C) to constantly supply context in the form of handles, etc. or where resources are tracked through global variables created via macro string concatenation.  We were able to replace much of this with fairly simple and succinct classes.

This obviously required a lot of upfront investment (especially when deciphering and unrolling meta-macros) but the upshot to us is that onboarding of new devs and maintenance is vastly shortened/improved. 

I realize what I’m asking is a significant effort and that C is targeting the lowest common denominator. I just think the embedded community needs to change, especially when dealing with complex services like BLE where one is forced to do c-style OOP. At that point using C seems like willfull ignorance of the language features in C++. 

Thanks, best of luck in your crusade!

Jeff

[ovrebekk]

Hi Jeff

Thanks a lot for sharing your motivations for using C++. The fact that you are spending so much time on your own to add a C++ wrapper on top of the SDK is interesting. 

I will continue to push internally for better C++ support 

Best regards
Torbjørn

[awneil]

ovrebekk said:

Thanks a lot for sharing your motivations for using C++.

Some more motivations here:

devzone.nordicsemi.com/.../can-you-make-some-small-changes-for-c-compatibility

[ovrebekk]

Thanks Andrew

I will relay it back to the team. 

Best regards
Torbjørn

[CheMax]

I would also like to switch to C ++ for a number of reasons. I will give the main thing: the project colleagues have a large number of developments in C ++ and they have to rewrite their existing code to pure C. It is sad (

But I still stop things like:
- freeRTOS written in pure C;
- SDK from Nordic also written in pure C.

But I do not think that I will be able to go fast enough and just go. On the other hand, the availability of support in SDK will contribute to the progress in the development of programming skills).

Maybe arrange a survey and see how many people actually want to see support for C ++?

[Nguyen Hoan Hoang]

Why would you have to rewrite C++ code to C ?  C++ is a super set of C.    

This C++ Object abstraction library works on top of the SDK and other C libraries no problem at all.

[Jeffrey Haynes]

Agreed, you definitely do not need to rewrite your C++ code as C. The caveat to that would be if you’re using heavy dynamic allocation such as stl/boost. But in that case you don’t have a language issue, you have a memory issue and you’d likely have to rewrite your code anyway. 

[CheMax]

At the moment I only know C. And there is no time to study and move to C++, there are many projects ...

We use free RTOS in our projects, I assume that difficulties may arise with it.

The person who performs digital signal processing uses a standard template library. For a DSP processor with external memory, this is normal, but for the MCU ...

But still I will try)

P.S. Link leads to the missing page.