Re: [boost] expected/result/etc

On 2/12/2016 1:39 AM, Emil Dotchevski wrote:

On Thu, Feb 11, 2016 at 9:02 PM, Michael Marcin 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.