Boost logo

Boost :

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.

Boost list run by bdawes at, gregod at, cpdaniel at, john at