Re: [boost] [system][filesystem v3] Question about error_code arguments

Subject: Re: [boost] [system][filesystem v3] Question about error_code arguments
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2009-10-20 14:32:01

Scott McMurray wrote:
> 2009/10/20 Beman Dawes <bdawes_at_[hidden]>:
>> Regardless, I'd like to hear Boosters views on the two interfaces
>> above. Which do you prefer? Why?
>>
> 
> Since it's neither polymorphic nor ownership-transferring, I really
> dislike the pointer version.
> 
> Now, I have no idea how error_code is specified, but I thought it
> would have been something like this, which wouldn't require null
> references:
> 
> struct error_code {
>     static const int throw_instead = ~0;
>     error_code(int c = 0) : code_(c) {}
>     int code() const { return code_; }
>     error_code &operator=(int c) {
>         if (code_ == throw_instead) throw system_exception(c);
>         code_ = c;
>         return *this;
>     }
>   private:
>     int code_;
> };
> 
> error_code throws_object(error_code::throw_instead);
> error_code &throws() { return throws_object; }
> 
> That said, I'd much prefer the pointer version to anything that
> requires that implementation code check whether the address of a
> reference is null, despite my distaste at having to pass &error all
> over the place.

+1, null references are a really weird idea, IMHO. We should not 
introduce such precedent in the language support library, especially 
since there is an alternative solution that achieves the same result in 
a natural way.