It seems that it would be fairly straight forward to define some
preprocessor macros that allow the exception specifications to be
spelled out in the appropriate ways based on the what __cplusplus is set to.
Thus, we can continue to support users of ilmbase according to their own
C++ language standard needs.
Even though the recent VFX Reference Platform specifications have been
specifying C++11 for a while (and C++14 for 2018), there may still be
facilities using third party applications dating to before that. And
there would be use cases that are entirely independent of the VFX
Reference Platform.
When updates to OpenEXR lead to files being written that cannot be read
by older versions of OpenEXR, we would want to avoid making any
unwarranted hindrances that would block downstream users from updating
to the newer OpenEXR.
On 08/12/17 11:20, Nick Rasmussen wrote:
It seems reasonable to me as well. Removing the dynamic exception
specifications would’t even break compatibility with older compilers.
-nick
On Thu, Aug 10, 2017 at 11:52 AM Piotr Stanczyk
<piotr.stanc...@gmail.com <mailto:piotr.stanc...@gmail.com>> wrote:
Sounds like a sensible plan to me.
Anyone from ILM care to comment on this? Can you foresee any
internal build issues?
Piotr
On Thu, Aug 10, 2017 at 11:40 AM Larry Gritz <l...@larrygritz.com
<mailto:l...@larrygritz.com>> wrote:
Any vendors that have bought into VFX Platform (Autodesk,
Foundry, SESI) should in theory have been on C++11 since last
year (and should be on board for C++14 for any products coming
in 2018).
We're only talking about moving forward, so a stray downstream
product stuck on C++03 can keep using OpenEXR <= 2.2.
I'll give it a couple days to see if there are objections
before I do any of the actual work. But it will be cleaner and
easier if we can just assume C++11 as a minimum.
-- lg
On Aug 10, 2017, at 11:12 AM, Piotr Stanczyk
<piotr.stanc...@gmail.com <mailto:piotr.stanc...@gmail.com>>
wrote:
Are there any vendors for whom this would cause an issue?
Else, I would vote for moving things forward
On 10 August 2017 at 10:18, Larry Gritz <l...@larrygritz.com
<mailto:l...@larrygritz.com>> wrote:
Ugh, so it's worse than I thought.
I suppose I'm willing to fix and submit a patch to
address this.
Do I need to put in the proper macros to make it compile
on everything from C++03 through 17? Does anybody want to
argue for continuing to maintain C++03 compatibility for
future OpenEXR releases, or is it finally time (six years
after the C++ standard and 2+ years after VFXPlatform) to
raise the floor to C++11?
-- lg
On Aug 9, 2017, at 11:38 PM, Werner Benger
<wer...@cct.lsu.edu <mailto:wer...@cct.lsu.edu>> wrote:
It should be noted that dynamic expressions are actually
forbidden in C++17, so OpenEXR does no longer compile
with GCC 7.1 when std C++17 is enabled. The highest C++
version that can be used to compile it is C++14, where
it's still just a warning, while in C++17 it's an error.
It would be good to have OpenEXR at least compilable in
C++17. Major C++ libraries such as QT are using C++11
nowadays, so it seems pretty safe to go beyond C++03 for
modern applications, a lot of things are indeed much easier.
Werner
On 10.08.2017 00:20, Larry Gritz wrote:
In a test compile with gcc 7, I get lots of errors of
the following ilk:
/home/travis/build/lgritz/openexr/IlmBase/Imath/ImathVec.h:228:34:
warning: dynamic exception specifications are
deprecated in C++11 [-Wdeprecated]
const Vec2 & normalizeExc () throw
(IEX_NAMESPACE::MathExc);
^~~~~
I can disable this particular warning, of course, but
it's worth noting that the OpenEXR code base is not
C++11 compliant. But in addition to using some C++03
idioms that are deprecated in C++11, perhaps more
importantly, the code is not taking advantage of new
features such as move semantics, constexpr, nothrow,
and others. For the Imath classes especially, using
some of these may actually confer a performance benefit.
I feel kind of bad pointing this out while not really
having the time at the moment to code up and submit an
actual patch myself, but I thought I'd at least open
the topic and see where the community stands on the
issue of how and when to upgrade to C++11 and if it's
important for modern OpenEXR to continue to support
C++03. For point of reference, the VFX Reference
Platform [http://www.vfxplatform.com/] dictated C++11
for 2016 and 2017, and will be C++14 for 2018.
-- lg
--
Larry Gritz
l...@larrygritz.com <mailto:l...@larrygritz.com>
_______________________________________________
Openexr-devel mailing list
Openexr-devel@nongnu.org <mailto:Openexr-devel@nongnu.org>
https://lists.nongnu.org/mailman/listinfo/openexr-devel
--
___________________________________________________________________________
Dr. Werner Benger Visualization Research
Center for Computation & Technology at Louisiana State
University (CCT/LSU)
2019 Digital Media Center, Baton Rouge, Louisiana 70803
Tel.: +1 225 578 4809 <tel:%28225%29%20578-4809>
Fax.: +1 225 578-5362
<tel:%28225%29%20578-5362>
_______________________________________________
Openexr-devel mailing list
Openexr-devel@nongnu.org <mailto:Openexr-devel@nongnu.org>
https://lists.nongnu.org/mailman/listinfo/openexr-devel
--
Larry Gritz
l...@larrygritz.com <mailto:l...@larrygritz.com>
_______________________________________________
Openexr-devel mailing list
Openexr-devel@nongnu.org <mailto:Openexr-devel@nongnu.org>
https://lists.nongnu.org/mailman/listinfo/openexr-devel
--
Larry Gritz
l...@larrygritz.com <mailto:l...@larrygritz.com>
_______________________________________________
Openexr-devel mailing list
Openexr-devel@nongnu.org <mailto:Openexr-devel@nongnu.org>
https://lists.nongnu.org/mailman/listinfo/openexr-devel
_______________________________________________
Openexr-devel mailing list
Openexr-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/openexr-devel
_______________________________________________
Openexr-devel mailing list
Openexr-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/openexr-devel
