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

[Paul Schneider]

Hi, Yves,

I don't have a Windows development machine to test this with, but it sounds 
like somewhere in the MFC headers there's something like this:

typedef unsigned int UINT;

and later when a UINT is declared, the compiler doesn't know which definition 
you mean.

Since the EXR definition is protected in a namespace, I wonder if you have

using namespace Imf;

somewhere in your code, before the offending header file is included.  This 
would promote the EXR definition of UINT into the global namespace, and cause a 
conflict with the MFC definition (already in the global namespace).

Check that and see if that's the problem.  All of the EXR library definitions 
(except half) are protected by namespaces, in the hopes that awkward naming 
schemes such as you propose won't be necessary.

- Paul

 
On Tuesday, December 28, 2004, at 06:45PM, Yves Poissant <address@hidden> wrote:

>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 
>
>
>
>_______________________________________________
>Openexr-devel mailing list
>address@hidden
>http://lists.nongnu.org/mailman/listinfo/openexr-devel
>
>