From: Andy Little (andy_at_[hidden])
Date: 2004-11-14 17:35:36
"Doug Gregor" <dgregor_at_[hidden]> wrote in message
The formal review of the Named Parameters library by David Abrahams and
Daniel Wallin starts today and runs until Monday, November 22nd.
- What is your evaluation of the design?
Overall I like the idea of named parameters, basically because they are an
aid to code legibility as staed in the docs. Anything that provides in place
documentation is extremely useful facility. Therefore In contrast to the BGL
approach I think this is more legible. I am assuming that the BGL approach
must uses member functions in some class ruling out the assignment style
syntax, and presumably requiring the class to be written, so this must be
more 'generic'.... After trying out the library to see if it might help make
initialisation of a transform matrix more legible. (Note obviously more
efficient to pass in the matrix as a non const reference, but the legibility
starts to suffer. OTOH Ideally It woould be nice to use something similar to
named params in a constructor... but I assume that the lib wont support that
?. However at the end of the day Some equivalent to this libraray might
actually be more useful in constructors than for functions )
//bgl style ?
tx_matrix<units> t = make_matrix(
tx_matrix<units> t = make_matrix(
translation = xy_pair<units>(units(1),units(1)),
rotation = angle::rad(1),
scaling = .5
I come to the conclusion that the second format is aesthetically better than
the first, which I guess covers the design. I cant see a better way to do
- What is your evaluation of the implementation?
As far as looking into the implementation is concerned I was interested to
see a custom list used. I guess there are good reasons for this, but I
thought mpl and tuple were designed for this type of job?. Whatever I dont
really have the experience to make any assessment of the implementation
The Helper macro BOOST_NAMED_PARAMS_FUN is very useful as far as it goes. Of
course in the make_matrix function above the return type would be a template
type. Obviously the macro cant deal with that or can it?, which is annoying
as implementing the thing manually is relatively time consuming. OTOH I have
no idea what the alternative might be though. Although it makes life easy
for users, at the implementation level a fair amount of work is required
once you stray from simple use.
- What is your evaluation of the documentation?
Well I followed through on the examples and finally got it to run. It is
slightly *amusing* to keep writing the code for the examples and then be
told 'but of course that doesnt work' (2.3 Defining the implementation
- What is your evaluation of the potential usefulness of the library?
I think it is very useful for increasing source code legibility. Though bear
in mind that a reasonable amount of time needs to be spent by the
implementor to make the users life easy ( I suspect the
BOOST_NAMED_PARAMS_FUN MACRO doesnt work except in the simplest cases). No
gain no pain I guess..
- Did you try to use the library? With what compiler?
Tested on VC7.1
Did you have
I had some problems with the boost::mpl::_ widget ... but I guess this
shouldnt be used with the BOOST_NAMED_PARAMS_FUN macro.. not further
explored for lack of time. The SFINAE looks like it may get quite hairy,
where a number of types need to be restricted, though I'm not sure that this
cant be done simply by using enable_if in the return type of the
- How much effort did you put into your evaluation? A glance? A quick
reading? In-depth study?
I played around for an hour or so.
- Are you knowledgeable about the problem domain?
If the domain is function parameters ... I guess I use them from tine to
As always, please remember to clearly state whether you believe the
library should be accepted into Boost.
Review Manager, Named Parameters library
Unsubscribe & other changes:
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk