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 <[email protected]> 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" <[email protected]> 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 > > [email protected] > > https://lists.blender.org/mailman/listinfo/bf-committers > > > _______________________________________________ > Bf-committers mailing list > [email protected] > https://lists.blender.org/mailman/listinfo/bf-committers > -- With best regards, Sergey Sharybin _______________________________________________ Bf-committers mailing list [email protected] https://lists.blender.org/mailman/listinfo/bf-committers
