[Openexr-devel] UINT clashes with Windows MFC-ATL

[Yves Poissant]

Hi There,

I just spent a good deal of time trying to compile a plugin for the OpenEXR 
file format. I managed to take care of all the issues that poped up except 
for one. The UINT defined in the PixelType enum does clash with one line of 
code in the Microsoft Windows ATL library header files. Yes. One line of 
code. The whole rest of the code does not produce errors. I analysed the 
preprocessor output file to try to understand what is going on and frankly, 
I can't see. Actually, there is no apparent reason for the clash but it 
clashes anyway.

So in the end, I had to modify the ImfPixelType.h file and change the "UINT" 
in the enum to "EXR_UINT" and now it compiles fine.

The line of code that causes problems in ATL is VS7 cstringt.h line 2234 :
  UINT nID = LOWORD( reinterpret_cast< DWORD_PTR >( pv ) );
which expands to :
  UINT nID = ((WORD)((DWORD_PTR)( reinterpret_cast<DWORD_PTR>(pv)) & 
0xffff));

The error I get is C2872: "UINT" : Ambiguous symbol. Could be "unsigned int 
UINT" or "Imf::PixelType UINT"

All the Imfxxx.h files are included after all the other included files and 
the using namespace are set after all included files.

Any hint on how to resolve this ambiguity would be appreciated. I've tried 
several hypotheses without success so far.

In any event, I'd like to suggest that UINT, HALF and FLOAT should be 
changed to EXR_UINT, EXT_HALF and EXR_FLOAT to prevent any compiler 
confusion and improve portability. UINT and FLOAT are commonly used symbols 
and it seems that even with properly designed and set namespace, in some 
circumstances, there are still place for confusion.

Regards,
Yves Poissant