On Tue, Oct 20, 2009 at 12:56 PM, Andrey Semashev <andrey.semashev@gmail.com> 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.