From: Douglas Gregor (gregod_at_[hidden])
Date: 2004-02-18 18:51:25
On Tuesday 17 February 2004 07:25 pm, Brian McNamara wrote:
> Indirect Functoids
>
> This is perhaps the most Boost-redundant feature of the library. FC++
> indirect functoids do almost the same thing as boost::function objects.
> The differences:
[reordering]
> - indirect functoids don't work with non-const reference parameters,
> whereas boost::function object do
> - indirect functoids can't be "null", whereas boost::function objects
> can
My inclination is that these two really don't matter all that much. They are
convenient, perhaps, but not a reason to keep funN and boost::function
separate.
> - indirect functoids are imbued with "full functoid" features
Hmmm, what would this involve? I know that we would need to implement an
operator() that supports currying and an operator[] that supports the Lambda
stuff. I suspect that a careful reading of the fullN class templates would
answer all of my questions, but I haven't gotten there yet.
I could see having a macro like "BOOST_FUNCTION_FCPP_SUPPORT" (possibly
defined by the FC++ headers before including boost/function.hpp, for
instance).
> If FC++ were accepted into Boost, my gut tells me that in the
> long-term, indirect functoids would naturally disappear (by getting
> absorbed by boost::function).
This would make me happy. I like FC++, but am (and have been---I think we've
discussed this before) a little concerned about the fact that we're
introducing a lot of nearly-redundant bits into Boost.
Doug