[Bf-committers] Making C++11 required for blender2.8 branch

[Jörg Müller]

Hello everyone,

I'm a bit startled about the whole discussion about which features to 
allow and not allow. To me it's strange to have those restrictions in 
the first place and some of the comments sound like: yeah, let's allow 
the while loop, but not for loops, you can do the same thing with a 
while loop anyway. We also don't strictly allow/disallow features of 
Python, C or older C++ versions. There are always arguments for and 
against features, but even goto has some valid use cases (eg. error 
handling where else you would have horribly nested if/else combinations) 
and after all the designers of C++11 had good reasons for the 
changes/additions. Therefore I think everything should be allowed except 
for reasons such as compilers/platforms we support, but that don't 
support specific features, or similar limitations. Everything else can 
go into coding guidelines (like: don't use goto and globals) and be 
taked care of with code reviews, otherwise this might be another reason 
to scare away contributors.

Cheers,
Jörg

On 2016-10-04 11:15, Sergey Sharybin wrote:
> Hi,
>
> = Summary =
>
> I would like to propose to switch to C++11 in blender2.8 branch.
>
> Such a bump was already discussed in the past, but i want to give it a real
> pus forward now.
>
> = Why do we need C++11 =
>
> There are various aspects why we want C++11. Here is just couple of
> examples from own areas i meaintain.
>
> == Dependency graph ==
>
> I would like to kick old depednency graph out from 2.8 branch, so we
> wouldn't need to worry about whether particular feature is compatible with
> old depsgraph design or not. This would help laying down design and
> implementation for all the node-based and local-overrides features we need.
>
> New dependency graph uses function bindings (it's like a function pointer
> with argument values which will be passed to the function). Currently in
> release builds we depend on Boost for that. But making Boost required for
> Blender is something i'm not going to commit to. So the idea is to use
> C++11 for this.
>
> Surely, here there's an alternative to write own function bindings
> implementation (and i even have such implementation), but from benchmarks
> they are much slower than native C++11. Even Boost implementation is
> slower. This might not be an issue in other implications, but in new
> depsgraph we really have 1000s function calls per rig, so it becomes a
> bottleneck.
>
> == Cycles / Audaspace ==
>
> Cycles and Audaspace are using Boost for some code helpers like foreach
> loops and shared pointers. This features are available in C++11, so such
> transition will let us to make Blender itself free from such a heavy and
> tricky dependency as Boost (Blender release builds will still use Boost
> indirectly via OIIO/OCIO).
>
> == OpenShadingLanguage ==
>
> We are currently hitting limitation of how new OSL can be because of LLVM
> requirements. We are currently using LLVM 3.4 which is quite old (recently
> it was 3.9 released). Tricky thing is: we can't bring up newer LLVM because
> new version of it requires C++11.
>
> == Other cases ==
>
> There might be other areas in the code which will benefit and make
> development easier, i only listed things from areas i'm really familiar
> with.
>
> = What does it mean to requirements =
>
> I would really suggest sticking to a minimal allowed feature sets from
> C++11 (see below), so requirements seems to be:
>
> == Windows ==
>
> MSVC 2013 already supports quite enough of C++11, so nothing will be
> changed here
>
> == OSX ==
>
> OSX will need to be bumped to at least version 10.7, hopefully we can bring
> it up to 10.8. To my knowledge, OpenGL/viewport work will require such bump
> to 10.7 due to drivers.
>
> Details about 10.7 vs. 10.8 would better be discussed in IRC with devs who
> are motre familiar with that world than i am.
>
> But in any case, any of this bumps will require re-compiling the whole
> precompiled libraries repository. That's where we would need help of
> platform maintainers.
>
> == Linux ==
>
> Linux will require gcc-4.8, which seems to be old enough and available on
> all the platforms (even the ones recommended by vfxplatforms ;)
>
> There will also be required some work to be done to make sure all the
> dependencies are also build with C++11.
>
> Unfortunately, it's quite tricky to know in advance. Fortunately, it's only
> Blender Linux platform guys would need to solve in install_deps.sh so for
> users it'll be matter of re-running the script.
>
> = What's the plan =
>
> There are still some technical details to be discussed and figured out, but
> this we'll do much easier in IRC with platform maintainers.
>
> Here's my vision of how we can approach the migration:
>
> - Create a Git branch where we'll be (a) working on build scripts (b) do
> required tweaks to CMake and code when/if needed.
> - Create a new folder in
> https://svn.blender.org/svnroot/bf-blender/trunk/lib/ for OSX C++11
> libraries. Not sure darwin-9 is really relevant name nowadays. Commit all
> newely compiled libraries in there.
> - Once the branch is finished and tested by active developers, merge it to
> blender2.8
>
> As simple as that :)
>
> = Next steps =
>
> Don't have much to be added here, just am open for discussions and opinion
> form active developers about such a move.
>
> Might also be missing something important here.
>
> But in any case, let's give a whirl of discussion :)
>