search

meganz / mingw-std-threads

Standard threads implementation currently still missing on MinGW GCC on Windows
BSD 2-Clause "Simplified" License
439 stars 137 forks source link

Problem with mutex.h #54

Closed Jamaika1 closed 5 years ago

Jamaika1 commented 5 years ago

I don't know how to describe it. I mean that some programs don't tolerate 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 5 years ago

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.

Jamaika1 commented 5 years ago

Thanks for the answer Update works. :)

nmcclatchey commented 5 years ago

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.