Problem with Designated Initializers in SDK when using C++

RE: Problem with Designated Initializers in SDK when using C++

tesc — Tue, 22 Mar 2016 10:02:09 GMT

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.

RE: Problem with Designated Initializers in SDK when using C++

RK — Sun, 20 Mar 2016 00:28:05 GMT

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

RE: Problem with Designated Initializers in SDK when using C++

zrrr — Sun, 20 Mar 2016 00:19:14 GMT

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.

RE: Problem with Designated Initializers in SDK when using C++

RK — Sat, 19 Mar 2016 23:53:47 GMT

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

RE: Problem with Designated Initializers in SDK when using C++

RK — Sat, 19 Mar 2016 23:53:09 GMT

yeah that's a known bug, the cast in there is to uint8_t instead of uint16_t. We discuss this every time a new SDK release comes out. it's currently on the list of known issues and may get fixed one day. Until then, modify the file to say uint16_t and continue on with the day.

devzone.nordicsemi.com/.../

You'll come across a few more here and there but they're all pretty trivial, although the designated initialisers are annoying.

RE: Problem with Designated Initializers in SDK when using C++

zrrr — Sat, 19 Mar 2016 23:48:07 GMT

sdk/components/softdevice/s110/headers/nrf_svc.h:57:6: error: impossible constraint in 'asm'

But I also get more "asm operand 0 probably doesn't match constraints" warnings than I can count in other softdevice headers.

RE: Problem with Designated Initializers in SDK when using C++

RK — Sat, 19 Mar 2016 23:39:30 GMT

which assembler? Most of the C++/g++ assembler problems are well-known and documented here in the forums and lots of us use pretty much only C++, so it's quite do-able.

RE: Problem with Designated Initializers in SDK when using C++

zrrr — Sat, 19 Mar 2016 23:36:30 GMT

That I can fix this by modifying the macro is obvious but i wanted a more general approach as the SDK uses designated initializers in many places and I don't want to reimplement/modify too much in the SDK. I temporarily fixed it by filling the struct manually instead of using the macro just to run into the next problem. Some inline assembler statements don't work with g++ and throw compile errors. Seems like the SDK was never designed with C++ in mind. That is sad as I really liked the SDK (especially the exceptionally good documentation compared to other manufacturers) but C++ support is mandatory for me.

RE: Problem with Designated Initializers in SDK when using C++

RK — Sat, 19 Mar 2016 23:18:19 GMT

Change the macro to fill in all the fields properly in order and use that instead of the one in the SDK.

Importing inside an extern "C" {} block won't help as that just works for the definition of the macro, it doesn't help when you use it which is in 'c++' context.

Or factor out the functions you use it in and make them extern "C" {}