Re: [Openexr-devel] C++11, 'throw', etc.

2017-08-14 Thread Richard Addison-Wood 
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 
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 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
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 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
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

Re: [Openexr-devel] C++11, 'throw', etc.

2017-08-12 Thread Nick Rasmussen 
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 
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  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 
>> 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  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  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
>>>
>>>
>>>
>>>
>>>
>>> ___
>>> Openexr-devel mailing list
>>> Openexr-devel@nongnu.org
>>> https://lists.nongnu.org/mailman/listinfo/openexr-devel
>>>
>>>
>>> --
>>>
>>> ___
>>> Dr. Werner BengerVisualization Research
>>> Center for Computation & Technology at Louisiana State University
>>> (CCT/LSU)
>>> 2019  Digital Media Center, Baton Rouge, Louisiana 70803
>>> Tel.: +1 225 578 4809 <(225)%20578-4809>Fax.: +1
>>> 225 578-5362 <(225)%20578-5362>
>>>
>>>
>>> ___
>>> Openexr-devel mailing list
>>> Openexr-devel@nongnu.org
>>> https://lists.nongnu.org/mailman/listinfo/openexr-devel
>>>
>>>
>>> --
>>> Larry Gritz
>>> l...@larrygritz.com
>>>
>>>
>>>
>>>
>>>
>>> ___
>>> Openexr-devel mailing list
>>> Openexr-devel@nongnu.org
>>> https://lists.nongnu.org/mailman/listinfo/openexr-devel
>>>
>>>
>>
>> --
>> Larry Gritz
>> l...@larrygritz.com
>>
>>
>>
>>
>> ___
> Openexr-devel mailing list
> Openexr-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/openexr-devel
>
___
Openexr-

Re: [Openexr-devel] C++11, 'throw', etc.

2017-08-11 Thread Phil Barrett 
On Thu, 10 Aug 2017 23:47:02 +0100, Deke Kincaid   
wrote:


I don't think it would hurt.  Everyone is mostly on 2.2 now.  
The only places I could see possible issues are places which are always  
really far behind and do not follow >VFXPlatform, ie Adobe and any DI  
products such as Blackmagic Resolve, Scratch, Baselight where they care  
less about >fitting into the pipeline.


True. Baselight is using 2.2 but we're not on C++11 yet; it'll hopefully  
happen by the end of this year. We're happy to stick with older source  
until then.


Phil
--
Phil Barrett
FilmLight___
Openexr-devel mailing list
Openexr-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/openexr-devel

Re: [Openexr-devel] C++11, 'throw', etc.

2017-08-10 Thread Deke Kincaid 
Yes, Brendan's (my mistake, not Brent) ProEXR plugin now ships with many
Adobe products.

http://fnordware.blogspot.com/2015/12/openexr-for-premiere-is-free.html

On Thu, Aug 10, 2017 at 3:58 PM, Joseph Goldstone 
wrote:

> Adobe must have updated to at lest 1.7 in the last year because they now
> support attribute names with lengths > 31. If it gets to where we need to
> ask them a question I have some email addresses from discussions we had, in
> getting them to that point.
>
> On Aug 10, 2017, at 3:47 PM, Deke Kincaid  wrote:
>
>
> Though Adobe now includes Brent's ProEXR plugin so everything might be
> just fine.  They were still on EXR 1.0 up until a year ago.
>
>
>
> This message is confidential. It may also be privileged or otherwise
> protected by work product immunity or other legal rules. If you have
> received it by mistake, please let us know by e-mail reply and delete it
> from your system; you may not copy this message or disclose its contents to
> anyone. Please send us by fax any message containing deadlines as incoming
> e-mails are not screened for response deadlines. The integrity and security
> of this message cannot be guaranteed on the Internet.
>
>
> --
> This email has been scanned for email related threats and delivered safely
> by Mimecast.
> For more information please visit http://www.mimecast.com
> --
>
___
Openexr-devel mailing list
Openexr-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/openexr-devel

Re: [Openexr-devel] C++11, 'throw', etc.

2017-08-10 Thread Joseph Goldstone 
Adobe must have updated to at lest 1.7 in the last year because they now 
support attribute names with lengths > 31. If it gets to where we need to ask 
them a question I have some email addresses from discussions we had, in getting 
them to that point.

On Aug 10, 2017, at 3:47 PM, Deke Kincaid 
mailto:dekekinc...@gmail.com>> wrote:


Though Adobe now includes Brent's ProEXR plugin so everything might be just 
fine.  They were still on EXR 1.0 up until a year ago.



This message is confidential. It may also be privileged or otherwise protected 
by work product immunity or other legal rules. If you have received it by 
mistake, please let us know by e-mail reply and delete it from your system; you 
may not copy this message or disclose its contents to anyone. Please send us by 
fax any message containing deadlines as incoming e-mails are not screened for 
response deadlines. The integrity and security of this message cannot be 
guaranteed on the Internet.
---
 This email has been scanned for email related threats and delivered safely by 
Mimecast.
 For more information please visit http://www.mimecast.com
---
___
Openexr-devel mailing list
Openexr-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/openexr-devel

Re: [Openexr-devel] C++11, 'throw', etc.

2017-08-10 Thread Deke Kincaid 
I don't think it would hurt.  Everyone is mostly on 2.2 now.

The only places I could see possible issues are places which are always
really far behind and do not follow VFXPlatform, ie Adobe and any DI
products such as Blackmagic Resolve, Scratch, Baselight where they care
less about fitting into the pipeline.

Though Adobe now includes Brent's ProEXR plugin so everything might be just
fine.  They were still on EXR 1.0 up until a year ago.

On Thu, Aug 10, 2017 at 12:49 PM, Larry Gritz  wrote:

> Do you think it's likely that any app that is farther behind is also
> locked off on particular versions of external libraries like OpenEXR, so
> would not be hurt by future releases of those libraries requiring C++11?
>
>
> On Aug 10, 2017, at 12:41 PM, Deke Kincaid  wrote:
>
> Nuke 11, Maya 2017 and Houdini 16 or 16.5? (I forget which) are now C++11
> I believe.  I think a few applications are still a bit behind (rv, Mari,
> Katana) but there are plans for that to be rectified in the near-ish future.
>
> On Thu, Aug 10, 2017 at 11:52 AM, Piotr Stanczyk  > 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  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 
>>> 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  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  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





 ___
 Openexr-devel mailing list
 Openexr-devel@nongnu.org
 https://lists.nongnu.org/mailman/listinfo/openexr-devel


 --
 
 ___
 Dr. Werner BengerVisualization Resear

Re: [Openexr-devel] C++11, 'throw', etc.

2017-08-10 Thread Larry Gritz 
Do you think it's likely that any app that is farther behind is also locked off 
on particular versions of external libraries like OpenEXR, so would not be hurt 
by future releases of those libraries requiring C++11?


> On Aug 10, 2017, at 12:41 PM, Deke Kincaid  wrote:
> 
> Nuke 11, Maya 2017 and Houdini 16 or 16.5? (I forget which) are now C++11 I 
> believe.  I think a few applications are still a bit behind (rv, Mari, 
> Katana) but there are plans for that to be rectified in the near-ish future.
> 
> On Thu, Aug 10, 2017 at 11:52 AM, Piotr Stanczyk  > 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  > 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 > > 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 > > 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 >> > 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 
 
 
 
 
 
 ___
 Openexr-devel mailing list
 Openexr-devel@nongnu.org 
 https://lists.nongnu.org/mailman/listinfo/openexr-devel 
 
>>> 
>>> -- 
>>> ___
>>> Dr. Werner BengerVisualization Research
>>> Center for Computation & Technology at Louisiana State University (CCT/LSU)
>>> 2019  Digital Media Center, Baton Rouge, Louisiana 70803
>>> Tel.: +1 225 578 4809 Fax.: 
>>> +1 225 578-5362 
>

Re: [Openexr-devel] C++11, 'throw', etc.

2017-08-10 Thread Deke Kincaid 
Nuke 11, Maya 2017 and Houdini 16 or 16.5? (I forget which) are now C++11 I
believe.  I think a few applications are still a bit behind (rv, Mari,
Katana) but there are plans for that to be rectified in the near-ish future.

On Thu, Aug 10, 2017 at 11:52 AM, Piotr Stanczyk 
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  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 
>> 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  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  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
>>>
>>>
>>>
>>>
>>>
>>> ___
>>> Openexr-devel mailing list
>>> Openexr-devel@nongnu.org
>>> https://lists.nongnu.org/mailman/listinfo/openexr-devel
>>>
>>>
>>> --
>>> 
>>> ___
>>> Dr. Werner BengerVisualization Research
>>> Center for Computation & Technology at Louisiana State University
>>> (CCT/LSU)
>>> 2019  Digital Media Center, Baton Rouge, Louisiana 70803
>>> Tel.: +1 225 578 4809 <(225)%20578-4809>Fax.: +1
>>> 225 578-5362 <(225)%20578-5362>
>>>
>>>
>>> ___
>>> Openexr-devel mailing list
>>> Openexr-devel@nongnu.org
>>> https://lists.nongnu.org/mailman/listinfo/openexr-devel
>>>
>>>
>>> --
>>> Larry Gritz
>>> l...@larrygritz.com
>>>
>>>
>>>
>>>
>>>
>>> ___
>>> Openexr-devel mailing list
>>> Openexr-devel@nongnu.org
>>> https://lists.nongnu.org/mailman/listinfo/openexr-devel
>>>
>>>
>>
>> --
>> Larry Gritz
>> l...@larrygritz.com
>>
>>
>>
>>
>>
> ___
> Openexr-devel mailing list
> Openexr-devel@nongnu.org
> https://lists.nongnu.org/mailm

Re: [Openexr-devel] C++11, 'throw', etc.

2017-08-10 Thread Piotr Stanczyk 
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  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 
> 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  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  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
>>
>>
>>
>>
>>
>> ___
>> Openexr-devel mailing list
>> Openexr-devel@nongnu.org
>> https://lists.nongnu.org/mailman/listinfo/openexr-devel
>>
>>
>> --
>>
>> ___
>> Dr. Werner BengerVisualization Research
>> Center for Computation & Technology at Louisiana State University
>> (CCT/LSU)
>> 2019  Digital Media Center, Baton Rouge, Louisiana 70803
>> Tel.: +1 225 578 4809 <(225)%20578-4809>Fax.: +1
>> 225 578-5362 <(225)%20578-5362>
>>
>>
>> ___
>> Openexr-devel mailing list
>> Openexr-devel@nongnu.org
>> https://lists.nongnu.org/mailman/listinfo/openexr-devel
>>
>>
>> --
>> Larry Gritz
>> l...@larrygritz.com
>>
>>
>>
>>
>>
>> ___
>> Openexr-devel mailing list
>> Openexr-devel@nongnu.org
>> https://lists.nongnu.org/mailman/listinfo/openexr-devel
>>
>>
>
> --
> Larry Gritz
> l...@larrygritz.com
>
>
>
>
>
___
Openexr-devel mailing list
Openexr-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/openexr-devel

Re: [Openexr-devel] C++11, 'throw', etc.

2017-08-10 Thread Larry Gritz 
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  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  > 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 > > 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 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> ___
>>> Openexr-devel mailing list
>>> Openexr-devel@nongnu.org 
>>> https://lists.nongnu.org/mailman/listinfo/openexr-devel 
>>> 
>> 
>> -- 
>> ___
>> Dr. Werner BengerVisualization Research
>> Center for Computation & Technology at Louisiana State University (CCT/LSU)
>> 2019  Digital Media Center, Baton Rouge, Louisiana 70803
>> Tel.: +1 225 578 4809 Fax.: +1 
>> 225 578-5362 
>> 
>> 
>> ___
>> Openexr-devel mailing list
>> Openexr-devel@nongnu.org 
>> https://lists.nongnu.org/mailman/listinfo/openexr-devel 
>> 
> 
> --
> Larry Gritz
> l...@larrygritz.com 
> 
> 
> 
> 
> 
> ___
> Openexr-devel mailing list
> Openexr-devel@nongnu.org 
> https://lists.nongnu.org/mailman/listinfo/openexr-devel 
> 
> 
> 

--
Larry Gritz
l...@larrygritz.com




___
Openexr-devel mailing list
Openexr-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/openexr-devel

Re: [Openexr-devel] C++11, 'throw', etc.

2017-08-10 Thread Piotr Stanczyk 
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  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  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
>
>
>
>
>
> ___
> Openexr-devel mailing list
> Openexr-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/openexr-devel
>
>
> --
> 
> ___
> Dr. Werner BengerVisualization Research
> Center for Computation & Technology at Louisiana State University (CCT/LSU)
> 2019  Digital Media Center, Baton Rouge, Louisiana 70803
> Tel.: +1 225 578 4809 <(225)%20578-4809>Fax.: +1
> 225 578-5362 <(225)%20578-5362>
>
>
> ___
> Openexr-devel mailing list
> Openexr-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/openexr-devel
>
>
> --
> Larry Gritz
> l...@larrygritz.com
>
>
>
>
>
> ___
> 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

Re: [Openexr-devel] C++11, 'throw', etc.

2017-08-10 Thread Larry Gritz 
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  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
>> 
>> 
>> 
>> 
>> 
>> ___
>> Openexr-devel mailing list
>> Openexr-devel@nongnu.org
>> https://lists.nongnu.org/mailman/listinfo/openexr-devel
> 
> -- 
> ___
> Dr. Werner BengerVisualization Research
> Center for Computation & Technology at Louisiana State University (CCT/LSU)
> 2019  Digital Media Center, Baton Rouge, Louisiana 70803
> Tel.: +1 225 578 4809Fax.: +1 225 578-5362
> 
> 
> ___
> Openexr-devel mailing list
> Openexr-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/openexr-devel

--
Larry Gritz
l...@larrygritz.com




___
Openexr-devel mailing list
Openexr-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/openexr-devel

Re: [Openexr-devel] C++11, 'throw', etc.

2017-08-10 Thread Werner Benger 
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





___
Openexr-devel mailing list
Openexr-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/openexr-devel


--
___
Dr. Werner BengerVisualization Research
Center for Computation & Technology at Louisiana State University (CCT/LSU)
2019  Digital Media Center, Baton Rouge, Louisiana 70803
Tel.: +1 225 578 4809Fax.: +1 225 578-5362


___
Openexr-devel mailing list
Openexr-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/openexr-devel