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

Marcus D. Hanwell marcus.hanwell at kitware.com
Fri Aug 22 11:57:56 EDT 2014 

So my first pass at this, keeping the bar relatively low for now,

http://review.source.kitware.com/#/t/4550/

I have tested this both as default, and forcing to ANSI C++, on GCC
4.9.1. It would be pretty simple to extend this for Clang (I would
rather do it in a follow up commit). This does change the default to
enable C++11 if the GCC compiler reports it is capable of this, and I
verified the VTK_OVERRIDE fails as expected when overriding something
that is not virtual. When looking at this it raised the question (for
me at least) of whether we ask for ANSI C++, and the standards (I
think we should), or the GNU specific extensions (what we were
implicitly doing before by passing nothing unless extra warnings were
turned on).

The features coming up in CMake look great, but I don't think we need
to wait in order to use some of the simpler features. It passes on the
Gerrit submissions, so nothing terrible happened on the surface, I
think this set is pretty conservative. Let me know if you see major
issues in the approach, you can see in a single class (vtkBitArray)
how VTK_OVERRIDE and VTK_NULLPTR are used.

Marcus

On Tue, Aug 19, 2014 at 11:16 AM, Marcus D. Hanwell
<marcus.hanwell at kitware.com> wrote:
> Yes, and there are more extensive examples in the Qt project (for 5+),
> and Boost where they both used the prefixed macro name approach. I can
> get some of the basics in pretty quickly as I haven't heard much
> opposition.
>
> Marcus
>
> On Mon, Aug 18, 2014 at 10:28 PM, Andrew Maclean
> <andrew.amaclean at gmail.com> wrote:
>> Brilliant! It looks as if ITK has already done a lot of this!
>>
>>
>> Andrew
>>
>>
>>
>> On Tue, Aug 19, 2014 at 10:19 AM, Matt McCormick
>> <matt.mccormick at kitware.com> wrote:
>>>
>>> VTK_OVERRIDE would be nice, and it would be nice to macros that are
>>> similar to ITK.  Currently there is
>>>
>>>   ITK_OVERRIDE
>>>   ITK_NOEXCEPT
>>>   ITK_NULLPTR
>>>
>>>
>>> http://itk.org/gitweb?p=ITK.git;a=blob;f=Modules/Core/Common/include/itkMacro.h;h=aa4d40d7f5042eaf3c696af469d4cf0848239935;hb=HEAD#l121
>>>
>>>
>>> Thanks,
>>> Matt
>>>
>>> On Mon, Aug 18, 2014 at 7:25 PM, Marcus D. Hanwell
>>> <marcus.hanwell at kitware.com> wrote:
>>> > 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
>>> >>
>>> > _______________________________________________
>>> > 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
>>> >
>>
>>
>>
>>
>> --
>> ___________________________________________
>> Andrew J. P. Maclean
>>
>> ___________________________________________

More information about the vtk-developers mailing list