[Bf-committers] Towards C++11
Konrad Wilhelm
konrad.wilhelm.kleine at gmail.com
Tue Jun 10 11:38:21 CEST 2014
Hi,
I'm not voting against supporting C++11 but if there're problems to support
all of it at once. I suggest to use migrate step by step.
For example, the clang-modernize [1] tool allows you to automatically add a
macro that expands to the C++11 "override" keyword [2] to every virtual
function that overrides a function from a base class [3].
It turns this code
class A { virtual foo() {} };
class B : A { foo() {} };
to this code
class A { virtual foo() {} };
class B : A { foo() override {} };
or to this code
class A { virtual foo() {} };
class B : A { foo() MY_OVERRIDE_MACRO {} };
Depending on whether you have used the "-override-macro" switch on the
clang-modernize tool and if you have a #define MY_OVERRIDE_MACRO that
expands to "override" somewhere.
Override does basically nothing but checking that foo() indeed overrides a
virtual function from a base class. If you happen to rename A::foo() to
A::bar() the following code will still compile:
class A { virtual bar() {} };
class B : A { foo() {} };
But this this code will not compile:
class A { virtual bar() {} };
class B : A { foo() override {} };
See the benefit? If you forgot to rename "foo" to "bar" in any derivative
class of A, you previously wouldn't get an error. The code still compiles
with non-C++11 compilers where MY_OVERRIDE_MACRO doesn't expand to
"override".
The clang-modernize tool helps to introduce this C++11 feature very easiy
and it does a very good job doing so. If I find the time later today, I
will run it on the Blender code base and post an audit/review (which on is
the pre-commit one again?) on phabricator.
Happy coding
Konrad
PS: I've changed ~600 files and >3400 lines of code with clang-modernize in
another project to introduce the C++11 override feature
PPS: If there're odd coding patterns that are hard to find with regular
expressions, one can write a clang-tool to find those places. Its
unbelieavably easy. Just have a look how the clang-modernize tool finds the
places to add an override specifier (extracted from [4]):
methodDecl(hasParent(recordDecl()),
isOverride(),
unless(destructorDecl()))
This describes a matching pattern that is applied to the whole AST
representation of your source code. I think it's very verbose and
meaningful. It finds any method declaration that is part of a "struct" or
"class", hence "recordDecl", and overrides a method (see "foo" in my
example above). To prevent destructors from being specified as "override",
the last line excludes destructors from these method declarations that we
want to match. Now, to be fair, the matching part is more or less trivial,
the tricky part comes when replacing stuff. That is art and not to be
discussed here ;) But at least you can find the places where some coding
pattern applies. Appart from declaration matchers like the one for finding
places to add the "override" keyword to, one can also create matchers for
any type of call of a function.
[1] http://clang.llvm.org/extra/ModernizerUsage.html
[2] http://clang.llvm.org/extra/AddOverrideTransform.html
[3]
http://channel9.msdn.com/Events/GoingNative/2013/The-Care-and-Feeding-of-C-s-Dragons
at time 0:32:10
[4]
http://llvm.org/svn/llvm-project/clang-tools-extra/trunk/clang-modernize/AddOverride/AddOverrideMatchers.cpp
2014-06-08 13:06 GMT+02:00 Lukas Tönne <lukas.toenne at gmail.com>:
> Have been doing an initial test (arch linux 64bit, GCC 4.9), and looks like
> it's working alright with just a few minor tweaks needed.
>
> This commit enables C++11 in the depsgraph_refactor branch and could be
> ported cleanly to master:
> https://developer.blender.org/rB93e4e1ce3434ea680c6ac69fab68303d09d0d11b
>
> Note: some static type tests in BLI_utildefines have been disabled for C++
> here, lengthy explanation in the commit comments.
>
> Other compilers (clang, xcode, msvc) will need to be tested of course, and
> some external libs need to be verified for compatibility, but generally it
> looks quite promising.
>
>
> On Sat, Jun 7, 2014 at 2:16 PM, Jens Verwiebe <info at jensverwiebe.de>
> wrote:
>
> > Regarding OSX, it should plain work.
> >
> > I use c++11 based projects since a while without any issues recognized.
> > Anyway apple clang is based on common clang svn, just with some specials
> > addedas
> > for example xcode integration etc. ..
> >
> > Jens
> >
> >
> >
> >
> > Am 07.06.2014 um 12:04 schrieb Lukas Tönne <lukas.toenne at gmail.com>:
> >
> > > It's great to see that C++11 has general support. It would be really
> > > helpful in the depsgraph to deal with closures, among other places.
> > Without
> > > this we'd have to either tediously backport boost implementation (but
> why
> > > reinvent the wheel?), or use lots of bloated cumbersome type
> definitions
> > > and C style void* casting (error prone, hides logic). So i'm really
> happy
> > > that there are no big showstoppers so far.
> > >
> > >
> > > On Sat, Jun 7, 2014 at 11:38 AM, Martijn Berger <
> > martijn.berger at gmail.com>
> > > wrote:
> > >
> > >> @Campbell I am pretty sure give how hard Apple is pushing out new
> > releases
> > >> and given how many people upgrade that we can just assume an
> llvm/clang
> > >> 3.0+ feature set for c++11.
> > >>
> > >> I think we should also do this analysis for C99 support and C11
> support.
> > >> There are some other projects out there that use C++11 features (clang
> > is
> > >> one) and they have made comprehensive analysis of what features they
> can
> > >> and do use.
> > >>
> > >> There are some things we can use anyway like noexcept provided we use
> it
> > >> like the QT people use it so the code does not require a c++11
> compiler
> > but
> > >> you do get some benefit from compiling with one (
> > >> http://qt-project.org/doc/qt-5/qtglobal.html#Q_DECL_NOEXCEPT)
> > >>
> > >> I think getting a sort of caniuse.com for c/c++ language features on
> > the
> > >> wiki would be good way forward.
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >> On Sat, Jun 7, 2014 at 11:11 AM, Campbell Barton <
> ideasman42 at gmail.com>
> > >> wrote:
> > >>
> > >>> General +1 to take advantage of C++11 where appropriate,
> > >>> AFAICS OSX needs some investigation?, otherwise we're close to being
> > >>> able to support it.
> > >>>
> > >>>
> > >>> @Tom M: I'm not concerned with static checking tools, mainly because
> > >>> using C++11 in a few places won't suddenly make static checkers fail
> > >>> on the rest of our code, eventually they will get updated too.
> > >>>
> > >>> Coverity has support:
> > >>> https://communities.coverity.com/docs/DOC-1571
> > >>> clang-static-analyser didn't work well for me last I checked with
> C++,
> > >>> but it might have improved in last year or so.
> > >>>
> > >>>
> > >>> @Ichthyo: Not being able to build Blender on older Linux isnt such a
> > >>> big deal since Blender can still run on them, if its important they
> > >>> can get a new compiler (I did this on a CentOS server, compiling a
> > >>> newer GCC/Clang isnt that big of a deal).
> > >>>
> > >>>
> > >>> @Jeffrey H: C++11 doesn't raise hardware requirements.
> > >>>
> > >>> On Sat, Jun 7, 2014 at 3:18 PM, Jeffrey H <
> italic.rendezvous at gmail.com
> > >
> > >>> wrote:
> > >>>> What about older hardware? I don't know much about C++11, but I
> would
> > >>>> imagine it takes advantage of newer processor instruction sets and I
> > >> know
> > >>>> new compilers do the same. Would Blender still run on, say, an old
> > >>> Pentium
> > >>>> 4? The reason I ask is simply because a large number of users use
> > >> Blender
> > >>>> because it's able to run on the proverbial toaster, where Maya and
> > >> other
> > >>>> programs cannot. Is this actually an issue or am I just making stuff
> > >> up?
> > >>>>
> > >>>>
> > >>>> On Fri, Jun 6, 2014 at 11:39 AM, Ichthyostega <prg at ichthyostega.de>
> > >>> wrote:
> > >>>>
> > >>>>> Am 06.06.2014 17:54, schrieb Sergey Sharybin:
> > >>>>>> Why it might be useful?
> > >>>>>
> > >>>>>> C++11 brings some neat syntax and STD library extensions.
> > >>>>>
> > >>>>> ..plus the benefit you can get from using functors / closures
> wisely.
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>> Downside is that we have to cut off some platforms / compilers.
> > >>>>>
> > >>>>> Basically we need GCC >= 4.7 and Clang >= 3.0
> > >>>>>
> > >>>>> And anything below that will not be supported anymore.
> > >>>>> Like RedHat Enterprise Linux. :-P
> > >>>>>
> > >>>>>
> > >>>>> Sounds like something for Blender 2.8.x
> > >>>>>
> > >>>>> --Ichthyo
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>> _______________________________________________
> > >>>>> Bf-committers mailing list
> > >>>>> Bf-committers at blender.org
> > >>>>> http://lists.blender.org/mailman/listinfo/bf-committers
> > >>>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>> --
> > >>>> Jeffrey "Italic_" Hoover
> > >>>> _______________________________________________
> > >>>> Bf-committers mailing list
> > >>>> Bf-committers at blender.org
> > >>>> http://lists.blender.org/mailman/listinfo/bf-committers
> > >>>
> > >>>
> > >>>
> > >>> --
> > >>> - Campbell
> > >>> _______________________________________________
> > >>> Bf-committers mailing list
> > >>> Bf-committers at blender.org
> > >>> http://lists.blender.org/mailman/listinfo/bf-committers
> > >>>
> > >> _______________________________________________
> > >> Bf-committers mailing list
> > >> Bf-committers at blender.org
> > >> http://lists.blender.org/mailman/listinfo/bf-committers
> > >>
> > > _______________________________________________
> > > Bf-committers mailing list
> > > Bf-committers at blender.org
> > > http://lists.blender.org/mailman/listinfo/bf-committers
> >
> > _____________________________________
> >
> > Jens Verwiebe
> > Allerskehre 44 - 22309 Hamburg
> >
> > Tel.: +49 40 68 78 50
> > mobil: +49 172 400 49 07
> > mailto: info at jensverwiebe.de
> > web: http://www.jensverwiebe.de
> > _____________________________________
> >
> > _______________________________________________
> > Bf-committers mailing list
> > Bf-committers at blender.org
> > http://lists.blender.org/mailman/listinfo/bf-committers
> >
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>
More information about the Bf-committers
mailing list