Boost logo

Boost :

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.)


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk