Boost logo

Boost :

From: Beman Dawes (beman_at_[hidden])
Date: 2000-08-10 07:35:56


William Kempf wrote:

>> > [lots on a generic approach]
> ...
>>Ahhh... the light goes on. Sorry, I've not seen this approach to
>design. When "generic programming approach" was stated I took this
>too mean the implementation should be done through templates. The
>generic approach from this document seems to mean that the
>implementation is not defined at all, and only certain parts of the
>interface are specified. The "mutex" may not be a template, but the
>mutex concept is applicable to varying concrete types that may be
>used in templates. Do I have this right?
>
>The documents look nice, and I like the approach taken for the
>try_lock. I'm still curious if a timed_lock should be considered.
>The benefit of a timed_lock over a try_lock is that the CPU
>utilization can be vastly reduced for some constructs on some
>platforms. Yes, that's starting to get specific to the
>implementation, which I don't want to do, but it still seems a valid
>question.

Take at look at the Feature Modeling and Domain Analysis techniques
described in the book Generative Programming by Czarnecki and Eisenecker.

Quoting them, "It is important to keep in mind that anything users or
client programs might want to control about a concept is a feature. Thus
during feature modeling, we document not only functional features ... but
also implementation features [that a client might want to control]. In
this aspect, Domain Analysis is different from classical software analysis,
where the usual rule is to avoid analyzing any implementation issues."

In terms of this discussion, feature modeling could be used to identify
features prior to applying the generic programming approach. It really is
OK to talk about implementation features like recursive and non-recursive
mutexes if these are important to users. Note that the issue of when a
feature choice binds is separate.

--Beman


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