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 <[email protected]> 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 <[email protected]> > 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 <[email protected]> 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 > > > [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 > > > _______________________________________________ > 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
