Re: [boost] [function types][review] (repost with new formatting)

From: David Abrahams (dave_at_[hidden])
Date: 2005-06-13 18:37:55

Rob Stewart <stewart_at_[hidden]> writes:

> From: David Abrahams <dave_at_[hidden]>
>
> Thanks for the repost.  I, too, can read it now.
>
>> >   Motivation
>> >
>> >   Applying metaprogramming to increase the flexibility of software
>> >   design often involves the inspection and manipulation of function
>> >   types.
>> >
>> >   A very common application is the automatic generation of callback
>> >   facilities which occurs frequently in Boost libraries, such as Bind,
>> >   Lambda, Phoenix and Function.
>> 
>> This is a very weak opening.  A person reading the Motivation section
>> wants to know, "what would I do with this library?"  I suggest
>
> Absolutely right.
>
>> something like:
>> 
>>   Generic libraries that accept callable arguments are common in C++:
>>   STL, Boost.Lambda, Boost.Function, and Boost.Python are just a few
>>   examples.  Analysis and manipulation of built-in function types
>>   seems to appear in each one.
>> 
>> The above is by no means perfect, and it took me 5 minutes to write.
>> It can be hard to follow Mr. White's advice ;-)
>
> I question why you say "seems to appear."  It should be possible
> to state it definitively, right?

Only if you're referring to the libs listed and not all the generic
libs that accept callable args.  So if you can clarify that, be my
guest.

> That aside, this is still lacking.  It tells me that powerful
> tools that one might consider black boxes need the functionality
> of this library, but says nothing about why the reader may.

I can only think of needing this library if I were going to build a
generic library that accepts callable arguments.  Whether or not that
is a powerful black box is a matter of opinion I guess.

>> "With one exception, each component is defined in a header file whose
>> name is the same as that of the component, with an .hpp suffix.  For
>> example, before using is_function_type, your functions should first
>
> s/functions/code/

Right.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com