Boost C++ Libraries: Ticket #5357: system::error_code::operator unspecified_bool_type() should not assume 0 == success.

cc set

viboes — Sat, 25 Aug 2012 08:35:05 GMT

cc viboes added

The code I'm seen in is

      operator unspecified_bool_type() const  // true if error
      {
        return m_val == 0 ? 0 : unspecified_bool_true;
      }

It seems to me we can close this ticket now.

mgruenke@… — Sun, 26 Aug 2012 23:19:43 GMT

Replying to viboes:

The code I'm seen in is

Yes, and that's the problem.

It seems to me we can close this ticket now.

Why is that? The problem has not been addressed.

viboes — Sun, 09 Sep 2012 18:03:36 GMT

Replying to mgruenke@…:

Replying to viboes:

The code I'm seen in is

Yes, and that's the problem.

It seems to me we can close this ticket now.

Why is that? The problem has not been addressed.

Apologies. I didn't understood that the above code was related to a change proposal.

IIUC, you pretend that the proposed change behavior is compatible with the C++11 standard. I don't think this is the case.

A generic library using the current error_code behavior would break when instantiated with an error_category that refines the is_error behavior. So that this is a breaking change that needs more careful documentation.

I will suggest you to post to the std-discussion ML this possible enhancement.

mgruenke@… — Sun, 09 Sep 2012 23:12:50 GMT

Replying to viboes:

IIUC, you pretend that the proposed change behavior is compatible with the C++11 standard. I don't think this is the case.

Pretend is a strong word. In fact, I made no statement about C++11.

On that subject, I think Boost is Boost and the standard library is the standard library. I don't see why Boost can't offer more than what's provided by the standard library, even if it was influenced by a corresponding feature in Boost.

A generic library using the current error_code behavior would break when instantiated with an error_category that refines the is_error behavior.

How would it break? A given bit of code is either using a boost::system::error_code or a std::error_code. They're different types, and whichever is being used, the compiler will correctly instantiate the corresponding check.

I will suggest you to post to the std-discussion ML this possible enhancement.

Last I checked, this was the boost library bug tracker. If the standard library adopted this problematic behavior, I think that's unfortunate but probably too late to change.

However, so long as there's boost::system, an option could exist for those cases where success does not map uniquely to 0. That's why I think this is worth fixing, regardless of what's in the standard library.