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