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

Tue Oct 4 12:51:00 CEST 2016

Hi,

Bastien,

Don't have strong opinion about what to use a split point for the branch.
But it might indeed be a good idea to base it on 2.8 branch. Just to make
things simpler.

You are also correct about GCC-6.

Dalai,

Ah, you're right. So for the allowed parts defeinitely goes:

- Range based loops
- Function bindings
- In Cycles we use scoped lock, so should allow using that but with a
restriction that Blender-side code should stick to BLI for the threading.
- Audaspace uses shared/uniq pointers to my knowledge, so kinda also need
to be allowed. But again: for Blender we need to stick to a strict
ownership of data.

Things i'm against:

- Using shared/uniq pointers all over the place. Get the proper ownership
model!
- Using auto, it's not hard to watch your types and using auto makes code
much more tricky to follow
- Threading related things should be forbidden in Blender side. Use BLI for
that. Single scheduler for the win!
- TLS. It's usually not coming for free. Even worse, will be much less
predictable across the compilers.
- No garbage collection!

Things i can be convinced for:

- Initializer lists
- Enum classes
- Variadic templates (man, will make some OpenCL area in Cycles so much
more cleaner!)
- Static assert. I'm using it in Cycles, wouldn't mind if it's used more.

That's a rough outline. Once again, open for discussion and making it more
official in the wiki.

Don't think it's possible to restrict as a compile option. Just matter of
reviewing code i think. Or using some helper headers (like util_foreach.h).
Can also be done as a part of linter.

On Tue, Oct 4, 2016 at 12:26 PM, Dalai Felinto <dfelinto at gmail.com> wrote:

> Hi Sergey,
>
> > I would really suggest sticking to a minimal allowed feature sets from
> C++11 (see below)
>
> I think you forgot the part explaining which subset of C++11 you would
> suggest to be allowed.
>
> Also, can that said subset be forced via build options (or rather, can we
> make sure using something other than the agreed on will raise errors)?
>
> Cheers,
> Dalai
>
> On Oct 4, 2016 06:58, "Bastien Montagne" <montagne29 at wanadoo.fr> wrote:
>
> > Not being much of a C++ dev, but am all for switching to C++11, that
> > llvm version issue e.g. is starting to be annoying with recent Linux
> > distro…
> >
> > Will start checking on install_deps issues as soon as we have a branch
> > (based on blender2.8 I assume, not master?). Also, iirc starting from
> > gcc6, C++11 is default with this compiler?
> >
> > Bastien
> >
> > Le 04/10/2016 à 11:15, Sergey Sharybin a écrit :
> > > 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
> >
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers
>

-- 
With best regards, Sergey Sharybin