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

[E. Scott Larsen]

I realized after I sent that post that it probably came across much
harsher than I intended, sorry about that.  I also noticed later that you
said you weren't a wizard at namespaces, which suggests I should have
responded with a useful tutorial on them instead of what I said.  Again,
sorry.  It looks like someone else replied with a few more helpful tips,
reference that.

The whole purpose of namespaces is to solve this very problem.  The "using
namespace XXX;" syntax is a backdoor for when they are not needed.  There
are many places in industry that I've worked that explicitly do not allow
that syntax; many folks would say that it is bad usage.  That said, it's
certianly the most common usage and is likely the most commonly
recommended.  It's perfectly fine usage when there are no collisions.
But, collissions do eventually happen with every bit of code that finds
widespread use, as both OpenEXR and MFC have.  Proper usage of namespaces
is by far the cleanest, most compatable, and most portable solution (not
to mention the smartest, the ....).  The "using namespace XXX;" syntax
completely defeats the purpose of namespaces.  You've found a place where
a collision occurs.  Collisions were foreseen by the language
constructors, and the mechanism for dealing with them is namespaces.  So
learn how to use namespaces properly and your collision will go away.
That's all I was trying to say.

A few comments inline...

On Wed, 29 Dec 2004, Yves Poissant wrote:

> As you can guess, asking Microsoft to change their MFC code is not a
> practical solution. Beside, the MFC source is pretty well in respect of
> namespaces except for one single line of code in their whole headings.

We'll not go into a discussion about MFC code and their compliance with
namespaces or any other C++ aspect.  Suffice it to say: it's very bad.

> You are right that there are several people already using OpenEXR and if
> only because of that, it is not very realistic from my part to expect a
> change in the OpenEXR source. However, I read in the archives that the
> owners of OpenEXR were interested in hearing about any portability or
> incompatibility issues. I just reported one. And instead of just critiquing,
> I suggested a solution.

I was just saying that it's actually not a portability or incompatability
issue.  It's actually working as it should (in fact, it's got more
compatability and portability as it stands; you suggestion would not solve
the real problem: namespaces solve the real problem).

> You don't seem to like the solution but I don't
> think I was "rude" at all. There might not be a load of people using OpenEXR
> with MFC right now but as OpenEXR becomes more popular, this situation will
> inevitably change. At least, this behavior could be documented if not
> changed.

Yes, broader and better education about namespaces and how to use them
correctly would be good.

> > Curiousity: why do you find EXR_UINT less akward than Imf::UINT?
>
> Because Imf:: needs to be added in front of *every* symbols defined inside
> the Imf namespace not only in front of UINT, FLOAT and HALF.

but one day, there'll be a collision with some other symbol, then
someone'll ask to have that one changed, then ... and finally one day,
someone'll have code with an EXR_UINT in it that collides. The solution is
proper usage of namespaces.

> > I'm certainly not one of the guiding forces in the OpenEXR land
>
> I see. Thanks for this precision. And thanks for your Oh so helpfull post.

Hopefully this one was more helpful.  Sorry about that last one.  Find
some information on namespaces and you'll see that this is user error.
Yes, everyone could help provide more education to prevent confusion, but
that's the world we live in.

//Scott

>
> Yves Poissant
>
> ----- Original Message -----
> From: "E. Scott Larsen" <address@hidden>
> To: "Yves Poissant" <address@hidden>
> Cc: <address@hidden>
> Sent: Wednesday, December 29, 2004 12:28 PM
> Subject: Re: [Openexr-devel] UINT clashes with Windows MFC-ATL
>
>
> 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
> >
>
>
>
> _______________________________________________
> Openexr-devel mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/openexr-devel
>