Boost logo

Boost :

From: William Kempf (sirwillard_at_[hidden])
Date: 2000-09-14 12:47:13


--- In boost_at_[hidden], Eric Swanson <ESwanson_at_I...> wrote:
> What I'd like to see is a lock template something like this one.
Yes, the
> placement new solution used by unsafe_lock<> works, but it sure
seems to me
> like it's digging too deep into the bag of tricks.

There's reasons to prefer this over your suggestion, which I'll get
to later. The point I'd make here, though, is that this is an
implementation detail of unsafe_lock<>. This means several things.
For one, the fact that placement new is "icky" is irrelevant here,
since it's buried in the implementation. For another, this means
that a different implementation of the same interface may very well
not use placement new (in fact, your example is just such an
alternate implementation). In other words, since we're discussing
prototypes here the implementation details are mostly off-topic at
this stage. They are only on-topic as the discussion pertains to
possible need for modification of the concepts. My implementation,
whether you like placement new or not, is proof that a modification
of the concepts is not needed or warranted.
 
> It might be useful to take a cue from the STL: stack<>'s 'Cont c'
member is
> protected, not private.

I really don't understand why the STL did this. stack<> is not
designed for polymorphic behavior (no virtual d-tor) so the only
benefit this safely buys is the ability to access the container in
protected/private derivation. I don't see how this could apply to
our current discussion.

> Due to the exclusivity of the mutex interface, it
> seems unlikely one would be able to write a lock template like this
one
> without either a) hacking mutex.h, or b) using placement new, which
seems
> hackish to me.

Don't think in terms of implementation. Think in generic terms of
the concepts. This means that (a) isn't really an option. Every
concrete implementation of the Mutex concept will have to have a
corresponding implementation (specialization?) of unsafe_lock<>.
Meanwhile, (b) is proof that a generic implementation of
unsafe_lock<> can be built solely using the Concept, with no reliance
on any implementation details.

> It might be useful to have some sort of 'mutex_accessor'
> class so that implementing a new lock<> template wouldn't require
adding a
> friend to the mutex class (or using placement new).

A mutex_accessor<> would simplify development of various lock types,
but it would also expose the very methods that are so dangerous on a
mutex to begin with. You might as well expose those methods directly
on the mutex.

> template <typename M>
> class basic_varlock

[snip]

This is unsafe_lock<> to a T, it just uses friendship instead of
placement new in the implementation. This leaves me with a question
and then an explanation of why I'd prefer the placement new "hack".

Why call it basic_varlock<>? I can understand the basic_ prefix, but
varlock makes no sense to me. In any event, I prefer "unsafe"
over "var" to add psychological emphasis that this is not the
preferred lock.

As for why I prefer placement new... it's wholly generic. It doesn't
require specialized coding when a programmer adds a new
implementation of a Mutex concept, nor does it impose any further
requirements on the implementation beyond those required by the
concept. The feeling that it's "hackish" is irrelevant, since it's a
hidden part of the implementation.

Bill Kempf


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