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

Subject: Re: [boost] [system][filesystem v3] Question about error_code arguments
From: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2009-10-20 14:45:09

Beman Dawes wrote:
>
> They are talking about a filesystem library binding at least loosely
> based on Boost.System, Boost.Filesystem, and C++ TR2.

Good!

> In looking at
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2838.html,
> "Library Support for Hybrid Error Handling (Rev 2)", they are
> concerned about specifying hybrid error handling like this:
>
>      void f(error_code& ec=throws());

When avoiding exceptions, that leads to this code:

   error_code error;
   f(error);

> They would rather see it specified like this:
>
>      void f(error_code* ec=0);

   error_code error;
   f(&error);

As Scott McMurray noted, the call doesn't transfer ownership and isn't polymorphic.  However, using a null pointer to indicate the absence of something is idiomatic as Peter Dimov noted.  From a purely esthetic point of view, I prefer not having to take the address of the error_code to call such a function.

> 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.  Given that this scheme will be standardized, it is quite reasonable to think that compiler vendors will apply suitable magic to eliminate the performance downside (auto-generate overloads, for example).

> Although the reference form is usual for C++, the use of anything
> other than the default is limited, and usually in low-level code at
> that. Although I could personally live with either form, I'm leaning
> slightly toward the pointer form.

I have no experience with such functions, so I can't weigh in on the relative use of the default versus providing an error_code.  Given the widening use cases for this approach, I doubt there is a general case one can cite.  (Certainly those coding in environments without exceptions would bias the numbers.)

In summary, I favor the reference interface so long as there is no mention of a null reference, provided compiler vendors think it can be done optimally.  Otherwise, I can live with the pointer interface.

_____
Rob Stewart                           robert.stewart_at_[hidden]
Software Engineer, Core Software      using std::disclaimer;
Susquehanna International Group, LLP  http://www.sig.com

IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.