<div dir="ltr">+1<br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Aug 19, 2014 at 11:16 AM, Marcus D. Hanwell <span dir="ltr"><<a href="mailto:marcus.hanwell@kitware.com" target="_blank">marcus.hanwell@kitware.com</a>></span> wrote:<br>


<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Yes, and there are more extensive examples in the Qt project (for 5+),<br>
and Boost where they both used the prefixed macro name approach. I can<br>
get some of the basics in pretty quickly as I haven't heard much<br>
opposition.<br>
<br>
Marcus<br>
<br>
On Mon, Aug 18, 2014 at 10:28 PM, Andrew Maclean<br>
<div><div><<a href="mailto:andrew.amaclean@gmail.com" target="_blank">andrew.amaclean@gmail.com</a>> wrote:<br>
> Brilliant! It looks as if ITK has already done a lot of this!<br>
><br>
><br>
> Andrew<br>
><br>
><br>
><br>
> On Tue, Aug 19, 2014 at 10:19 AM, Matt McCormick<br>
> <<a href="mailto:matt.mccormick@kitware.com" target="_blank">matt.mccormick@kitware.com</a>> wrote:<br>
>><br>
>> VTK_OVERRIDE would be nice, and it would be nice to macros that are<br>
>> similar to ITK.  Currently there is<br>
>><br>
>>   ITK_OVERRIDE<br>
>>   ITK_NOEXCEPT<br>
>>   ITK_NULLPTR<br>
>><br>
>><br>
>> <a href="http://itk.org/gitweb?p=ITK.git;a=blob;f=Modules/Core/Common/include/itkMacro.h;h=aa4d40d7f5042eaf3c696af469d4cf0848239935;hb=HEAD#l121" target="_blank">http://itk.org/gitweb?p=ITK.git;a=blob;f=Modules/Core/Common/include/itkMacro.h;h=aa4d40d7f5042eaf3c696af469d4cf0848239935;hb=HEAD#l121</a><br>



>><br>
>><br>
>> Thanks,<br>
>> Matt<br>
>><br>
>> On Mon, Aug 18, 2014 at 7:25 PM, Marcus D. Hanwell<br>
>> <<a href="mailto:marcus.hanwell@kitware.com" target="_blank">marcus.hanwell@kitware.com</a>> wrote:<br>
>> > I am with David Gobbi and Ken. It would be a simple search and replace<br>
>> > once support for pre-C++11 compilers were dropped and the potential<br>
>> > for unintended consequences is too great. Glad to see there is general<br>
>> > support, I should have included more on my reasoning, but didn't want<br>
>> > to go into too much detail on implementation if there was little<br>
>> > support for it.<br>
>> ><br>
>> > It sounds like there is, nullptr is definitely another piece of low<br>
>> > hanging fruit. There is lots more that would be great to use, the<br>
>> > language is evolving and it is important that we take advantage of the<br>
>> > parts that make sense.<br>
>> ><br>
>> > Marcus<br>
>> ><br>
>> > On Mon, Aug 18, 2014 at 6:43 PM, David Gobbi <<a href="mailto:david.gobbi@gmail.com" target="_blank">david.gobbi@gmail.com</a>><br>
>> > wrote:<br>
>> >> Yes, I also believe that using "#define override" has the potential to<br>
>> >> cause problems.  Let's say that "override" appears as a variable<br>
>> >> somewhere in code that someone brought into VTK and tested with a<br>
>> >> C++11 compiler (this is legal, since "override" is not a keyword).<br>
>> >> Then someone else tries compiling that code on C++03 where the<br>
>> >> "#define override" is active.  All of a sudden, "override" is replaced<br>
>> >> by nothing anywhere it is used as a variable (or as any other kind of<br>
>> >> identifier).<br>
>> >><br>
>> >><br>
>> >> On Mon, Aug 18, 2014 at 4:29 PM, Andrew Maclean<br>
>> >> <<a href="mailto:andrew.amaclean@gmail.com" target="_blank">andrew.amaclean@gmail.com</a>> wrote:<br>
>> >>> Hi Ken<br>
>> >>><br>
>> >>> Good point, thanks for that.<br>
>> >>><br>
>> >>> Andrew<br>
>> >>><br>
>> >>><br>
>> >>> On Tue, Aug 19, 2014 at 8:25 AM, Moreland, Kenneth <<a href="mailto:kmorel@sandia.gov" target="_blank">kmorel@sandia.gov</a>><br>
>> >>> wrote:<br>
>> >>>><br>
>> >>>> +1 for me too.<br>
>> >>>><br>
>> >>>> However, my vote is actually to introduce things like VTK_OVERRIDE<br>
>> >>>> and<br>
>> >>>> VTK_FINAL until pre-C++11 compilers get abandoned. I find it<br>
>> >>>> disconcerting<br>
>> >>>> when libraries try to get cute with changing the behavior of (or<br>
>> >>>> trying to<br>
>> >>>> emulate) keywords with preprocessor macros. It can be pretty<br>
>> >>>> confusing when<br>
>> >>>> something goes wrong, and good luck if you have to use two separate<br>
>> >>>> projects<br>
>> >>>> together that both tried to define preprocessor macros with different<br>
>> >>>> implementations.<br>
>> >>>><br>
>> >>>> -Ken<br>
>> >>>><br>
>> >>>><br>
>> >>>> From: Andrew Maclean <<a href="mailto:andrew.amaclean@gmail.com" target="_blank">andrew.amaclean@gmail.com</a>><br>
>> >>>> Reply-To: "<a href="mailto:andrew.amaclean@gmail.com" target="_blank">andrew.amaclean@gmail.com</a>" <<a href="mailto:andrew.amaclean@gmail.com" target="_blank">andrew.amaclean@gmail.com</a>><br>


>> >>>> Date: Monday, August 18, 2014 4:09 PM<br>
>> >>>> To: VTK Developers <<a href="mailto:vtk-developers@vtk.org" target="_blank">vtk-developers@vtk.org</a>>, "Marcus D. Hanwell"<br>
>> >>>> <<a href="mailto:marcus.hanwell@kitware.com" target="_blank">marcus.hanwell@kitware.com</a>>, Ben Boeckel <<a href="mailto:ben.boeckel@kitware.com" target="_blank">ben.boeckel@kitware.com</a>>,<br>


>> >>>> Sean<br>
>> >>>> McBride <<a href="mailto:sean@rogue-research.com" target="_blank">sean@rogue-research.com</a>><br>
>> >>>> Subject: [EXTERNAL] Re: [vtk-developers] Introducing (optional) C++11<br>
>> >>>> features in VTK<br>
>> >>>><br>
>> >>>> +1! ... actually: ++1 :-)<br>
>> >>>><br>
>> >>>> I would support this. To keep VTK relevant we need to be introducing<br>
>> >>>> these<br>
>> >>>> features. Especially features like nullptr, unique_ptr etc.<br>
>> >>>><br>
>> >>>> But I would not be happy at introducing more VTK defines like<br>
>> >>>> VTK_OVERRIDE<br>
>> >>>> and VTK_FINAL - unless absolutely necessary. I much prefer Sean's<br>
>> >>>> idea of<br>
>> >>>> using a modernise tool.<br>
>> >>>><br>
>> >>>> Regards<br>
>> >>>>    Andrew<br>
>> >>>><br>
>> >>>><br>
>> >>>> On Tue, Aug 19, 2014 at 7:05 AM, <<a href="mailto:vtk-developers-request@vtk.org" target="_blank">vtk-developers-request@vtk.org</a>><br>
>> >>>> wrote:<br>
>> >>>>><br>
>> >>>>><br>
>> >>>>> ---------- Forwarded message ----------<br>
>> >>>>> From: "Marcus D. Hanwell" <<a href="mailto:marcus.hanwell@kitware.com" target="_blank">marcus.hanwell@kitware.com</a>><br>
>> >>>>> To: VTK Developers <<a href="mailto:vtk-developers@vtk.org" target="_blank">vtk-developers@vtk.org</a>><br>
>> >>>>> Cc:<br>
>> >>>>> Date: Mon, 18 Aug 2014 13:45:37 -0400<br>
>> >>>>> Subject: [vtk-developers] Introducing (optional) C++11 features in<br>
>> >>>>> VTK<br>
>> >>>>> Hi,<br>
>> >>>>><br>
>> >>>>> As we move forward, it would be great to get a feeling for people's<br>
>> >>>>> thoughts about integrating some components of C++11 optionally. So<br>
>> >>>>> if<br>
>> >>>>> C++11 is available/enabled, there are several features we could<br>
>> >>>>> enable<br>
>> >>>>> optionally at compile time.<br>
>> >>>>><br>
>> >>>>> A very simple example is that of the new override keyword, that is<br>
>> >>>>> used to indicate that a member function is overriding a virtual<br>
>> >>>>> function. Using this can avoid mistakes where the signature changes<br>
>> >>>>> and derived classes are missed. It can be defined in a header (empty<br>
>> >>>>> on old compilers, override with recent compilers). Final is similar,<br>
>> >>>>> indicating that the virtual function cannot be overridden in derived<br>
>> >>>>> classes.<br>
>> >>>>><br>
>> >>>>> This would introduce changes to the VTK coding style, where we now<br>
>> >>>>> use<br>
>> >>>>> virtual for all virtual functions (first declaration, or subsequent<br>
>> >>>>> overrides). We could introduce this gradually for new code, even<br>
>> >>>>> having one or two dashboards compiling this way would help spot<br>
>> >>>>> simple<br>
>> >>>>> errors such as an incorrect signature not actually overriding a<br>
>> >>>>> function, but in fact declaring a new virtual for example.<br>
>> >>>>><br>
>> >>>>> In these cases I would suggest simple naming, so VTK_OVERRIDE and<br>
>> >>>>> VTK_FINAL would be used where a C++11 only code would simply use the<br>
>> >>>>> new keywords.<br>
>> >>>>><br>
>> >>>>> Thoughts, objections? There are lots of other features, and I know<br>
>> >>>>> it<br>
>> >>>>> will be a while before we can use them all but it would be great to<br>
>> >>>>> make a start with some of the easier ones that can improve code<br>
>> >>>>> quality with little overhead.<br>
>> >>>>><br>
>> >>>>> Marcus<br>
>> >>>>><br>
>> >>>>><br>
>> >>>>><br>
>> >>>>> ---------- Forwarded message ----------<br>
>> >>>>> From: Ben Boeckel <<a href="mailto:ben.boeckel@kitware.com" target="_blank">ben.boeckel@kitware.com</a>><br>
>> >>>>> To: "Marcus D. Hanwell" <<a href="mailto:marcus.hanwell@kitware.com" target="_blank">marcus.hanwell@kitware.com</a>><br>
>> >>>>> Cc: VTK Developers <<a href="mailto:vtk-developers@vtk.org" target="_blank">vtk-developers@vtk.org</a>><br>
>> >>>>> Date: Mon, 18 Aug 2014 14:21:56 -0400<br>
>> >>>>> Subject: Re: [vtk-developers] Introducing (optional) C++11 features<br>
>> >>>>> in<br>
>> >>>>> VTK<br>
>> >>>>> On Mon, Aug 18, 2014 at 13:45:37 -0400, Marcus D. Hanwell wrote:<br>
>> >>>>> > Thoughts, objections? There are lots of other features, and I know<br>
>> >>>>> > it<br>
>> >>>>> > will be a while before we can use them all but it would be great<br>
>> >>>>> > to<br>
>> >>>>> > make a start with some of the easier ones that can improve code<br>
>> >>>>> > quality with little overhead.<br>
>> >>>>><br>
>> >>>>> What about "= delete" for removing default assignment and copy<br>
>> >>>>> constructors?<br>
>> >>>>><br>
>> >>>>> --Ben<br>
>> >>>>><br>
>> >>>>><br>
>> >>>>><br>
>> >>>>> ---------- Forwarded message ----------<br>
>> >>>>> From: "Marcus D. Hanwell" <<a href="mailto:marcus.hanwell@kitware.com" target="_blank">marcus.hanwell@kitware.com</a>><br>
>> >>>>> To: Ben Boeckel <<a href="mailto:ben.boeckel@kitware.com" target="_blank">ben.boeckel@kitware.com</a>><br>
>> >>>>> Cc: VTK Developers <<a href="mailto:vtk-developers@vtk.org" target="_blank">vtk-developers@vtk.org</a>><br>
>> >>>>> Date: Mon, 18 Aug 2014 14:29:10 -0400<br>
>> >>>>> Subject: Re: [vtk-developers] Introducing (optional) C++11 features<br>
>> >>>>> in<br>
>> >>>>> VTK<br>
>> >>>>> On Mon, Aug 18, 2014 at 2:21 PM, Ben Boeckel<br>
>> >>>>> <<a href="mailto:ben.boeckel@kitware.com" target="_blank">ben.boeckel@kitware.com</a>><br>
>> >>>>> wrote:<br>
>> >>>>> > On Mon, Aug 18, 2014 at 13:45:37 -0400, Marcus D. Hanwell wrote:<br>
>> >>>>> >> Thoughts, objections? There are lots of other features, and I<br>
>> >>>>> >> know it<br>
>> >>>>> >> will be a while before we can use them all but it would be great<br>
>> >>>>> >> to<br>
>> >>>>> >> make a start with some of the easier ones that can improve code<br>
>> >>>>> >> quality with little overhead.<br>
>> >>>>> ><br>
>> >>>>> > What about "= delete" for removing default assignment and copy<br>
>> >>>>> > constructors?<br>
>> >>>>> ><br>
>> >>>>> Certainly, I think we should start out simple and then build it out.<br>
>> >>>>> If we have prototypes for a few of the most useful features that can<br>
>> >>>>> easily be encapsulated in compile time logic that will degrade to<br>
>> >>>>> C++98 that would be great.<br>
>> >>>>><br>
>> >>>>> Marcus<br>
>> >>>>><br>
>> >>>>><br>
>> >>>>><br>
>> >>>>> ---------- Forwarded message ----------<br>
>> >>>>> From: "Sean McBride" <<a href="mailto:sean@rogue-research.com" target="_blank">sean@rogue-research.com</a>><br>
>> >>>>> To: "Marcus D. Hanwell" <<a href="mailto:marcus.hanwell@kitware.com" target="_blank">marcus.hanwell@kitware.com</a>>, "VTK<br>
>> >>>>> Developers"<br>
>> >>>>> <<a href="mailto:vtk-developers@vtk.org" target="_blank">vtk-developers@vtk.org</a>><br>
>> >>>>> Cc:<br>
>> >>>>> Date: Mon, 18 Aug 2014 16:50:12 -0400<br>
>> >>>>> Subject: Re: [vtk-developers] Introducing (optional) C++11 features<br>
>> >>>>> in<br>
>> >>>>> VTK<br>
>> >>>>> On Mon, 18 Aug 2014 13:45:37 -0400, Marcus D. Hanwell said:<br>
>> >>>>><br>
>> >>>>> >As we move forward, it would be great to get a feeling for people's<br>
>> >>>>> >thoughts about integrating some components of C++11 optionally. So<br>
>> >>>>> > if<br>
>> >>>>> >C++11 is available/enabled, there are several features we could<br>
>> >>>>> > enable<br>
>> >>>>> >optionally at compile time.<br>
>> >>>>><br>
>> >>>>> +1 from me.<br>
>> >>>>><br>
>> >>>>> nullptr is another one that can be made to work even on older<br>
>> >>>>> compilers<br>
>> >>>>> with some #define glue.<br>
>> >>>>><br>
>> >>>>> Instead of creating a 'VTK_OVERRIDE', we could also use 'override'<br>
>> >>>>> as if<br>
>> >>>>> we required C++11 and "#define override /* nothing */" as<br>
>> >>>>> appropriate.  Then<br>
>> >>>>> when C++11 really is the minimun requirement no big find/replace is<br>
>> >>>>> required.  Just a thought.<br>
>> >>>>><br>
>> >>>>> PS: I already have dashboards building as C++11 and C++14.<br>
>> >>>>><br>
>> >>>>> Cheers,<br>
>> >>>>><br>
>> >>>>> --<br>
>> >>>>> ____________________________________________________________<br>
>> >>>>> Sean McBride, B. Eng                 <a href="mailto:sean@rogue-research.com" target="_blank">sean@rogue-research.com</a><br>
>> >>>>> Rogue Research                        <a href="http://www.rogue-research.com" target="_blank">www.rogue-research.com</a><br>
>> >>>>> Mac Software Developer              Montréal, Québec, Canada<br>
>> >>>>><br>
>> >>>>><br>
>> >>>>><br>
>> >>>>><br>
>> >>>>><br>
>> >>>>> ---------- Forwarded message ----------<br>
>> >>>>> From: "Sean McBride" <<a href="mailto:sean@rogue-research.com" target="_blank">sean@rogue-research.com</a>><br>
>> >>>>> To: "Marcus D. Hanwell" <<a href="mailto:marcus.hanwell@kitware.com" target="_blank">marcus.hanwell@kitware.com</a>>, "VTK<br>
>> >>>>> Developers"<br>
>> >>>>> <<a href="mailto:vtk-developers@vtk.org" target="_blank">vtk-developers@vtk.org</a>><br>
>> >>>>> Cc:<br>
>> >>>>> Date: Mon, 18 Aug 2014 17:05:38 -0400<br>
>> >>>>> Subject: Re: [vtk-developers] Introducing (optional) C++11 features<br>
>> >>>>> in<br>
>> >>>>> VTK<br>
>> >>>>> On Mon, 18 Aug 2014 16:50:12 -0400, Sean McBride said:<br>
>> >>>>><br>
>> >>>>> >nullptr is another one that can be made to work even on older<br>
>> >>>>> > compilers<br>
>> >>>>> >with some #define glue.<br>
>> >>>>> ><br>
>> >>>>> >Instead of creating a 'VTK_OVERRIDE', we could also use 'override'<br>
>> >>>>> > as if<br>
>> >>>>> >we required C++11 and "#define override /* nothing */" as<br>
>> >>>>> > appropriate.<br>
>> >>>>> >Then when C++11 really is the minimun requirement no big<br>
>> >>>>> > find/replace is<br>
>> >>>>> >required.  Just a thought.<br>
>> >>>>><br>
>> >>>>> I hit send too fast...<br>
>> >>>>><br>
>> >>>>> I also wanted to suggest looking at the clang-modernize tool, which<br>
>> >>>>> is "a<br>
>> >>>>> standalone tool used to automatically convert C++ code written<br>
>> >>>>> against old<br>
>> >>>>> standards to use features of the newest C++ standard".<br>
>> >>>>><br>
>> >>>>> <<a href="http://clang.llvm.org/extra/clang-modernize.html" target="_blank">http://clang.llvm.org/extra/clang-modernize.html</a>><br>
>> >>>>><br>
>> >>>>> Specifically, it can be used to automatically add 'override' and<br>
>> >>>>> convert<br>
>> >>>>> to 'nullptr':<br>
>> >>>>><br>
>> >>>>> <<a href="http://clang.llvm.org/extra/AddOverrideTransform.html" target="_blank">http://clang.llvm.org/extra/AddOverrideTransform.html</a>><br>
>> >>>>> <<a href="http://clang.llvm.org/extra/UseNullptrTransform.html" target="_blank">http://clang.llvm.org/extra/UseNullptrTransform.html</a>><br>
>> >>>>><br>
>> >>>>> Cheers,<br>
>> >> _______________________________________________<br>
>> >> Powered by <a href="http://www.kitware.com" target="_blank">www.kitware.com</a><br>
>> >><br>
>> >> Visit other Kitware open-source projects at<br>
>> >> <a href="http://www.kitware.com/opensource/opensource.html" target="_blank">http://www.kitware.com/opensource/opensource.html</a><br>
>> >><br>
>> >> Follow this link to subscribe/unsubscribe:<br>
>> >> <a href="http://public.kitware.com/mailman/listinfo/vtk-developers" target="_blank">http://public.kitware.com/mailman/listinfo/vtk-developers</a><br>
>> >><br>
>> > _______________________________________________<br>
>> > Powered by <a href="http://www.kitware.com" target="_blank">www.kitware.com</a><br>
>> ><br>
>> > Visit other Kitware open-source projects at<br>
>> > <a href="http://www.kitware.com/opensource/opensource.html" target="_blank">http://www.kitware.com/opensource/opensource.html</a><br>
>> ><br>
>> > Follow this link to subscribe/unsubscribe:<br>
>> > <a href="http://public.kitware.com/mailman/listinfo/vtk-developers" target="_blank">http://public.kitware.com/mailman/listinfo/vtk-developers</a><br>
>> ><br>
><br>
><br>
><br>
><br>
> --<br>
> ___________________________________________<br>
> Andrew J. P. Maclean<br>
><br>
> ___________________________________________<br>
_______________________________________________<br>
Powered by <a href="http://www.kitware.com" target="_blank">www.kitware.com</a><br>
<br>
Visit other Kitware open-source projects at <a href="http://www.kitware.com/opensource/opensource.html" target="_blank">http://www.kitware.com/opensource/opensource.html</a><br>
<br>
Follow this link to subscribe/unsubscribe:<br>
<a href="http://public.kitware.com/mailman/listinfo/vtk-developers" target="_blank">http://public.kitware.com/mailman/listinfo/vtk-developers</a><br>
<br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><a href="tel:%2B1%20919%20869%208849" value="+19198698849" target="_blank">+1 919 869 8849</a><br>
</div></div>