Re: [boost] expected/result/etc

Subject: Re: [boost] expected/result/etc
From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2016-02-12 02:39:53

On Thu, Feb 11, 2016 at 9:02 PM, Michael Marcin <mike.marcin_at_[hidden]>
wrote:

>
> You likely routinely use "unsafe" code that can lead to UB in the presence
> of programming errors.
>
> Do you use std::vector operator[] in your code?
> Do you use std::vector iterators?
>
> Maybe you always use std::vector at() to access elements.
> If so then I understand your reluctance to deal specify UB.
>

This is not about safe or unsafe code, it's about preventing logic errors.
I'm not arguing that vector::op[] should throw. Actually I'd say that it's
a bug to call vector::at. :)

Writing high performance code requires you to *think*.
> In C++ we embrace UB when it is "The Right Thing".
>

I embrace it where it is appropriate, yes.

> You can certainly add a debug layer to result that can help diagnose
> problems (mark if the result was tested for containing a value or error is
> some way and assert if it was accessed without such a test).
> Much as Microsoft's STL debug iterators are a helpful tool.
>
> But I don't want to pay for them in retail builds.
>

Good, I don't, either.

> There's no way I'm going to throw an exception because a raytrace hit an
> intersection limit when I need to maintain a consistent 90hz stereo
> rendering or risk making my users literally ill. Still it's an error and
> needs to be handled gracefully.
>

And I'm arguing that whether you throw or not should rarely be a question
of performance. If hitting the intersection limit in a raytracing program
leads to an invalid frame, you should report that error by throwing an
exception. This has zero performance cost if functions are being inlined,
which they are at the lowest levels of a raytracer. Generally, if you can
afford the "if" statement to detect the error, you can afford to throw.

> If I can't the interface and implementation I want and need out of a
> standard or pseudo standard library then I'll have to roll my own but it's
> a shame how often I have to do that. It's a large part of why STL and Boost
> have terrible reputation in my industry and are outright banned in many
> companies.

In ~20 years in the video game industry I have never needed to implement my
own STL, and modern STL implementations are a lot better than in the old
days. On the other hand years ago I did have to refactor a company's
home-grown STL replacement to fold templates to reduce bloat, since
otherwise the executable was over 20 megs on a platform with 32 megs of
RAM. Ironically, the STL on that platform was folding the templates
automatically. Too bad they had it banned.

Emil