Boost logo

Boost :

Subject: Re: [boost] [system][filesystem v3] Question about error_code arguments
From: OvermindDL1 (overminddl1_at_[hidden])
Date: 2009-10-20 15:30:23


On Tue, Oct 20, 2009 at 12:56 PM, Andrey Semashev
<andrey.semashev_at_[hidden]> wrote:
> 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.

I prefer a references interface from ease of use, however it should
never have a null pointer. Why not have two functions of the same
name, one takes a reference, the other a pointer, thus you can handle
both cases and enforced that the reference cannot be null.


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