On Tue, Oct 4, 2016 at 6:51 AM, Sergey Sharybin <[email protected]> wrote:
> 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. > +1 for range-based loops. So much easier to write, read, and think about. I've never used function bindings but you explained the need in your first post. +10 for proper 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! > I like auto but am happy to use it in my own projects, not Blender. But C++11 threading / async / concurrency is so nice! As long as BLI offers similar perks... does it? I get the point about single scheduler. Things i can be convinced for: > > - Initializer lists > - Enum classes > I've found these incredibly helpful in other projects. Bordering on essential. I would put constexpr and move semantics in the same "essentials" bucket. > - Static assert. I'm using it in Cycles, wouldn't mind if it's used more. > Also helpful but in fewer situations. Why a limited subset? I'm guessing it's for sanity reasons and not compiler support, as all major platforms have caught up. I worked with a person that just discovered lambdas and was using them in every possible situation... but if a particular C++11 feature is right for the job why not allow it? -- Mike _______________________________________________ Bf-committers mailing list [email protected] https://lists.blender.org/mailman/listinfo/bf-committers
