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

[Sergey Sharybin]

Hi,

Answers are inlined.

On Tue, Oct 4, 2016 at 1:58 PM, Kévin Dietrich <kevin.dietrich at mailoo.org>
wrote:

> Le 2016-10-04 12:51, Sergey Sharybin a écrit :
>
> > Things i'm against:
> >
> > - Using shared/uniq pointers all over the place. Get the proper ownership
> > model!
>
> Whilst I may agree that shared_ptrs are basically global variables, and
> that their predominant use in libs like OpenVDB is a PITA, I don't
> necessarily think they go against a proper ownership model.
>
> The goal of unique_ptrs, as far as RAII is concerned, is to save your
> ass if you forget to call `delete` (and we both know that happens, same
> as `free`), or if an exception is thrown, to make sure memory is freed;
> then they also force you to be mindful of the lifetime of the objects,
> and since you cannot copy them (operator= is tagged as delete), the
> owner is the one who created them. How does that go against a proper
> ownership model?
>
> So my opinion would be: allowing them but be critical when they appear,
> especially for shared_ptrs ; do a case by case scenario. Ultimately, in
> the case of Blender, you'll need to pass raw pointers between the C and
> C++ interfaces if you have to do so, therefore smart pointers can be
> tricky to manage here. The object_node branch has a good example of that
> (managing a refcounted pointer passed between nodes).
>

Proper ownership: the guy who allocated something is responsible for
deleting the thing. Explicitly. Once it's done using it and not cause some
"delayed" deletion somewhere down the road.

If that causes leaks -- it is to be catched by the allocator. If our
allocator needs tweaks to make it more convenient -- do those tweaks.


> > - Using auto, it's not hard to watch your types and using auto makes code
> > much more tricky to follow
>
> On the contrary, I'm all in for this one. `auto` does not necessarily
> make the code harder to follow. I use it everyday, and can easily follow
> code, even for code I haven't written. `auto` also forces you to always
> initialize the variables, so the type is still known. When dealing with
> heavily templated libraries, like OpenVDB, or ones with a shitload of
> namespaces, like Alembic, `auto` is a breeze too.
>
> I'd rather see (and type!):
>   const auto &first = grid->cBeginOn();
> than:
>   const typename GridType::ValueOnIter &iter = grid->cBeginOn();
>

That's so called lazy coding. `auto` in this code does not make code more
readable at all and causes ambiguity.

One case might be more or less intuitive, but i would rather make it strict
rule over more explanatory code rather than briefer code.


> Also, what about lambdas? I'm a sucker for those.
>

Barely met real need of those.

Just to stress it: the idea of such C++11 transition is to solve some
technical limitations. But there is no goal to use everything possible from
the standard, especially if that doesn't help keeping code clear.

-- 
With best regards, Sergey Sharybin