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

[Paul Schneider]

Hi, Yves,

I realized that since the MFC code in question is a macro, it gets instantiated 
well within 
your C file, so adding your "using" declaration after the #includes won't work.

What you could do is something like this instead:

using Imf::RgbaInputFile;
using Imf::RgbaOutputFile;
// using whatever EXR classes you would like to import

You could also "scope" your using declarations:

void func1()
{
   using namespace Imf;
   RgbaInputfile blah;
}

void func2()
{
   using namespace Imf;
   RgbaInputfile blah;
}

void func3()
{
   CALL_UNSAFE_MFC_MACRO();
   Imf::RgbaInputfile blah;
}

void func4()
{
   CALL_UNSAFE_MFC_MACRO();
   {
       using namespace Imf;
       RgbaInputFile blah;
   }
}

etc, etc.

Hopefully you can use some combination of those techniques to keep your code 
simple and
painless (for you :) ).  Sorry about the hassle.

- Paul

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

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