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:56:11

Stewart, Robert wrote:
> Beman Dawes wrote:
> 
>> 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. I wasn't at the meeting where the
>> LWG asked that a null reference be mandated; my reading of the
>> standard is that it is unclear if returning a null reference is or
>> isn't undefined behavior. Some of the core folks seem to think it
>> is undefined, but compilers accept it.
> 
> As with others, this makes me very uncomfortable.  I'd prefer that it
> be worded as an unspecified reference and that dereferencing it would
> result in undefined behavior.  However, that begs the question: how
> does the function determine whether to throw an exception.  If
> throws() returns an error_code instance that throws when the error is
> set, then there's no need for a null reference.  Unfortunately, that
> has a performance downside: the function must be called and the
> temporary must be created or a reference to a global object must be
> created for all calls that use the default.  A null pointer default
> must be cheaper.

I think the performance cost of checking a reference or pointer for 
validity and checking some property in the error_code instance will be 
the same. After all, in both cases it comes down to a single comparison 
of two integers. Even if referencing the global default instance does 
add overhead, I bet it is negligible.