[Bf-committers] Towards C++11

Sergey Sharybin sergey.vfx at gmail.com
Tue Jun 10 17:30:12 CEST 2014 

Konrad, i'm not really sure what you mean. If it's about using some
tool/library which _emulates_ c++11 then i'd say no-go for this. Would
rather implement function bindings/move {shared,unique}_ptr (which are the
main reason i've started this thread) to some header in extern/ which could
be used all over the place.



On Tue, Jun 10, 2014 at 3:38 PM, Konrad Wilhelm <
konrad.wilhelm.kleine at gmail.com> wrote:

> 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
> >
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>



-- 
With best regards, Sergey Sharybin

More information about the Bf-committers mailing list