[Bf-committers] Towards C++11
Konrad Wilhelm
konrad.wilhelm.kleine at gmail.com
Wed Jun 11 09:45:37 CEST 2014
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 <sergey.vfx at gmail.com>:
> 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
> _______________________________________________
> 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