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

Mon Aug 18 19:25:04 EDT 2014

I am with David Gobbi and Ken. It would be a simple search and replace
once support for pre-C++11 compilers were dropped and the potential
for unintended consequences is too great. Glad to see there is general
support, I should have included more on my reasoning, but didn't want
to go into too much detail on implementation if there was little
support for it.

It sounds like there is, nullptr is definitely another piece of low
hanging fruit. There is lots more that would be great to use, the
language is evolving and it is important that we take advantage of the
parts that make sense.

Marcus

On Mon, Aug 18, 2014 at 6:43 PM, David Gobbi <david.gobbi at gmail.com> wrote:
> 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,
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/vtk-developers
>