cxx::Expects macro conflicts with Microsoft GSL Expects macro

[gpalmer-latai]

Required information

When compiling a C++ library that depends transitively both on iceoryx_hoofs/cxx/requires.hpp and <gsl/gsl_assert>, and iceoryxlibraries are included after gsl ones, the following error message will result:

external/iceoryx/iceoryx_hoofs/vocabulary/include/iox/not_null.hpp:35:14: error: expected unqualified-id
        cxx::Expects(t != nullptr);
             ^
external/gsl/include/gsl/gsl_assert:170:23: note: expanded from macro 'Expects'
#define Expects(cond) GSL_CONTRACT_CHECK("Precondition", cond)
                      ^
external/gsl/include/gsl/gsl_assert:162:5: note: expanded from macro 'GSL_CONTRACT_CHECK'
    (GSL_LIKELY(cond) ? static_cast<void>(0) : gsl::details::terminate())

Operating system:
Ubuntu 20.04 LTS

Compiler version:
GCC 9.4.0

Eclipse iceoryx version:
Slightly out of date master (just a few commits)

Observed result or behaviour:
Code fails to compile because GSL calls the Expects macro expecting it to be the one that gsl defined, but it is not because that macro has been overwritten by the one in iceoryx.

Expected result or behaviour:
Somehow, there is no conflict and code is able to depend both on gsl and iceoryx.

The only solution within this project I could think of is to name Expects to something less duplicatable in Iceoryx - like IOX_EXPECTS. Curious what folks' thoughts about this are.

Obviously I'm aware that I have solutions in my use case to either not depend on gsl (because hoofs covers mostly the same use cases) or be careful about how/where I import things.

Conditions where it occurred / Performed steps:

#include <gsl/gsl_util>
#include <iox/not_null.hpp>
...
// Some utility that does index checking and has a special overload for their flavor of span.
// It calls their version of Expects internally.
gsl::at(...);

[gpalmer-latai]

Just wanted to add another note here - there are other third party libraries as well that themselves depend on GSL so... 🙁

[elBoberido]

@gpalmer-latai this is one of our early sins when we did not prefix our macros. The long term plan is to move to the macros defined in error_reporting_macros.hpp. We need to refactor quite a lot of tests for this though, so in the short term might indeed be better to just add the prefix

[gpalmer-latai]

So in other words you would be fine with changing all occurrences of Expects with IOX_EXPECTS (ditto for Ensures)?

I suppose it will look weird to see iox::cxx::IOX_EXPECTS. Then again, I'm quite surprised and it is new knowledge to me that namespaces and macros combine in such a sneaky way.

[elBoberido]

Sure. We need to prefix all macros with the IOX prefix else we get exactly the problem you described. I'm surprised the issues is reported only now.

Yes it will be just IOX_EXPECTS. The trick with macros and namespaces is simple.

namespace foo {
    void bar() {}
}

#define BAR() bar()

int main() {
    foo::BAR();
}

The macro itself is not namespaced but the namespace must be added in order to use it. It is against the autosar guidelines though ... for good reasons.

[elBoberido]

Luckily it is a simple search and replace and therefore easy to fix

[gpalmer-latai]

Thanks for taking care of this already!