On 03/03/2018 21:11, mike via Boost wrote:

I don't claim to understand all the implementation details, so sorry if this is dumb question:

What happened to the idea to encode failure or success in a single bit in the status_code_domain pointer, thus making the check if an operation succeeded trivial even in the type-erased case?

That was a potential workaround for Boost.System to not break existing code. A complete rebuild like doesn't need such hacks. It has a formal empty state for those users who won't risk the cost of a virtual function call. For everybody else, it costs one virtual function call at worst, usually not even that as the compiler will have speculatively inlined the implementation and/or the linker will have implemented the 'final' modifier. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

...

A complete rebuild like doesn't need such hacks. It has a formal empty state for those users who won't risk the cost of a virtual function call.

It might not be necessary, but wouldn't it be a worthwhile optimization regardless?

As I mentioned, it has a formal empty state. No further optimisation is needed. It is as efficient as is possible.

Even in the generic case it would work without any cross-module analysis and should generally make the compiler's task easier. It would also make the checks for failure or success constexpr (not sure if that is typically relevant). Or would it imply problematic tradeoffs?

Unlike with , with the implementation of the domain may be exposed to all translation units using it (i.e. if you use the typed status_code<DomainType>, then by definition DomainType must be visible to all translation units). The compiler generally does the right thing when it can see a 'final' implementation. So if you want maximum optimisation, never use the type erased forms of status_code. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/