Re: [boost] [review] Fast track formal review of Forward library begins today

From: Giovanni Piero Deretta (gpderetta_at_[hidden])
Date: 2007-12-05 05:27:15

On Dec 3, 2007 10:57 AM, John Torjo <john.groups_at_[hidden]> wrote:
> Hi all,
>
> The formal review of the Boost.Functional/Forward library, proposed by
> Tobias Schwinger, begins today :
>
>      * What is your evaluation of the design?

Good. Simple enough to cover most needs.

In my design I allow the user to specify if a specific operator()
overload should be disabled or not (depending on the arity and the
parameter types); It is useful if you are using more than  one
forwarder in some complex composition (i.e. as base classes) and you
need to disable ambiguous overload. I do not think
Boost.Functional/Forward should necessarily provide this
functionality, but it might be considered.

I think too that the library should optionally allow K more arguments
which are all const or non const. For (uncommon) very high arity
functions that need to be wrapped, you can usually live with this
limitation.

>      * What is your evaluation of the implementation?

Looks simple, but it is hard to evaluate preprocessor meta code.

>      * What is your evaluation of the documentation?

Complete enough.

I think it should be explicitly specified that the wrapped function
object must be result_of
compatible (if such a note is already present, I've missed it).

A discussion of the impact of the library on compile time (especially
with high values of N) would be useful.

Also a comment on the (potentially lack of) runtime performance
penalty imposed by the library would be nice.

>From the documentation I cannot infer if operator() is overloaded for
both const and non const 'this'. I think not (), but it should be
specified explicitly.  I have never needed this in practice, In fact,
IMHO it should be specified that 'this' is always const.

>      * What is your evaluation of the potential usefulness of the library?

Extremely useful. This is wheel which has been reinvented many and
many times. Boost should be the supply a prepackaged solution.

>      * Did you try to use the library? With what compiler?

No.

>        Did you have any problems?

N/A.

>      * How much effort did you put into your evaluation?
>        A glance? A quick reading? In-depth study?

A quick reading of the documentation and of the implementation.

>      * Are you knowledgeable about the problem domain?

Yes, I'm one of those which had to reimplement the wheel :).

>
>      * Do you think the library should be accepted as a Boost library?

Definitely!

gpd