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

Kévin Dietrich kevin.dietrich at mailoo.org
Tue Oct 4 13:58:04 CEST 2016


Le 2016-10-04 12:51, Sergey Sharybin a écrit : 

Hi, 

I'm all in for the upgrade.

> 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). 

> - 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(); 

> Things i can be convinced for:
> 
> - Enum classes

Downside is having to overload the binary operators if you intend to use
the enum as bitflags. But they don't hurt. 

> - Variadic templates (man, will make some OpenCL area in Cycles so much
> more cleaner!)

I don't use them that much, not sure if I did in real code, but they are
useful, and I would vote for. 

> - Static assert. I'm using it in Cycles, wouldn't mind if it's used more.

I wouldn't mind either. 

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

Cheers, 
Kévin


More information about the Bf-committers mailing list