|
Boost : |
From: David B. Held (dheld_at_[hidden])
Date: 2002-05-21 14:43:25
"Peter Dimov" <pdimov_at_[hidden]> wrote in message
news:004e01c1fe4b$5e9240d0$1d00a8c0_at_pdimov2...
> [...]
> Can't the design be improved?
Maybe.
> Small changes in behavior should correspond to small changes
> in implementation, or to put it another way, less code.
I guess that depends on what constitutes "small changes". ;)
In this case, one problem is that two data members are stored
(both the mutex ref itself, and a bool for safer locking/unlocking).
But really, I'm afraid the Storage policy is as small as possible.
It encapsulates the locking behaviour that Bill designed, which
includes the ability to lock/unlock arbitrarily. If this feature were
removed, it would be possible to write something like this:
// Storage Policy template
template <typename Resource, typename Acquire, typename Release>
class basic_resource
{
protected:
typedef Resource stored_type;
typedef bool pointer_type;
typedef bool& reference_type;
typedef Acquire acquire;
typedef Release release;
explicit basic_resource(stored_type const& r)
: resource_(r)
{
acquire(resource_);
}
void swap(basic_resource& rhs)
{ resource_.swap(rhs.resource_); }
public:
friend inline pointer_type get_impl(basic_resource const& lock)
{ return true; }
friend inline reference_type get_impl_ref(basic_resource const& lock)
{ return true; }
protected:
void destroy()
{ release(resource_); }
private:
stored_type& resource_;
};
// Storage Policy for scoped auto lock
template <typename Mutex>
class lock_storage : public basic_resource<
Mutex&,
&lock_ops<Mutex>::lock,
&lock_ops<Mutex>::unlock
>
{
typedef basic_resource<
Mutex&,
&lock_ops<Mutex>::lock,
&lock_ops<Mutex>::unlock
> base_type;
// Are these necessary?
typedef typename base_type::stored_type stored_type;
typedef typename base_type::pointer_type pointer_type;
typedef typename base_type::reference_type reference_type;
explicit lock_storage(stored_type const& mutex)
: base_type(mutex)
{ }
};
This code, along with the proposed move policy base class
should make it a snap to create new auto_resource types with
no_copy, move, or shared semantics, optimal space usage,
and whatever checking/conversion you like. Is this sufficiently
simple?
Dave
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk