Boost logo

Boost :

From: Kevlin Henney (kevlin_at_[hidden])
Date: 2000-08-10 11:42:09


In message <00eb01c002ab$401d5060$529260cb_at_yogi>, Mark Rodgers
<mark.rodgers_at_[hidden]> writes
[...]
>So for example we might have
>
>namespace boost {
> // tags - just like iterator tags
> struct lock_tag {};
> struct try_lock_tag : lock_tag {};
> struct timed_lock_tag : lock_tag {};
>
> // traits - just like std::iterator_traits
> template <typename Lock>
> struct lock_traits {
> typedef typename Lock::lock_category lock_category;
> };
>
> // convenience base class - just like std::iterator
> template <typename Category>
> struct lock {
> typedef Category lock_category;
> };
>}
>
>class win32_critical_section
>(
> class lock : public boost::lock<boost::try_lock_tag>
> {
> ...
> };
> ...
>};
>
>For this to work, we'd need to define our concepts so that TryLock
>did actually refine Lock and provided extended capabilities rather
>than different capabilities.
>
>I don't know. Maybe it's just cute and not useful.

I'm not sure I'm with you: I think categories and traits may find their
way in, but from what I can see, most uses are, err, not useful. Locking
tends not to have the same kind of genericity and flexibility as
algorithms and iterators, ie we have many algorithms in the world but
there are only a few rational locking policies.

Can I just clarify, is the nested lock type just a tag? In other words,
does nothing else?
____________________________________________________________

  Kevlin Henney phone: +44 117 942 2990
  Curbralan Ltd mobile: +44 7801 073 508
  kevlin_at_[hidden] fax: +44 870 052 2289
____________________________________________________________


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