RE: [Openexr-devel] Hither and Yon in Imath::Frustum

[Dan Wexler]

I agree that it would be improper to break the API before a major number
version change to IlmBase.  Is there an active 2.x branch?

One alternative is to redefine near and far at the bottom of this file,
and provide analogous Frustum::hither() and Frustum::yon() functions.
This fixes the include ordering problem and allows windows (and other)
developers to migrate their code before the 2.x API change.

I've attached a version of ImathFrustum.h with this change with these
changes that fix the include ordering and provide alternative hither/yon
functions.  I did a bit of searching through the windows headers and it
really does seem like windef.h simply defines near and far as empty, but
I'm not 100% confident of that change even though my app works (only
basic testing so far).

If we get really tricky, we can mark the Frustum::near() and
Frustum::far() functions as deprecated to generate a compiler warning,
which makes it easy to change your code without breaking anything in the
near term.  I'm not positive how to make that work since these are
inlined functions (Visual Studio has a #pragma deprecated, but I
couldn't get it to work in this case).

IMHO, this change is worthwhile in the long run.  It broadens the
potential user base significantly.  For example, if we ever wanted to
propose various portions of OpenEXR for inclusion with boost, or
eventually a future C++ standard, we would need to fix this near/far
issue.


> -----Original Message-----
> From: Florian Kainz [mailto:address@hidden
> Sent: Wednesday, May 28, 2008 2:24 PM
> To: Dan Wexler
> Cc: address@hidden
> Subject: Re: [Openexr-devel] Hither and Yon in Imath::Frustum
> 
> This change would affect all existing software that
> uses Imath::Frustum, including ILM's internal code...
> 
> Dan Wexler wrote:
> > Greetings from a new mailing list subscriber, but long time library
> user,
> >
> > The ImathFrustum.h header does a #undef on the "near" and "far"
> > abominations in the windows.h headers.  The implication is that you
> must
> > include ImathFrustum.h after including any Windows DX headers.  Yes,
> > Windows sucks, but the current #undef solution is not great either.
> >
> > Why not use hither/yon instead of near/far in ImathFrustum.h and in
> the
> > associated code files?
> >
> > Not only does this fix the problem elegantly, but it makes searching
> the
> > code easier, since hither/yon are more unique than near/far.  I'd be
> > willing to make and test out this change if folks agree that it is
> > worthwhile.
> >
> >
> > Dan Wexler
> >
> >
---------------------------------------------------------------------
> ---
> > This email message is for the sole use of the intended recipient(s)
> and
> > may contain confidential information.  Any unauthorized review, use,
> > disclosure or distribution is prohibited.  If you are not the
> intended
> > recipient, please contact the sender by reply email and destroy all
> > copies of the original message.
> >
---------------------------------------------------------------------
> ---
> >
> >
> >
---------------------------------------------------------------------
> ---
> >
> > _______________________________________________
> > Openexr-devel mailing list
> > address@hidden
> > http://lists.nongnu.org/mailman/listinfo/openexr-devel

ImathFrustum.h
Description: ImathFrustum.h