Re: [Boost][Outcome] Compile error?

From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2020-07-06 14:13:50

On 05/07/2020 19:41, Emil Dotchevski via Boost wrote:

> On exception_ptr, my original thinking (more than 15 years ago) was this:
> the parts of Boost Exception that could be used to call
> boost::throw_exception should work under BOOST_NO_EXCEPTIONS, but since
> exceptions can't be thrown, there's no reason why anyone would want to hold
> a pointer to one.

What about make_exception_ptr()?

There is a long story behind that function and whether it ought to work
with exceptions globally disabled or not. Basically, many years ago, I
reported to those STL implementations which were still implementing it
as a throw...catch, instead of direct construction, benchmarks showing
the hideous performance of not using direct construction. The
maintainers of said STL implementations did not think it important
enough to fix, but to my best knowledge, they have all since fixed that.
This reduces the cost of std::make_exception_ptr() from 30k CPU cycles
to about 3k CPU cycles, big gain if you do a lot of those.

I'd pitch the same thing to you: thanks to make_exception_ptr(),
exception_ptr is quite useful with exceptions globally disabled.

>> You're the first person to ever raise a need for a
>> outcome/boost_result.hpp which does not include Boost.Exception.
> 
> From my point of view, I was compiling an example that used outcome::result
> and was surprised that it didn't work under BOOST_NO_EXCEPTIONS. Even if we
> change boost::exception_ptr to work under BOOST_NO_EXCEPTONS, should
> outcome::result be coupled with it?

I propose two paths forward:

1. Boost.Exception gains an exception_ptr which works fine with
BOOST_NO_EXCEPTIONS.

2. Boost.Outcome disables use of boost::exception_ptr when
BOOST_NO_EXCEPTIONS is enabled.

I'm easy with either choice. But I think the former "nicer".

Also, for the record, about 70% of my users use result<> with error or
enum codes, perhaps 20% use exception_ptr, the remaining 10% use a
custom type. Those who use exception_ptr are quite vocal, however.

BTW if you are thinking of Boost.Exception improvements, that report
going around for why Boost libraries cannot be epoch-ised, it said the
only blocker for Outcome was its dependency on Exception. So, if
Exception could be epoch-ised, so could Outcome.

Me personally I give that whole proposal a very low priority, but while
we're talking etc etc

Niall