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

Subject: [boost] [system][filesystem v3] A possible error_code argument compromise
From: Scott McMurray (me22.ca+boost_at_[hidden])
Date: 2009-10-27 10:13:21

2009/10/20 Beman Dawes <bdawes_at_[hidden]>:
>
> 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.)