Problem with Designated Initializers in SDK when using C++

[zrrr]

Hi,

I want to program the nrf51822 with C++ and from what I've found here it should be possible.

But nrf_drv_gpiote.h contains designated initializers wich aren't supported by C++. I'm including all SDK headers inside an extern "C" {...} block but still get the following error when I use the GPIOTE_CONFIG_OUT_SIMPLE macro:

sdk/components/drivers_nrf/gpiote/nrf_drv_gpiote.h:85:5: sorry, unimplemented: non-trivial designated initializers not supported
 }
 ^
src/main.cpp:648:46: note: in expansion of macro 'GPIOTE_CONFIG_OUT_SIMPLE'
 nrf_drv_gpiote_out_config_t led_config = GPIOTE_CONFIG_OUT_SIMPLE(0);

I'm using SDK version 10 and compiling all .c files with GCC (-std=gnu99) and all .cpp files with G++ (-std=c++14).

How to deal with this problem?

[RK]

and try the search - all this is discussed constantly in lots of threads, with fixes and workarounds and advice. Search box is ^^ up there

[zrrr]

Thanks for the link! I tried the search but couldn't find anything for the designated initializer problem (though i found threads for the asm problem).

It might be a good idea to prioritize C++ compatibility and ISO C/C++ conformity in future versions as (judging from the amount of unfixed problems/complaints) both seem to currently be a very low priority to the dev team.

[RK]

I don't think the dev team use C++ so they don't see issues which break (I'd guess the designated init problems are just new fields added to a C-struct, that doesn't matter in C, but trips up C++ until you change the initialiser and add the new ones in order). I don't think that's going to change but just open a support case on 'My Page' if you find issues like this and they usually do get fixed within a release or two of the SDK. The asm issue has been remarkably long-running, few take that long, they did actually try to fix it in the most recent SDK release, but got the cast wrong because c++ has its own peculiar rules about when it uses shorts for things, C packs the enums into a byte.

You really should find there are only a few issues using the SDK with C++ and you learn them very quickly. I still wish there were extern "C" in all the header files but .. you just put it in the code

[tesc]

Yes, the dev team use C, so C++ issues will not be detected. The SDK (and SoftDevice headers) are provided in C. Porting to C++ should be relatively easy, but it would require some workarounds because of subtle differences. Any input on what we can do to improve C++ compatibility is appreciated.