Beware that this post is related to an SDK in maintenance mode
More Info: Consider nRF Connect SDK for new designs
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

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

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. 

Parents Reply Children
  • 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)
    

  • Precisely. We spent days “porting” this sort of thing to C++. There are clearly some C devs at Nordic who simply can’t be bothered to learn a new language. 

  • Thanks for the reminder, I will resume my lobbying efforts internally ;)

    If you can share some input on why you are using C++, and what problems it helps you solve, it will help me argue the case for C++ support Slight smile

    Best regards
    Torbjørn

  • 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

  • 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 Slight smile

    Best regards
    Torbjørn

Related