[vtk-developers] Introducing (optional) C++11 features in VTK

Andrew Maclean andrew.amaclean at gmail.com
Mon Aug 18 18:29:59 EDT 2014 

Hi Ken

Good point, thanks for that.

Andrew


On Tue, Aug 19, 2014 at 8:25 AM, Moreland, Kenneth <kmorel at sandia.gov>
wrote:

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



-- 
___________________________________________
Andrew J. P. Maclean

___________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20140819/95c38939/attachment-0002.html>

More information about the vtk-developers mailing list