Boost logo

Boost :

From: Rob Stewart (stewart_at_[hidden])
Date: 2005-05-05 15:39:42


From: "Peter Dimov" <pdimov_at_[hidden]>
> Beman Dawes wrote:
> > "Rob Stewart" <stewart_at_[hidden]> wrote in message
> > news:200505041425.j44EPnrb027885_at_weezy.balstatdev.susq.com...
> >
> >> status_flag status(path const &, int * error = 0);
> >>
> >> It is simpler from an implementation standpoint, but I don't
> >> think it is simpler from the caller's perspective. Since the
> >> argument is defaulted, the compiler will offer no help to ensure
> >> that you get and inspect the error number.
> >>
> >> Returning a type with the flags and error number together means
> >> that you always get the error number and can inspect it. Whether
> >> you use any schemes to ensure that the caller inspects a non-zero
> >> error number -- such as asserting in the destructor if an
> >> "inspected" flag isn't set -- is another matter.
> >
> > That seems like a convincing argument.
>
> Typical uses:
>
> if( status( p ) & file_flag ) // ...
> if( status( p, &e ) & file_flag ) // ...
>
> vs
>
> if( status( p ).flags & file_flag ) // ...
>
> status_result r = status( p );
> if( r.flags & file_flag ) // ...
>
> I don't see much of a difference here.

I'm assuming an operator & for the UDT status_result:

   if (status(p) & file_flag) ...

vs

   if (status(p) & file_flag) ...

If you actually use the error code:

   status_error e;
   status_result r(status(p, &e));
   if (!e && (r & file_flag)) ...

vs

   status_result r(status(p));
   if (r && (r & file_flag)) ...

Another advantage to returning a UDT is that the bitwise OR and
(in)equality operators can throw an exception on error,
effectively forcing the above usage to avoid an exception.

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

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