Re: [boost] iterator adaptor named parameters

From: Vesa Karvonen (vesa.karvonen_at_[hidden])
Date: 2001-06-04 00:39:44

I'm using a similar approach in my resource library. I have not found
major problems with the approach.

I'm currently considering making a tool that would take an extended
feature model (with defaults, constraints and some other details) and
generate the (list based) configuration DSL and parser from it. The
current feature model of the resource library is becoming large enough
that such a tool would make sense. (I can imagine that the final feature
model of my container library requires the tool.) The translation process
itself is quite trivial and repetitive and seems like a good candidate for
automation.

I'll probably post details on the extended feature modeling grammar to the
Boost list in a couple of days.

----- Original Message -----
From: "Jeremy Siek" <jsiek_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Sunday, June 03, 2001 23:21
Subject: [boost] iterator adaptor named parameters

>
> Here's what I think we should do with the iterator adaptor
> named parameters.
>
> Instead of the nested templates scheme, I think we should have the user
> specify the name using a wrapper class for each parameter. The wrapper
> class names would correspond to the parameter name, with something like
> "_p" at the end to mean "parameter" and to avoid name clashes. The usage
> would look like this:
>
> boost::iterator_adaptor<Iter, Policy,
>   boost::reference_p<T&>, boost::value_type_p<T> >
>
> The normal non-named parameter usage would still be supported of course.
>
> The implementation creates a type-list out of the parameter wrappers
that
> basically acts like an associative list, with the key being a tag class
> that identifies the parameter, and the value being the argument type.
When
> an argument is passed in without a wrapper, this is detected and the
> wrapper is added before inserting into the type-list. Then there's some
> meta-code that searches through the type-list for each parameter, and
then
> resolve any defaults.
>
> I just finished implementing this approach, seems to work pretty well
and
> is a bit simpler than the previous approach, and of course avoid the
> problem of the "template" keyword showing up all over the place.
>
> Does this sound like an acceptable solution?
>
> Cheers,
> Jeremy
>
>
> ----------------------------------------------------------------------
>  Jeremy Siek                        www: http://www.lsc.nd.edu/~jsiek/
>  Ph.D. Candidate, IU B'ton          email: jsiek_at_[hidden]
>  Summer Manager, AT&T Research      phone: [phone]
> ----------------------------------------------------------------------
>
>
>
> To unsubscribe, send email to:
<mailto:boost-unsubscribe_at_[hidden]>
>
>
> Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/
>
>
>