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

Mike Erwin significant.bit at gmail.com
Thu Oct 6 18:42:16 CEST 2016

Approach B then, no exceptions!

Not personally a fan of exceptions. Much prefer code that is designed with
few or no opportunities to fail at runtime. Document possible failure cases
and make it the caller's responsibility.

Is anybody here talking about converting all C and C++ code to C++11? I
thought we were just talking about the C++ parts & raising the library /
compiler requirements.

C is not "old" and C++ is not "new". Both languages are great. Both
languages also have a history with plenty of old techniques and habits that
are not helpful in modern software development.

I abandoned C++ for several years and chose C99 for my own projects, until
catching up with C++11 ~2 years ago. Between C++98 and C++11 obviously go
with 11. There's no reason to choose between C99 and C++11 though. Both are
modern languages with good compiler support across platforms.

Mike Erwin
musician, naturalist, pixel pusher, hacker extraordinaire

On Thu, Oct 6, 2016 at 9:57 AM, Ichthyostega <prg at ichthyostega.de> wrote:

> On 04.10.2016 11:15, Sergey Sharybin wrote:
> > 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.
> On 04.10.2016 16:43, Sergey Sharybin wrote:
> > let's state the obvious: Blender's core is and will be a pure C.
> Hi Sergey,
> after reading this thread, it looks like the "elephant in the room"
> has not been mentioned. Regarding C++ this is the use of exceptions.
> Exceptions are one of the most beneficial features of modern C++
> BUT only if you go whole circle, and that means to use RAII *everywhere*.
> I have seen several times, that when you really go that path, the code size
> shrinks to about one third, the code becomes a thousand times more clean
> and
> readable and a lot of painstaking long-standing quality issues just resolve
> into thin air. This is a huge productivity boost, and in comparison, the
> good
> old C-style of resource management is just a huge waste of developer
> effort.
> BUT, as said, this only works if you're able to go that path totally.
> And I have seen numerous instances, where people switched half-heartedly
> and where not able to let go with the "good" old C habits. In that case,
> exceptions are a dangerous poison, and have the potential to kill a code
> base.
> You'll soon find every place littered with cascades of try-catch blocks and
> you'll be haunted by occasional random segfaults, which are near
> impossible to diagnose or fix.
> Thus I'd recommend to use either one of the following, and never mix
> things up.
> Approach-A:
>  - do *all* error handling with exceptions
>  - disallow the use of raw pointers. Wrap *every* resource into a RAII
> object
>  - disallow the use of try-catch blocks. In code review, request a proper
>    justification for every single catch.
> Approach-B:
>  - disallow the use of exceptions entirely
>  - disallow the use of smart-pointers, since they are pointless now and
>    might lure people into a programming style which can be dangerous and
>    simply does not work with such a setup.
> Since we all know the existing code base of blender and our existing
> developer resources, the second approach looks more viable.
> -- Ichthyo
> _______________________________________________
> 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