Hi Sergey, no no I'm not voting for some library or emulation to use. I voted for smooth transitioning to C++11 with the help of automation and clever macro definition. Let me quickly sketch out the things one would have to do to implement my idea...
I just picked one feature from C++11, namely the "override" specifier, to show that it is safe to implement even if not everybody switches to C++11. Just add something like this to some top-level CMakeLists.txt file: # Test if C++11 "override" specifier is supported by current compiler. # (See http://en.cppreference.com/w/cpp/language/override) check_cxx_source_compiles(" struct A { virtual void foo() {} }; struct B : A { void foo() override {} }; int main(int argc, char * argv[]) { B b; return 0; }" HAVE_CXX11_OVERRIDE_SPECIFIER) if(HAVE_CXX11_OVERRIDE_SPECIFIER) message(STATUS "Using C++11 override specifier where possible.") set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -DHAVE_CXX11_OVERRIDE_SPECIFIER") endif(HAVE_CXX11_OVERRIDE_SPECIFIER) Then in a global header file, use the HAVE_CXX11_OVERRIDE_SPECIFIER to define a macro that can be used instead of "override" directly: #ifdef HAVE_CXX11_OVERRIDE_SPECIFIER # define BF_OVERRIDE override #else # define BF_OVERRIDE #endif With just these two modifications in place, one can use BF_OVERRIDE in places where one would normally use the "override" keyword directly. It does no harm but adds a maintainability value to the code. To automate the process of using BF_OVERRIDE in places where it makes sense, I voted for using the clang-modernize tool. You run the tool and it changes your code, not more but not less. It does no emulation nor puts it a library in your code. Besides the "override" specifier the clang-modernize tool can also be used to replace auto_ptr with unique_ptr, and more, which seems to be what you were looking for. Here's a list of transformations, clang-modernize can apply to your source code: - Make use of override specifier where possible - Make use of range-based for loops where possible - Pass parameters by value where possible - Replace std::auto_ptr (deprecated) by std::unique_ptr (EXPERIMENTAL) - Use of 'auto' type specifier - Make use of nullptr keyword where possible Let me emphasize that this is not a library approach. It is just a smart tool that helps transitioning to C++11. I hope, this clarifies my idea. - Konrad 2014-06-10 17:30 GMT+02:00 Sergey Sharybin <[email protected]>: > 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 > _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
