nRFConnect Examples fail to build with C++17

Question

Greetings, 
 We've run into issues while trying to get the nRFConnect v2.4.0 examples to build for a C++17 project. The problem is easy to replicate by: 
 
 Create an example project for LLPM in VSCode/nRFConnect 
 In KConfig enable C++ Support and select C++17 
 Rename main.c to main.cpp 
 Update CMakeLists.txt to include src/main.cpp 
 Attempt a pristine build 
 Observe Terminal Output 
 
 It looks like there are a number of issues (all fairly minor?) including: 
 
 Designator order for struct initialization not matching declaration order
 
 Easy enough to reorder

Poorly designed/unnecessary macros resulting in utilizing addresses of temporary arrays
 
 The macros just initialize an array of structures... so we can just use the standard C code way of doing that and eliminate multi-level macros

Invalid C-style conversations from void* to typedef struct pointers
 
 For our project we can use the appropriate C++ style casts (static_cast or reinterpret_cast). I'm not sure how to make that C-compliant 
 Note that there are a number of C-style casts to void* deep inside the macro-chain. This can hide some fairly nasty bugs like casting a value to void* instead of the intended pointer to the value.

It's not a huge deal to make the fixes, but it's fairly frustrating for example projects to not build out of the box. The "helper" macros make things worse since the identifying the real bug requires diving down multiple layers and reengineering the intent to make the example compile. 
 Please let me know if you're able to replicate this or have an easy solution I'm missed. 
 Thanks!

jcondon · Accepted Answer

I was able to get this project to build in C++17, but the macro issue mentioned above was not trivial. I had to decipher the intent of some TERRIBLY designed macros to actually declare and initialize structure values. Note that there is ZERO documentation on this so I had to dig through many layers of nested macros to even figure out what they were attempting to do. 
 See below for how I ended up declaring and initializing the structures. This take the place of the previous definitions of the UUID and LE_ADV structure. In my own code I'll likely eliminate the INIT macros as well to avoid code obfuscation. Structures could just be initialized with standard initializers and not 5-10 layers of macros. I suggest looking at ST Micro's Low-Level (LL) libraries for the creation, initialization, and passing of structures for peripheral setup. 
 Note that this will be required for every C++ project that uses BLE (essentially every Nordic project). I suggest that Nordic quickly addresses this issue since the typical programmer who isn't vendor locked, doesn't have enough experience in both C and C++, or isn't stubborn enough won't be able to get this to work. Ideally they would also press the Zephyr development to reduce/eliminate the use of these unnecessary macros to make for more readable and reliable code. 
 const struct bt_uuid_128 BtUUIDLatency = BT_UUID_INIT_128(BT_UUID_LATENCY_VAL);
const struct bt_le_adv_param BtLEAdvConn = BT_LE_ADV_PARAM_INIT(BT_LE_ADV_OPT_CONNECTABLE,BT_GAP_ADV_FAST_INT_MIN_2,BT_GAP_ADV_FAST_INT_MAX_2,NULL);

nRFConnect Examples fail to build with C++17

Top Replies