Boost logo

Boost :

Subject: [boost] [system][filesystem v3] A possible error_code argument compromise
From: Scott McMurray ([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_); }
        error_code *p_;

Then the call is done the same was as before:

    error_code 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, gregod at, cpdaniel at, john at