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