[openbeos] Re: B_TRUE/B_FALSE

  • From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
  • To: openbeos@xxxxxxxxxxxxx
  • Date: Mon, 22 Sep 2003 01:25:20 +0200 CEST

Tyler Dauwalder <tyler@xxxxxxxxxxxxx> wrote:
> Well, see, here is where we differ :-) :-P. I like the ssize_t return 
> method. 

I also don't like it too much - mostly, because it often hides a 
possible bug in the implementation as in:
ssize_t read(char *buffer, size_t bufferSize);
bufferSize must not have the upper bit set, or else this function would 
have problems returning the correct value. I think that's certainly 

> somewhere to pass in as the output parameter. Further, references are 
> so 
> non-existent in the Be APIs, pointer output parameters tend to get 
> used 
> instead, which means you have to do an extra NULL check in the 
> function 
> that's being called. And no, this isn't a terrible amount of work, 
> but it's 
> the kind of inconvenience that leads people to just return an 
> overloaded bool.

Sure, but there is no point in *not* using reference parameters - most 
of the time, they are better suited for that kind of job anyway.

> I guess my overall train of thought is this: 
> 1. For trying to write solid code, I don't like functions that can 
> fail that 
> don't return an error code.

Me neither.

> 2. IMO, people will more often opt for overloading the meaning of a 
> bool 
> return value than going to the trouble of using an output parameter, 
> both 
> because it's more work to implement a function that uses output 
> parameters, 
> and more work to use one.
> 3. Our current policy is "return values, not exceptions (unless 
> absolutely 
> necessary)", so exceptions are out.

Right, for a public API, that's not really an option at this moment.

> 4. Having B_TRUE/B_FALSE plus bstatus_t or whatever would make it 
> convenient 
> to return something in {true,false,error}, while still being 
> unambiguous. The 
> same thing is currently done for returning something in 
> {size_t,error} 
> through the use of ssize_t return values, which I feel is a 
> relatively 
> elegant and practical solution given the issues addressed above.

Yes, it might not be a bad idea - but I think the approach using a 
reference parameter is cleaner most of the time.
If it would be used for comparison once only, the boolstatus_t would be 
a convenient way. Often, though, those values would have to be stored 
for later use, and I would really hate code like this:

boolstatus_t resizeStatus = partition->IsResizable();
if (resizeStatus < B_OK)
        return resizeStatus;

if (resizeStatus == B_TRUE)
        isResizable = true;
        isResizable = false;

In that case, I would rather like to see:

status_t status = partition->IsResizable(isResizable);
if (status < B_OK)
        return status;

with an optional "&" before the isResizable :-)


Other related posts: