Can you make some small changes for C++ compatibility.

RE: Can you make some small changes for C++ compatibility.

tesc — Tue, 29 Jan 2019 09:33:59 GMT

Hi,

It appears variable length arrays were removed in nRF5 SDK for Mesh v3.0.0, and so we consider this issue to be already fixed.

Regards,
Terje

RE: Can you make some small changes for C++ compatibility.

tesc — Mon, 28 Jan 2019 16:36:40 GMT

Hi,

Thank you for the detailed descriptions.

I have notified our Mesh team and registered the request in our internal issue tracker.

For now you must manually do the required changes, but hopefully this is something we can fix for future releases.

Regards,
Terje

RE: Can you make some small changes for C++ compatibility.

Nguyen Hoan Hoang — Tue, 22 Jan 2019 18:18:52 GMT

My 2 cents to this. Do not use __attribute((packed)). it is GCC extension. The C language has #pragma pack(x) since the beginning of the C language. Microsoft added the extension #pragma pack(push,x) back in the 80s. It is now a pseudo standard supported by all compilers from VCC to OSX Clang and GCC of course and fully compatible with C++. So the structure should be rewritten as:

/** BLE Service data packets. */

#pragma pack(push, 1)
typedef struct
{
uint16_t uuid; /**< UUID field. */
uint8_t *data; /**< Service data field. */
} ble_ad_data_service_data_t;

#pragma pack(pop)

if this structure is meant to be variable length it should be

/** BLE Service data packets. */

#pragma pack(push, 1)
typedef struct
{
uint16_t uuid; /**< UUID field. */
uint8_t data[1]; /**< Service data field. */
} ble_ad_data_service_data_t;

#pragma pack(pop)

Also this kind of macro is consider as bad programming practice, please remove as well.

#define NRF_SECTION_SET_DEF(_name, _type, _count)                                                   \ 
/*lint -save -emacro(14, MACRO_REPEAT_FOR*)  */                                                     \ 
MACRO_REPEAT_FOR(_count, NRF_SECTION_DEF_, _name, _type)                                            \ 
static nrf_section_t const CONCAT_2(_name, _array)[] =                                              \ 
{                                                                                                   \ 
    MACRO_REPEAT_FOR(_count, NRF_SECTION_SET_DEF_, _name)                                           \ 
};                                                                                                  \ 
/*lint -restore */                                                                                  \ 
static nrf_section_set_t const _name =                                                              \ 
{                                                                                                   \ 
    .p_first   = CONCAT_2(_name, _array),                                                           \ 
    .p_last    = CONCAT_2(_name, _array) + ARRAY_SIZE(CONCAT_2(_name, _array)),                     \ 
    .item_size = sizeof(_type),                                                                     \ 
}

RE: Can you make some small changes for C++ compatibility.

Phil Young — Tue, 22 Jan 2019 14:42:28 GMT

The use of extern "C" simply tells the compiler not to decorate the names of the functions so that the linker can recognize them, the default for C++ is that all function names are decorated with the types which would prevent linking the files.

extern "C" is essential but insufficient since there are many instances of incomplete type definitions in the function parameters, what this actually means is that C allows for the last parameter to a function to be an un-dimensioned array, which ultimately gets passed as a pointer.

C++ does not allow for this and sees it as an incomplete type definition, GCC allows it but the ARM compilers do not.

There is a switch that can be used with ARMCC, --gnu, to make it work in GCC compatible mode which enables support for this mode, but in doing so it defines __GNU_C as well as __CC_ARM_

in this mode the code will not compile using ARM compilers without editing the source since there are places in the code, particularly in the error logging, where having both of these defined results in incompatible redefinition of macros.

in summary there are 2 problems.

1. The use of arrays of undefined length it bad practice, that's why it was not allowed in C++, arrays are always passed by reference so a pointer is the preferred manner of passing arrays in both C and C++

2. The assumption that __CC_ARM_ and __GNU_C are mutually exclusive is not valid, in GCC __CC_ARM_ would never be defined, but in ARMCC they will both be defined when using --gnu

both of these would be trivial for Nordic to fix and would not affect the generated code in GCC or ARMCC, but would avoid the need to edit the nordic SDK when building a C++ application with ARMs compilers

for example

/** BLE Service data packets. */
typedef struct __attribute((packed))
{
uint16_t uuid; /**< UUID field. */
uint8_t data[]; /**< Service data field. */
} ble_ad_data_service_data_t;

..\..\..\..\mesh\core\include\packet.h(142): error: #70: incomplete type is not allowed

it would have been better to define it as

/** BLE Service data packets. */
typedef struct __attribute((packed))
{
uint16_t uuid; /**< UUID field. */
uint8_t *data; /**< Service data field. */
} ble_ad_data_service_data_t;

this has an identical meaning and is compatible with all compilers in both C and C++ modes.

RE: Can you make some small changes for C++ compatibility.

tesc — Tue, 22 Jan 2019 12:32:25 GMT

Hi,

I am trying to understand the issue here. Doesn't the use of 'extern "C"' throughout the SDK let you build the SDK using the C compiler still using the APIs from C++? Or can it not be bridged because of certain function headers? (Can you show me an example taken from the SDK of a function that is problematic?)

Regards,
Terje

RE: Can you make some small changes for C++ compatibility.

Phil Young — Mon, 21 Jan 2019 10:36:29 GMT

Thanks, interesting reading but they have not addressed any of the issues at Nordic.

I'm not asking them to write it in C++, simply to avoid using constructs that do not compile with the ISO/ANSI C++ compiler modes.

I've written all my embedded code in "C++" for over 20 years and can't understand why anybody would choose to start a new development in "C", but for me it's a bigger issue since I instantiate hundreds of instances of my code in a simulation environment for system level modelling and C++ provides the encapsulation to do that easily and efficiently ( and also produces significantly more efficient object code ).

The Nordic code is totally incompatible with this technique as it is not possible when using any globals as they cannot be distinguished between multiple instantiations of the device an a model.

one reason for the increased efficiency of C++ is that writing object oriented code makes you group data into objects that are related and operated on by the same functions thereby providing much better localization of data which greatly simplifies effective address calculation, i.e. the compiler gets to use a single pointer ( this, generally R0 ) with short immediate offsets for accessing data a lot more often and that reduces code size and increases execution efficiency significantly.

Look at any compiled code and the bulk of the instructions are for effective address computation when data is too far apart to be accessed in this manner.

Frankly the structure of the data in the Nordic code is really badly managed and inefficient but I can live with that provided I can write my code in C++.

RE: Can you make some small changes for C++ compatibility.

awneil — Mon, 21 Jan 2019 10:18:08 GMT

Have you seen this thread: https://devzone.nordicsemi.com/f/nordic-q-a/39234/why-isn-t-the-sdk-written-in-c ?