meganz/mingw-std-threads

Problem with mutex.h

Closed this issue · 3 comments

Jamaika1 commented

I don't know how to describe it. I mean that some programs don't tolerate <windows.h> and thus are incompatible with some typedef functions of the HALF, FLOAT or some cann't tolerate at all. Is there any idea to bypass this problem?
Recently, I have a problem compiling a new codec VVC with WPP PARALLEISM functions.
https://vcgit.hhi.fraunhofer.de/jvet/VVCSoftware_VTM
msg((MsgLevel) ERROR

nmcclatchey commented

Short answer: Maybe.

Long answer:
The Windows headers define many macros, which is undesired in C++ because they are unscoped. The library currently includes the entire windows.h header, which includes every such macro. With care, replacing windows.h with more specific headers (eg. syncapi.h) should be possible, but that may not completely avoid the undesirable macros.
Taking it a step further, it may be possible to eschew the Windows headers completely (solving the problem), but abandoning a supplier-provided API is generally considered to be unwise.

  • 👍1
Jamaika1 commented

Thanks for the answer
Update works. :)

nmcclatchey commented

Generally, avoiding naming conflicts is the right thing to do. Your approach is viable, as would be placing your enum in a namespace.

Generally, following the naming conventions from a style guide is good practice. It doesn't completely isolate you from problems (eg. the Windows API uses macros to fake argument-dependent lookup in C), but it can massively reduce the rate at which you encounter such problems. For example, reserving ALL_CAPS_NAMES for preprocessor macros will avoid many problems with older APIs.