$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
From: timatdvc (timw_at_[hidden])
Date: 2002-02-18 10:45:06
After reading your paper, there may not be any difference at all, 
except in minor technical differences and granularity.  In your 
approach, you are specifying individual policy classes, which I think 
makes a lot of sense when dealing with low-level components such as 
iterators or smart pointers.
My focus was more on situations where one would be providing larger-
scale highly-configurable libraries.  I think requiring clients to 
make configuration decisions for such a library by providing low-
level policies is akin to asking someone who wants a car to pick the 
alternator, starter, belts, spark plugs, etc...  Rather, at this 
level, a client should be able to make high-level configuration 
decisions that do not necessarily map to individual policies, but may 
in fact result in many policies being selected.  So in that sense, I 
don't think that what I described is at all at odds with your 
approach, but more a kind of insulating layer to hide such lower-
level configuration details from a client, thereby simplifying the 
use of a complex library.
Actually, if one took named template parameters using enumerated 
values, this would be a good description of what I used to pass 
configuration information to the generator.  The selected (or 
default) options would then result in the actual policies being 
selected.  Good paper, by the way!  Wish I'd found it sooner.  Makes 
me feel a bit like I've reinvented a wheel... ;)
+tim
--- In boost_at_y..., "David Abrahams" <david.abrahams_at_r...> wrote:
> How does this compare with what Jeremy did in the iterator adaptors 
library
> with named template parameters?
> 
> ----- Original Message -----
> From: "timatdvc" <timw_at_d...>
> To: <boost_at_y...>
> Sent: Monday, February 18, 2002 9:26 AM
> Subject: [boost] Combining Generative Programming and Policy-Based 
Design