[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Yves Poissant
Subject: [Openexr-devel] UINT clashes with Windows MFC-ATL
Date: Tue, 28 Dec 2004 21:44:43 -0500

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.

Yves Poissant

reply via email to

[Prev in Thread] Current Thread [Next in Thread]