Re: Re: [boost] Re: Next revision of boost::thread

From: William E. Kempf (wekempf_at_[hidden])
Date: 2003-01-09 11:44:45

> From: "Stefano Delli Ponti" <stefano.delliponti_at_[hidden]>
> From: "William E. Kempf" <wekempf_at_[hidden]>
> > > From: "Stefano Delli Ponti" <stefano.delliponti_at_[hidden]>
> > > From: "David Abrahams" <dave_at_[hidden]>
> > > > "William E. Kempf" <wekempf_at_[hidden]> writes:
> > > >
> > > > > That's a good idea.  So would users prefer new exception types here,
> > > > > or should I use the std:: exceptions?
> > > >
> > > > IMO, it's always safer to use an exception type which provides
> > > > more-specific information.
> > >
> > > Agreed. And we should keep coherence with the filesystem library.
> >
> > I'm not sure there's any coherence to keep here.  Do you have specific
> concerns/thoughts here?
> 
> I was thinking about keeping similar design patterns between these two
> libraries.
> (because they are conceptually similar as they both give a portable view of
> operating system functionalities).
> So if we use domain specific exception in the filesystem library, the thread
> library should follow the same pattern too. The same for the issue of
> conditional compilation.

I'll look at this closer, but the domains are different enough that I'm not sure there's anything that carries over.

As for conditional compilation... the Boost.Filesystem stuff has no need for this, while Boost.Threads has a very definate need.
 
> BTW I prefer having the same set of methods, some of them returning default
> values for platform without the support for the underline concept.
> Sometimes this could not be possible. ACE for instance uses a different
> approach.

Again, dummy stubs won't work in all cases.  A better example than I've already given is the attribute to make a mutex visible across process boundaries.  Not all platforms will support this, and if they don't a stub that returns an error or throws an exception is doing a great disservice to the developer, since he should know at compile time that this platform can't handle this, since there's nothing he can do at run time to compensate for the lack. 

William E. Kempf
wekempf_at_[hidden]