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

Tue Oct 4 19:37:05 CEST 2016

Hi Sergey,

I wrote what I (and others, judging from Howard's link) honestly thought
would be good practice. I do not count myself as C++feature-happy but these
features I found extremely helpful in my work and I use them quite often. I
can give workarounds for the issues you mentioned but it doesn't matter: I
am not contributing to the project anymore, others do, so feel free to
adopt whatever makes you feel safer and more comfortable.

On 4 October 2016 at 18:24, Howard Trickey <howard.trickey at gmail.com> wrote:

> 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
> >
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers
>