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

Antony Riakiotakis kalast at gmail.com
Tue Oct 4 15:59:54 CEST 2016


As Kevin wrote above, RAII is one of the main reasons to prefer C++ over C
and unique_ptr is the main STL mechanism that supports this. If people do
not do any weird ninja stuff such as passing unique_ptrs between scopes or
transferring ownership arbitrarily, this is the standard way of doing
resource management in C++. If we take the argument that unique_ptrs make
the code obfuscating then we should also prohibit freeing of contained
objects in destructors because the free itself won't be visible in client
code therefore the coder will miss it and think we have a memory leak. As
always, good review of code should fix this.

As for std::function and lambdas they can be thought of as generic callback
mechanisms. Lambdas are especially useful because they do not require
polluting the global scope with very small functions and instead you can
have a lambda that is very specific to your task right inside your code.
They are very useful for doing observer pattern implementations and generic
signalling mechanisms. Without lambdas you would have to rely on
inheritance of a generic observer interface, which means polluting your
class declaration with overrides of the observer class. With a lambda, you
just pass a lambda to the observed object, which can then do anything -
call any function, etc.

Just my 2c.

On 4 October 2016 at 14:49, Sergey Sharybin <sergey.vfx at gmail.com> wrote:

> Hi,
> On Tue, Oct 4, 2016 at 2:07 PM, Mike Erwin <significant.bit at gmail.com>
> wrote:
> > On Tue, Oct 4, 2016 at 6:51 AM, Sergey Sharybin <sergey.vfx at gmail.com>
> > wrote:
> >
> > 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.
> >
> Threading/concurrency in C++11 would be platform and std implementation
> dependent. Which is always a major PITA,b because then you would have no
> clue if something is fast or slow.
> It will also introduce yet-another-threading-pool which is also no-good at
> all.
> BLI's threading becomes more comprehensive and bet more improvement will be
> done there for the nodify-everything freak of nature. I would really
> suggest sticking to a single task scheduler every since now.
> > 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?
> >
> Just to keep code clear and understandable. Without situations like "i used
> shared pointer + auto + lambda just because language allows this and it
> looks cool to me".
> I'll be really pushing here the idea that code should be staying clear and
> self-explanatory and explicit, with sane decisions about what to use.
> --
> With best regards, Sergey Sharybin
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers

More information about the Bf-committers mailing list