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

Subject: Re: [boost] [system][filesystem v3] Question about error_code arguments
From: Thomas Klimpel (Thomas.Klimpel_at_[hidden])
Date: 2009-10-20 12:01:06

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.
> ...
>
> Although I could personally live with either form, I'm leaning
> slightly toward the pointer form.
>
> Regardless, I'd like to hear Boosters views on the two interfaces
> above. Which do you prefer? Why?

I don't know the details, but I also would prefer the pointer interface. "null reference" reminds me of somebody actually checking against a null reference:

void f(int& r) {
  if (&r) // check whether r is a null reference
    ... ;
  g(&r);
}

I have no problem if "r" could be undefined, i.e. somebody called "f(*p);" with a "p" that is null or undefined. I also don't have a problem if "g" checks the pointer it is passed in against null. However, if "f" itself checks its argument against being a null reference, then I'm disappointed. As another poster said: "I thought one of the selling points of references was they can't be null."

I could probably live with returning an "undefined reference", and if somebody prefers this "undefined reference" to actually be a null reference to simplify debugging, why not. But as soon as he explicitly checks the reference against actually being a null reference, I think he is doing something wrong.

Regards,
Thomas