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

[E. Scott Larsen]

Perhaps you could ask Microsoft to change their MFC code?
That might work ;)

If my intrusion may be pardoned...

<History Lesson >
Namespaces were designed primarily for the purpose of solving this exact
problem.  They were well designed and truly solved the problem, with the
benefit of not incurring any overhead even!

The namespace mechanism was perfect at one time except for two little
complaints: 1) there happen to be a reasonable number of lazy programmers
out there, and 2) namespaces often are unneccessary (when there are no
clashes).

As a token of friendship to lazy people, the syntax "using
namespace XXX;"  was added.
</History Lesson >

Notes:

Good News: You've already discovered one of the proper ways to use the
namespace mechanism to solve your problem (and the problem that it was
designed to solve); there are other ways too.  Enjoy discovering a few!

Good News: If you really like typing EXR_ instead of Imf:: then you can
use a macro, e.g. #define.  One of the reasons for macros are lazy people.
Of course you're not one of these and you are also smart enough to know
their dangers.  Another option is an editor shortcut, if you use a good
enough editor that is.

Good News: You can change your own local copy of the code, then you'll be
happy and the rest of the universe won't have to change their universes.

Bad News) there's more than 2 people using OpenEXR already (even more than
20, probably more than 2k).  It's actually a tad bit rude to ask them all
to change all of their code that they've been using for some time now (and
that is certainly more lines than yours) just so that your fingers can
have the joy of typing in all caps.

Sorry about that.  I'm certainly not one of the guiding forces in the
OpenEXR land (though I use it a lot), so perhaps you can still hope and
pray (or whatever your preference is) that they will all jump up and bend
over backwards for you.  But I'd expect not.  The problem is already
well solved, as you've found.

Curiousity: why do you find EXR_UINT less akward than Imf::UINT?

//Scott

On Wed, 29 Dec 2004, Yves Poissant 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
>