I've seen a few discussions on C++ support. It's frustrating I can't contribute to the conversation - I'm not sure if that's because my account is too new, or if comments are closed once the case is closed. Regardless, I did a little experimenting on my own. I created a C++ class (header and source files) in one of the examples. To #include that from the main example file the file would have to be renamed from main.c to main.cpp. Normally that wouldn't be a problem, and in most cases, where it is, you can put a properly located extern "C" { } and get pretty close.
There were a few things that the C++ compiler complained about that I fixed. Many of them were simple. For example, in main.cpp (formerly main.c):
NRF_LOG_DEBUG("PHY update request.");
ble_gap_phys_t const phys =
{
.rx_phys = BLE_GAP_PHY_AUTO,
.tx_phys = BLE_GAP_PHY_AUTO,
};
The property order initialization in this example (usbd:ble_uart_freertos) doesn't match the order in the struct. That can probably be ignored through a compiler option, but it's easy to fix so I just did.
But there are many more that I can't fix. Just two simple examples:
main.cpp:169:29: error: invalid conversion from 'void (*)(const app_usbd_class_inst_t*, app_usbd_cdc_acm_user_event_t)' {aka 'void (*)(const app_usbd_class_inst_s*, app_usbd_cdc_acm_user_event_e)'} to 'app_usbd_cdc_acm_user_ev_handler_t' {aka 'void (*)(const app_usbd_class_inst_s*, int)'} [-fpermissive]
components/libraries/usbd/class/cdc/acm/app_usbd_cdc_acm_internal.h:68:6: error: use of enum 'app_usbd_cdc_acm_user_event_e' without previous declaration
Some of these can be fixed with flags (e.g. it suggests -fpermissive) but that's not really a great idea - these checks exist for a reason. What's odd is that the libraries, for the most part, already declare extern "C" {} as if they're expected to work this way ... but they don't work with an out of the box segger installation, which means they won't work with gcc.
I know there's no short-term fix for this, but I'd just like to ask Nordic to consider this: if you take all the examples and do nothing other than rename main.c to main.cpp and try to compile them, I'm guessing you'll see a lot of these same errors and warnings. I think most of the errors fall into a few ceategories:
- Struct initialization property ordering (should be really easy to fix)
- Things that are not included correctly (e.g. that enum certainly is declared; why can't usb_cdc_acm_internal.h see it?)
- Things that are assigned to pointers without typecasts (where proper type guarding isn't possible)
It doesn't bother me that much that the NRF SDK isn't C++. i've learned to interop between C and C++ as have most people who have worked a lot using C++ and 3rd party (C based) libraries. But I'm wondering if I can just throw out a request that Nordic adjust a few things. I don't have to have a fully OOP interface to for example scanning and discovery; but i'd like to be able to build my own around the underlying APIs.
Possible?
--Chris
