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

[Yves Poissant]

Hi Paul,

Thank you for your reply.

Here is the include files order and namespace declaration:
------------------------------------------
#include "stdafx.h"
#include "SDK/HBitmap.h"
#include "Custom.h"
#include "IOApp.h"
#include "Flip.h"
#include "Files.h"
#include <io.h>
#include <fcntl.h>

#undef min
#undef max
#undef ASSERT
#undef THROW

#include <ImfInputFile.h>
#include <ImfChannelList.h>
#include <ImfVersion.h>

using namespace std;
using namespace Imf;
using namespace Imath;
------------------------------------------
Then starts the code. No other includes after that.

Also, you are correct about MFC headers declaring this:
  typedef unsigned int UINT;
And UINT is very commonly used in regular Windows applications as well as 
MFC based applications because of that. In fact there is even a :
  typedef float FLOAT;

However the FLOAT and most of the UINT does not cause a clash. As I 
mentionned, only one use of UINT in the MFC-ATL code does cause a clash. And 
what is more disturbing is that, as you can see from the clip I included 
here, the Imfxxx.h files are really included after the mfc include files. 
Yet, the clash happens in MFC even though the Imf was not yet reached. That 
is very strange. Looks to me like the compiler is confused in the second 
pass.

And everywhere I needed to use UINT as PixelType, I had to explicitly 
specify the namespace as in Imf::UINT.

So Currently, the way I decided to solve this clashing problem is to remove 
the "using namespace Imf" from the plugin source code and to always use 
explicit namespacing as in
 const Imf::Channels &channel = i.Channel();
This compiles fine and works very well although it is by itself quite 
awkward. But it does not necessitate that I modify the OpenEXR header files 
which would cause other problems later when the files gets updated.

I fully agree with you that awkward naming like the one I propose shouldn't 
be necessary and I hope I can find a more elegant solution to this clash 
with your help and those who know on this list. However, if no solution 
exist, it is probably less awkward to use something like EXR_UINT than to be 
forced to use Imf:: everywhere, which would defeat the purpose of using the 
otherwise well thought out namespacing. The real problem may be in the 
Microsoft source file. Could it be that "reinterpret_cast" is causing the 
confusion? Whatever. If the problem is in the Microsoft file, there is 
little we can do about it but adapt ;-)

Also, note that I'm am in no way a namespace wizzard. I know the basics of 
namespace and how to use namespaces but if there is some namespace wizardry 
that can solve this issue, then I'm not aware of it.

Thanks,
Yves Poissant

----- Original Message ----- 
From: "Paul Schneider" <address@hidden>
To: "Yves Poissant" <address@hidden>
Cc: <address@hidden>
Sent: Tuesday, December 28, 2004 9:57 PM
Subject: Re: [Openexr-devel] UINT clashes with Windows MFC-ATL



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