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 < [email protected]> 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 <[email protected]>: > > > 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 <[email protected]> > > 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 <[email protected]>: > > > > > > > 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 < > > > [email protected]> > > > > 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 < > > [email protected]> > > > >> 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 < > > [email protected] > > > > > > > >>> 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 < > [email protected]> > > > >>> 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 > > > >>>>> [email protected] > > > >>>>> http://lists.blender.org/mailman/listinfo/bf-committers > > > >>>>> > > > >>>> > > > >>>> > > > >>>> > > > >>>> -- > > > >>>> Jeffrey "Italic_" Hoover > > > >>>> _______________________________________________ > > > >>>> Bf-committers mailing list > > > >>>> [email protected] > > > >>>> http://lists.blender.org/mailman/listinfo/bf-committers > > > >>> > > > >>> > > > >>> > > > >>> -- > > > >>> - Campbell > > > >>> _______________________________________________ > > > >>> Bf-committers mailing list > > > >>> [email protected] > > > >>> http://lists.blender.org/mailman/listinfo/bf-committers > > > >>> > > > >> _______________________________________________ > > > >> Bf-committers mailing list > > > >> [email protected] > > > >> http://lists.blender.org/mailman/listinfo/bf-committers > > > >> > > > > _______________________________________________ > > > > Bf-committers mailing list > > > > [email protected] > > > > 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: [email protected] > > > web: http://www.jensverwiebe.de > > > _____________________________________ > > > > > > _______________________________________________ > > > Bf-committers mailing list > > > [email protected] > > > http://lists.blender.org/mailman/listinfo/bf-committers > > > > > _______________________________________________ > > Bf-committers mailing list > > [email protected] > > http://lists.blender.org/mailman/listinfo/bf-committers > > > _______________________________________________ > Bf-committers mailing list > [email protected] > http://lists.blender.org/mailman/listinfo/bf-committers > -- With best regards, Sergey Sharybin _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
