Open a-zw opened 3 days ago
There are other instance of suppressing restrict
and __restrict
but I don't know why, so naively removing it is probably not the solution?
@a-zw I couldn't agree more, that #define restrict
should not be there. It is kinda of safe to just remove all occurrences of restrict
/__restrict
from the sources, and at least for the API that would probably be a good plan. Then Cyclone can internally still do whatever.
Consistently using __restrict
and defining that away could also be an option. Or just defining dds_restrict
as restrict
/ nothing, depending on whether it is C or C++, and using that throughout.
I need to have a better look before making up my mind ...
https://github.com/eclipse-cyclonedds/cyclonedds/blob/d8cef891b9a27cc7bc52477e1c7b2c3f8edf81ba/src/core/ddsc/include/dds/dds.h#L29
Since
restrict
is a valid C++ identifier, a macro should not make it disappear. It can lead to unnecessary errors in user code.Example:
Workaround is simple: Just rename the variable.