This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

NRF_MESH_STATIC_ASSERT not compatible with C++

Using: NRF52832, SD 132 6.1.1, SDK 15.3.0, Mesh SDK 3.1.0.

Hi, I included mesh_opt_core.h in a C++ file, and got compiler errors at NRF_MESH_STATIC_ASSERT().

I fixed this by defining NRF_MESH_STATIC_ASSERT as:

#define NRF_MESH_STATIC_ASSERT(cond) typedef char nrf_mesh_static_assert[(cond) ? 1 : -1]

since static_assert is already defined by C++.

Parents
  • Moreover, gcc itself has static_assert since 4.3: https://gcc.gnu.org/projects/cxx-status.html#cxx11

    I don't know when it entered the gcc arm cross compiler, but it's not just limited to C++.

    The reason that

    #define NRF_MESH_STATIC_ASSERT(cond) typedef char static_assert[(cond) ? 1 : -1]

    works as intended (when the condition is false), is by defining a variable "static_assert" which tries to create an array "static_assert[-1]" that is invalid at compile time (because of the negative length). The only thing you do not want is that this variable name collides with any known function. So definitely do not call it static_assert. Indeed, nrf_mesh_static_assert like Bart proposes is fine, but it can be anything.

    I would perhaps propose to name it "static_assert_variable" to prevent clashing with anything that sounds like it also could be a function name.

Reply
  • Moreover, gcc itself has static_assert since 4.3: https://gcc.gnu.org/projects/cxx-status.html#cxx11

    I don't know when it entered the gcc arm cross compiler, but it's not just limited to C++.

    The reason that

    #define NRF_MESH_STATIC_ASSERT(cond) typedef char static_assert[(cond) ? 1 : -1]

    works as intended (when the condition is false), is by defining a variable "static_assert" which tries to create an array "static_assert[-1]" that is invalid at compile time (because of the negative length). The only thing you do not want is that this variable name collides with any known function. So definitely do not call it static_assert. Indeed, nrf_mesh_static_assert like Bart proposes is fine, but it can be anything.

    I would perhaps propose to name it "static_assert_variable" to prevent clashing with anything that sounds like it also could be a function name.

Children
No Data
Related