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
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
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 R
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
>
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
m
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
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
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
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 sinc
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 O
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 macr
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
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
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);
14 matches
Mail list logo
