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

[David Gobbi]

Yes, I also believe that using "#define override" has the potential to
cause problems.  Let's say that "override" appears as a variable
somewhere in code that someone brought into VTK and tested with a
C++11 compiler (this is legal, since "override" is not a keyword).
Then someone else tries compiling that code on C++03 where the
"#define override" is active.  All of a sudden, "override" is replaced
by nothing anywhere it is used as a variable (or as any other kind of
identifier).


On Mon, Aug 18, 2014 at 4:29 PM, Andrew Maclean
<andrew.amaclean at gmail.com> wrote:
> 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,