NotImplemented macro conflicts with OpenVINO

Summary

A user on StackOverflow reported compilation errors when including both OpenFOAM and OpenVINO in one project. The root cause turned out to be OpenFOAM's NotImplemented macro, which conflicts with an exception class defined in OpenVINO.

Steps to reproduce

Include the OpenVINO headers after the OpenFOAM headers in an skeleton C++ file.

Example case

What is the current bug behaviour?

Lots of compile errors.

What is the expected correct behavior?

No compile errors.

Relevant logs and/or images

/opt/OpenFOAM/OpenFOAM-4.1/src/OpenFOAM/lnInclude/error.H:316:13: error: ‘FatalError’ in namespace ‘Foam’ does not name a type
     ::Foam::FatalError((functionName), __FILE__, __LINE__)
             ^
/opt/OpenFOAM/OpenFOAM-4.1/src/OpenFOAM/lnInclude/error.H:358:5: note: in expansion of macro ‘FatalErrorIn’
     FatalErrorIn(functionName)                                                 \
     ^
/opt/OpenFOAM/OpenFOAM-4.1/src/OpenFOAM/lnInclude/error.H:367:24: note: in expansion of macro ‘notImplemented’
 #define NotImplemented notImplemented(FUNCTION_NAME)
                        ^
/opt/intel_openvino/openvino/inference_engine/include/ie_common.h:210:7: note: in expansion of macro ‘NotImplemented’
 class NotImplemented : public std::logic_error
       ^
/opt/intel_openvino/openvino/inference_engine/include/details/ie_exception_conversion.hpp:60:55: warning: statement has no effect [-Wunused-value]
         case NOT_IMPLEMENTED:throw NotImplemented(msg);
                                                       ^
make: *** [Make/linux64GccDPInt64Opt/tabulatedCombustionModel/FPVANNModel/FPVANNModel.o] Error 1

Environment information

I am not the submitter of the StackOverflow issue so I do not know the environment. This behavior should be reproducible across all distributions.

• OpenFOAM version :
• Operating system :
• Hardware info :
• Compiler :

Possible fixes

src/OpenFOAM/lnInclude/error.H line 367 defines a macro that should not be visible outside of the public OpenFOAM headers.

## Reattaching the author to the issue ticket: @Botje ##

changed the description

The fastest fix will be to follow the stackoverflow suggestions.

• either include openvino first
• or undefine to avoid the conflict. Until now, the only other known conflict was with windows:

  #undef DebugInfo    // Windows name clash with OpenFOAM messageStream

Macros are naturally fraught with this type of problem. If we rename, we might get a conflict elsewhere (unlikely, but you know what I mean). Could prefix all macros with and have FoamNotImplemented, but doesn't read particularly well.

Any suggestions about an intrinsic C++ means to get out of this?

assigned to @mark

Is it an option to restrict use of the macro to .cpp files? Then you can shift the macro definition to an internal header, only used by those.

By Botje on 2019-07-12T13:02:45 (imported from GitLab project)

## Reattaching the author to the issue ticket: @Botje ##

Hi @Botje - just noticed that you were probably still waiting for a response. The simple answer is that it's not really possible to shift these definitions to cpp files only. We use then in a few places as runtime equivalents of pure virtual methods (without needing a virtual class) and thus are used either in the header boilerplate or in inline definitions. Both of these necessitate having the definitions in headers.

The only really sane answer is to undefine them before include the openvino headers.

/mark

changed the description

Closing ticket - please re-open if still relevant

closed