[Bf-committers] Towards C++11

Sergey Sharybin sergey.vfx at gmail.com
Fri Jun 6 17:54:19 CEST 2014


It was rather a question of time when this question arises, so let's ask
it: when we'll allow using C++11 features?

= Why it might be useful? =

C++11 brings some neat syntax and STD library extensions. which might help

- Getting rid of custom shared_ptr implementation in both Libmv and Ceres.
- Simplify some traversal code in Ceres (details about exact use-cases in
Ceres sources i don't know yet, might ask Sameer if someone wonders)
- Get rid of OpenMP in Libmv/Ceres by using concurrency primitives from new
standard library.
- Get rid of Boost in Cycles by using function bindings from new standard
(this i didn't do by self yet, so this is mainly information from Lukas. he
also needed this to simplify some code in new dependency graph project).
- Get rid of Boost in Audaspace by using unique_ptr/shared_ptr from new
- Guess examples might be extended/

= Which compilers supports C++11 =

== Linux ==

GCC have almost full support of C++11 since version 4.8 and it's almost
full support in 4.7. We're using GCC 4.7 for release builds and seems it
does have stuff mentioned above.

Also some of the features implemented in C++0x, which is partially
supported in GCC-4.4. I'm talking about such an old compiler here because
it's a default compiler in CentOS and this OS seems to be used by some
render farms. So this means we might do transition for them quite flawless
(stuff like bumping Python version for them wouldn't be a smaller headache
i guess).

More details about C++11 in GCC you might find there [1]

== Windows ==

MSVC 2013 seems to have quite nice C++11 support as well. This is an
officially supported compiler now, soon we'll drop MSVC 2008 and we never
supported MSVC 2010 and 2012. So seems Windows is rather safe.

== OSX ==

For OSX i'm not sure. If we're using GCC then the case is covered above. If
we're using Clang then supported bits from new standard are listed there
[2]. I'm not really sure which OSX version and compiler'version we're using
for official builds.

= Policy about using new standard =

Accepting C++11 in code should not imply any permanently on-going cleanup
of old code to use new syntax, features etc. New standard should be only
used when it should use. As in: if it makes code easier to follow or allows
us not using some heavy external libs.

= When do we start and how do we process =

This i don't really know and that's the main reason writing this mail. From
what i currently can tell is that we need:

- Agree with all the developers that C++11 is worth using
- Agree with platform maintainers that official builds are possible to be
- Find out a good timing when we might start using new features.

= Did i miss something =

Yes, pretty much sure i did and there are more questions to be answered.
But that's why we've got ML -- to discuss stuff and find an ultimate way to
move forward :)

[1] http://gcc.gnu.org/projects/cxx0x.html
[2] http://clang.llvm.org/cxx_status.html

With best regards, Sergey Sharybin

More information about the Bf-committers mailing list