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

[Howard Trickey]

I agree with pretty much everything Sergey says. Where I work there is a
coding style guide that restricts usage of some C++ languages features.
As its preamble states, "As every C++ programmer knows, the language
has many powerful features, but this power brings with it complexity,
which in turn can make code more bug-prone and harder to read and maintain."

Not suggesting we follow this guide, but reproducing it here so that others
might read (if interested) some arguments pro and con various restrictions:

https://google.github.io/styleguide/cppguide.html



On Tue, Oct 4, 2016 at 10:44 AM Sergey Sharybin <sergey.vfx at gmail.com>
wrote:

> let's state the obvious: Blender's core is and will be a pure C.
>
> That being said, i'm not buying all this discussions about "a reason to
> prefer C++ over C". Choise over C as a core is something you should just
> leave with.
>
> I'm also not buying statements like "standard way of doing FOO in C++".
> Shall we then drop our hash tables in favor of STLs even tho we know STL
> implementation isn't really great?
>
> If we go deeper inside technical aspects of data ownership, it's all owned
> by a Blender's core side, meaning it's all C. This should close all the
> discussion of proper resource management in C++.
>
> I'm not sure what pollution of global scope here is. Static function is not
> living in the global scope.
>
> Benefit of NOT using lambdas is that you (a) have a proper meaningful name
> (b) can write proper documentation of what's happening (c) makes diffs more
> clear.
>
> Surely if it's one single case of lambda things aren't getting that messy,
> but this things goes out of control real quick and all of a sudden you have
> function where you pass 4 lambdas 10 LOC each. And then all a sudden you
> end up adding an explicit comment what that lambda is doing instead of just
> using function with a descriptive name. As a side effect, your function
> call becomes 3 displays long.
>
> Going into such situation is something we MUST to forbid.
>
> As for limiting the amount of features. Not all of the new stuff from new
> language standards helps readability, some of them even defeats overall
> Blender design. We have to come to a reasonable subset of things which
> lives seamlessly within the Blender design.
>
> On Tue, Oct 4, 2016 at 4:12 PM, Jörg Müller <nexyon at gmail.com> wrote:
>
> > 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 :)
> > >
> >
> > _______________________________________________
> > Bf-committers mailing list
> > Bf-committers at blender.org
> > https://lists.blender.org/mailman/listinfo/bf-committers
> >
>
>
>
> --
> With best regards, Sergey Sharybin
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers
>