[system][filesystem v3] A possible error_code argument compromise

2009/10/20 Beman Dawes <bdawes@acm.org>:
One particular concern is that as currently worded, the N2838 proposal requires throws() return a null reference, which they see as relying on undefined behavior.
So it sounds like the idea solution is something that looks like a reference to the caller, for shortness of typing, but looks like a pointer to the implementation, to ease checking and avoid the weirdness of null references. struct optional_error_code_ref { optional_error_code_ref() : p_() {} optional_error_code_ref(optional_error_code_ref const &ecr) : p_(ecr.p_) {} optional_error_code_ref(error_code &r) : p_(&r) {} error_code &operator*() const { return *p_; } error_code *operator->() const { return p_; } operator safe_bool() const { return safe_bool(p_); } private: error_code *p_; }; Then the call is done the same was as before: error_code ec; foo(ec); But it's obvious to check, and never deals in null references: void foo(optional_error_code_ref ec = optional_error_code_ref()) { ... if (ec) { ec->value = bar; } else { throw bar_exception(); } ... } It would of course be better spelt qux<error_code&>, but I'm not sure exactly what name that should be. ~ Scott (Hopefully the subject change will get us out of the exceptions vs error codes quagmire.)

Am Tuesday 27 October 2009 15:13:21 schrieb Scott McMurray:
struct optional_error_code_ref { optional_error_code_ref() : p_() {} optional_error_code_ref(optional_error_code_ref const &ecr) : p_(ecr.p_) {} optional_error_code_ref(error_code &r) : p_(&r) {} error_code &operator*() const { return *p_; } error_code *operator->() const { return p_; } operator safe_bool() const { return safe_bool(p_); } private: error_code *p_; };
It would of course be better spelt qux<error_code&>, but I'm not sure exactly what name that should be.
boost::optional<error_code&>? optional does have implicit conversion and the rest of your public interface. optional<T &> is implemented as a container of T & plus a bool though, but I see no reason not to create a boost::optional specialization that implements optional<T &> by holding a pointer that's exposed as a reference in the interface.

2009/10/27 Stefan Strasser <strasser@uni-bremen.de>:
boost::optional<error_code&>? optional does have implicit conversion and the rest of your public interface.
Ah, good. I hoped it did, but I got confused by the Optional References page in the docs.
optional<T &> is implemented as a container of T & plus a bool though, but I see no reason not to create a boost::optional specialization that implements optional<T &> by holding a pointer that's exposed as a reference in the interface.
Which I suppose brings us right back to the question of whether null references are legal, since that (worthwhile) optimization is only valid if they're illegal.
participants (2)
-
Scott McMurray
-
Stefan Strasser