Re: [boost] expected/result/etc

Subject: Re: [boost] expected/result/etc
From: Michael Marcin (mike.marcin_at_[hidden])
Date: 2016-02-12 04:25:21

On 2/12/2016 1:39 AM, Emil Dotchevski wrote:
> On Thu, Feb 11, 2016 at 9:02 PM, Michael Marcin <mike.marcin_at_[hidden]>
> wrote:
>>
>> But I don't want to pay for them in retail builds.
>>
>
> Good, I don't, either.

Sorry, I don't follow at all then.

If .get() isn't specified as UB when a value is not ready how are you 
going to avoid the overhead?

Specifically .get() must do *at least* an if statement before returning 
the value.

Are you relying on the compiler to optimize away the check and throw as 
unreachable given an earlier check for an error?

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

Sorry I don't follow.
Are you suggesting that the raytracer should be inlined into every call 
site?

What I think you're saying is that where I want to write code that looks 
like:

result<int> bar()
{
     return std::make_error_code( std::errc::bad_address );
}

int main()
{
     int foo;

     auto _foo = bar();
     if ( _foo ) {
         foo = _foo.get();
     } else {
         foo = 0;
     }

     return foo;
}

I should instead write code that looks like:

int bar()
{
     throw std::system_error(
std::make_error_code( std::errc::bad_address ) );
}

int main()
{
     int foo;

     try {
         foo = bar();
     }
     catch ( std::system_error& e )
     {
         foo = 0;
     }

     return foo;
}

And I should expect equal performance?

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

Your experience differs from my own.

EASTL just (officially) released to much fanfare.
https://github.com/electronicarts/EASTL

It's very easy to find performance problems in even current shipping 
standard libraries.
2 examples:
See what happens when you insert a duplicate key into a std::map VS2015.
Or look towards the 17x perf increase in iostreams float serialization 
coming in VS2015 update 2.