Observed result or behaviour:
There is a compile-time conflict between this library and Apache Arrow. This is due to the macro definition for ENUM in iceoryx_binding_c/include/iceoryx_binding_c/internal/c2cpp_binding.h. In the Apache Arrow library, there is a header that has ENUM as a value in one of their enums (see arrow/cpp/src/parquet/types.h line 78). If c2cpp_binding.h from this library is included before the other, then we either need to include an #undef ENUM before including the next header or else run into a compile-time error.
Expected result or behaviour:
I expect if you define macros in a public header that it's a unique enough name that it will not conflict with user code or with other third-party code.
Conditions where it occurred / Performed steps:
#include <iceoryx_binding_c/types.h>
#include <parquet/types.h>
int main() {
return 0;
}
It is fixed by either reordering includes
#include <parquet/types.h>
#include <iceoryx_binding_c/types.h>
int main() {
return 0;
}
Both of these solutions on the user side are unsatisfactory. It would be really nice if the macros had more specific names such as ICEORYX_ENUM and ICEORYX_CLASS to avoid name clashes.
Required information
Operating system: Ubuntu 20.04 LTS
Compiler version: GCC 12.2.0
Eclipse iceoryx version: v2.90.0
Observed result or behaviour: There is a compile-time conflict between this library and Apache Arrow. This is due to the macro definition for
ENUM
iniceoryx_binding_c/include/iceoryx_binding_c/internal/c2cpp_binding.h
. In the Apache Arrow library, there is a header that hasENUM
as a value in one of their enums (see arrow/cpp/src/parquet/types.h line 78). Ifc2cpp_binding.h
from this library is included before the other, then we either need to include an#undef ENUM
before including the next header or else run into a compile-time error.Expected result or behaviour: I expect if you define macros in a public header that it's a unique enough name that it will not conflict with user code or with other third-party code.
Conditions where it occurred / Performed steps:
It is fixed by either reordering includes
or by undefining the
ENUM
macro after the includeBoth of these solutions on the user side are unsatisfactory. It would be really nice if the macros had more specific names such as
ICEORYX_ENUM
andICEORYX_CLASS
to avoid name clashes.