Re: [Boost-users] [review] Formal Fast-Track review of the Boost.Functional/Factory library - extended until sunday
shunsuke wrote:
John Torjo wrote:
Hi all,
I've extended the review until Sunday (inclusive). I'm hoping for more reviews. So far, we've had only two. If you are interested in the library (you should be :)), please take some time to review it. This is the info you need to do a review on:
*Description*
Factories are callback mechanisms for constructors, so we provide two function objects, boost::value_factory and boost::factory, that encasulate object construction through direct application of the constructor or operator new, respectively. These templates make other facilities that operate on function objects (such as standard algorithms, Boost.Bind, Boost.Function, or Fusion functional adapters) applicable to constructors.
Is there any difference to lambda::constructor/new_ptr?
Yes, those components are designed to only work with the Lambda library. Functional/Factory OTOH provides standard compliant (they work with result_of and the libraries built upon it) function objects. Regards, Tobias
Tobias Schwinger wrote:
Is there any difference to lambda::constructor/new_ptr?
Yes, those components are designed to only work with the Lambda library. Functional/Factory OTOH provides standard compliant (they work with result_of and the libraries built upon it) function objects.
BTW, Boost.Lambda can support result_of without modifying its source code.
#include
shunsuke wrote:
BTW, Boost.Lambda can support result_of without modifying its source code.
#include
// imaginary header for now. namespace bl = boost::lambda; // result_of conforming FunctionObject bl::bind( bl::constructor< boost::shared_ptr<int> >(), bl::bind(bl::new_ptr<int>(), bl::_1) )
If interested, I think I can upload result_of.hpp.
Sounds good to me - but it isn't up to me to decide. You should probably repost this suggestion with '[lambda]' in the subject or file a feature request with a patch for that library's authors to pick it up. IIRC there was a planned merger of Lambda and Phoenix2. Itseems you have some time to contribute ITM and your "Egg" library showssome experience in that domain. I'm CCing Joel as he might be interested in your help. Getting "Factory functionality" out of the Lambda library does not deprecate the utility we are reviewing: Using Boost.Lambda just to create a single class instance seems sorta wasteful. Factory's greatest strength is its simplicity: We can easily make it compile (and optimize decently) even with legacy compilers and it's lightweight in terms of dependencies and template instantiations. Regards, Tobias
Tobias Schwinger wrote:
If interested, I think I can upload result_of.hpp.
Sounds good to me - but it isn't up to me to decide.
You should probably repost this suggestion with '[lambda]' in the subject or file a feature request with a patch for that library's authors to pick it up.
I will.
IIRC there was a planned merger of Lambda and Phoenix2. Itseems you have some time to contribute ITM and your "Egg" library showssome experience in that domain. I'm CCing Joel as he might be interested in your help.
I'm not sure I can help, but I'm sure I know all the compiler bugs around result_of. :-)
Getting "Factory functionality" out of the Lambda library does not deprecate the utility we are reviewing: Using Boost.Lambda just to create a single class instance seems sorta wasteful. Factory's greatest strength is its simplicity: We can easily make it compile (and optimize decently) even with legacy compilers and it's lightweight in terms of dependencies and template instantiations.
I agree Boost.Lambda makes compiling slow. (Actually I have my own Factory-like utilities.) Regards, -- Shunsuke Sogame
participants (2)
-
shunsuke -
Tobias Schwinger