Re: C++11, 'throw', etc.
Richard Addison-Wood <[email protected]> Mon, 14 Aug 2017 20:44:45 +1200
| Newsgroups | gmane.comp.video.openexr.devel |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format. --===============6785426221402562565== Content-Type: multipart/alternative; boundary="------------1FD88EFFB678418734B5AFFF" Content-Language: en-US This is a multi-part message in MIME format. --------------1FD88EFFB678418734B5AFFF Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit 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 > <[email protected] <mailto:[email protected]>> 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 <[email protected] > <mailto:[email protected]>> 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 >> <[email protected] <mailto:[email protected]>> >> 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 <[email protected] >> <mailto:[email protected]>> 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 >>> <[email protected] <mailto:[email protected]>> 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 >>>> [email protected] <mailto:[email protected]> >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Openexr-devel mailing list >>>> [email protected] <mailto:[email protected]> >>>> 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 >>> [email protected] <mailto:[email protected]> >>> https://lists.nongnu.org/mailman/listinfo/openexr-devel >> >> -- >> Larry Gritz >> [email protected] <mailto:[email protected]> >> >> >> >> >> >> _______________________________________________ >> Openexr-devel mailing list >> [email protected] <mailto:[email protected]> >> https://lists.nongnu.org/mailman/listinfo/openexr-devel >> >> > > -- > Larry Gritz > [email protected] <mailto:[email protected]> > > > > > _______________________________________________ > Openexr-devel mailing list > [email protected] <mailto:[email protected]> > https://lists.nongnu.org/mailman/listinfo/openexr-devel > > > > _______________________________________________ > Openexr-devel mailing list > [email protected] > https://lists.nongnu.org/mailman/listinfo/openexr-devel --------------1FD88EFFB678418734B5AFFF Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> </head> <body text="#000000" bgcolor="#FFFFFF"> 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.<br> <br> Thus, we can continue to support users of ilmbase according to their own C++ language standard needs.<br> <br> 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.<br> <br> 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.<br> <br> <div class="moz-cite-prefix">On 08/12/17 11:20, Nick Rasmussen wrote:<br> </div> <blockquote type="cite" cite="mid:CAOYGd5xVd3obUtAtpdEBouXNEnfhGdd=b9znaGPf875HaG4GSQ@mail.gmail.com"> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> <div> <div dir="auto"><br> </div> <div> <div dir="auto">It seems reasonable to me as well. Removing the dynamic exception specifications would’t even break compatibility with older compilers. </div> </div> </div> <div> <div> <div dir="auto"><br> </div> <div dir="auto">-nick</div> </div> <div><br> <div class="gmail_quote"> <div>On Thu, Aug 10, 2017 at 11:52 AM Piotr Stanczyk <<a href="mailto:[email protected]" target="_blank" moz-do-not-send="true">[email protected]</a>> wrote:<br> </div> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div>Sounds like a sensible plan to me. </div> <div><br> </div> <div>Anyone from ILM care to comment on this? Can you foresee any internal build issues?</div> <div><br> </div> <div>Piotr</div> <div><br> <div class="gmail_quote"> <div>On Thu, Aug 10, 2017 at 11:40 AM Larry Gritz <<a href="mailto:[email protected]" target="_blank" moz-do-not-send="true">[email protected]</a>> wrote:<br> </div> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div style="word-wrap:break-word">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). <div><br> </div> <div>We're only talking about moving forward, so a stray downstream product stuck on C++03 can keep using OpenEXR <= 2.2.</div> <div><br> </div> <div>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.</div> <div><br> </div> <div><span class="m_6361944120489933342m_-293618947442915972m_-6079636075028917681Apple-tab-span" style="white-space:pre-wrap"> </span>-- lg</div> <div><br> </div> </div> <div style="word-wrap:break-word"> <div> <div><br> <div> <blockquote type="cite"> <div>On Aug 10, 2017, at 11:12 AM, Piotr Stanczyk <<a href="mailto:[email protected]" target="_blank" moz-do-not-send="true">[email protected]</a>> wrote:</div> <br class="m_6361944120489933342m_-293618947442915972m_-6079636075028917681Apple-interchange-newline"> <div> <div>Are there any vendors for whom this would cause an issue? Else, I would vote for moving things forward <div><br> </div> </div> <div class="gmail_extra"><br> <div class="gmail_quote">On 10 August 2017 at 10:18, Larry Gritz <span><<a href="mailto:[email protected]" target="_blank" moz-do-not-send="true">[email protected]</a>></span> wrote:<br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div style="word-wrap:break-word">Ugh, so it's worse than I thought. <div><br> </div> <div>I suppose I'm willing to fix and submit a patch to address this.</div> <div><br> </div> <div>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?</div> <div><br> </div> <div><span class="m_6361944120489933342m_-293618947442915972m_-6079636075028917681m_6758675243403444048Apple-tab-span" style="white-space:pre-wrap"> </span>-- lg</div> <div><br> </div> <div> <div> <div class="m_6361944120489933342m_-293618947442915972m_-6079636075028917681h5"><br> <div> <blockquote type="cite"> <div>On Aug 9, 2017, at 11:38 PM, Werner Benger <<a href="mailto:[email protected]" target="_blank" moz-do-not-send="true">[email protected]</a>> wrote:</div> <br class="m_6361944120489933342m_-293618947442915972m_-6079636075028917681m_6758675243403444048Apple-interchange-newline"> <div> <div>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.<br> <br> Werner<br> <br> <br> On 10.08.2017 00:20, Larry Gritz wrote:<br> <blockquote type="cite">In a test compile with gcc 7, I get lots of errors of the following ilk:<br> <br> /home/travis/build/lgritz/openexr/IlmBase/Imath/ImathVec.h:228:34: warning: dynamic exception specifications are deprecated in C++11 [-Wdeprecated]<br> const Vec2 & normalizeExc () throw (IEX_NAMESPACE::MathExc);<br> ^~~~~<br> <br> 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.<br> <br> 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 [<a href="http://www.vfxplatform.com/" target="_blank" moz-do-not-send="true">http://www.vfxplatform.com/</a>] dictated C++11 for 2016 and 2017, and will be C++14 for 2018.<br> <br> <span class="m_6361944120489933342m_-293618947442915972m_-6079636075028917681m_6758675243403444048Apple-tab-span" style="white-space:pre-wrap"> </span>-- lg<br> <br> --<br> Larry Gritz<br> <a href="mailto:[email protected]" target="_blank" moz-do-not-send="true">[email protected]</a><br> <br> <br> <br> <br> <br> _______________________________________________<br> Openexr-devel mailing list<br> <a href="mailto:[email protected]" target="_blank" moz-do-not-send="true">[email protected]</a><br> <a href="https://lists.nongnu.org/mailman/listinfo/openexr-devel" target="_blank" moz-do-not-send="true">https://lists.nongnu.org/mailman/listinfo/openexr-devel</a><br> </blockquote> <br> -- <br> ___________________________________________________________________________<br> Dr. Werner Benger Visualization Research<br> Center for Computation & Technology at Louisiana State University (CCT/LSU)<br> 2019 Digital Media Center, Baton Rouge, Louisiana 70803<br> Tel.: <a href="tel:%28225%29%20578-4809" value="+12255784809" target="_blank" moz-do-not-send="true">+1 225 578 4809</a> Fax.: <a href="tel:%28225%29%20578-5362" value="+12255785362" target="_blank" moz-do-not-send="true">+1 225 578-5362</a><br> <br> <br> _______________________________________________<br> Openexr-devel mailing list<br> <a href="mailto:[email protected]" target="_blank" moz-do-not-send="true">[email protected]</a><br> <a href="https://lists.nongnu.org/mailman/listinfo/openexr-devel" target="_blank" moz-do-not-send="true">https://lists.nongnu.org/mailman/listinfo/openexr-devel</a><br> </div> </div> </blockquote> </div> <br> </div> </div> <div> <div style="word-wrap:break-word"> <div style="font-family:Helvetica;font-size:14px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">--</div> <div style="font-family:Helvetica;font-size:14px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">Larry Gritz</div> <div style="font-family:Helvetica;font-size:14px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><a href="mailto:[email protected]" target="_blank" moz-do-not-send="true">[email protected]</a></div> <div style="font-family:Helvetica;font-size:14px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><br> </div> <br class="m_6361944120489933342m_-293618947442915972m_-6079636075028917681m_6758675243403444048Apple-interchange-newline"> </div> <br class="m_6361944120489933342m_-293618947442915972m_-6079636075028917681m_6758675243403444048Apple-interchange-newline"> </div> <br> </div> </div> <br> _______________________________________________<br> Openexr-devel mailing list<br> <a href="mailto:[email protected]" target="_blank" moz-do-not-send="true">[email protected]</a><br> <a href="https://lists.nongnu.org/mailman/listinfo/openexr-devel" rel="noreferrer" target="_blank" moz-do-not-send="true">https://lists.nongnu.org/mailman/listinfo/openexr-devel</a><br> <br> </blockquote> </div> <br> </div> </div> </blockquote> </div> <br> </div> </div> </div> <div style="word-wrap:break-word"> <div> <div> <div> <div style="word-wrap:break-word"> <div style="color:rgb(0,0,0);font-family:Helvetica;font-size:14px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">--</div> <div style="color:rgb(0,0,0);font-family:Helvetica;font-size:14px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">Larry Gritz</div> <div style="color:rgb(0,0,0);font-family:Helvetica;font-size:14px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><a href="mailto:[email protected]" target="_blank" moz-do-not-send="true">[email protected]</a></div> <div style="color:rgb(0,0,0);font-family:Helvetica;font-size:14px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><br> </div> <br class="m_6361944120489933342m_-293618947442915972m_-6079636075028917681Apple-interchange-newline"> </div> <br class="m_6361944120489933342m_-293618947442915972m_-6079636075028917681Apple-interchange-newline"> </div> <br> </div> </div> </div> </blockquote> </div> </div> _______________________________________________<br> Openexr-devel mailing list<br> <a href="mailto:[email protected]" target="_blank" moz-do-not-send="true">[email protected]</a><br> <a href="https://lists.nongnu.org/mailman/listinfo/openexr-devel" rel="noreferrer" target="_blank" moz-do-not-send="true">https://lists.nongnu.org/mailman/listinfo/openexr-devel</a><br> </blockquote> </div> </div> </div> <br> <fieldset class="mimeAttachmentHeader"></fieldset> <br> <pre wrap="">_______________________________________________ Openexr-devel mailing list <a class="moz-txt-link-abbreviated" href="mailto:[email protected]">[email protected]</a> <a class="moz-txt-link-freetext" href="https://lists.nongnu.org/mailman/listinfo/openexr-devel">https://lists.nongnu.org/mailman/listinfo/openexr-devel</a> </pre> </blockquote> <br> </body> </html> --------------1FD88EFFB678418734B5AFFF-- --===============6785426221402562565== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Openexr-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/openexr-devel --===============6785426221402562565==--