AMDG On 06/06/2012 08:25 AM, Hite, Christopher wrote:
My 0.02EUR.
A big issue of type deletion is dealing with storage.
1) Please do a better job of SBO than boost::function. It'd be cool if you let the user pick the SBO size or even configure his own container.
boost::function might have been implemented using shared_ptr, but there would have been issues with stateful f-tors.
I don't have any SBO right now. I will at some point, but I want to make sure that I have the interface completely nailed down before I start getting into messy optimizations like this.
2) On a related note I could see the use of an any_ref type holding only a virtual table pointer and a ref to an object it doesn't own. Just two words no heaping. That pushes the storage problem out to the user.
I think you could do that optimization with a specialization where the 2nd parameter is a ref.
I've supported this since I started this rewrite of my library.
Would the second parameter ever be shared_ptr<_self> ?
3) What about optionality? Should they always use optional<any<> > ? boost::function can be null.
I intended to support this. It looks like I haven't implemented it yet, though.
4) What about and any_base<> + any_derived<> ? Based on several cases where I've seen/done type deletion a common pattern is to define a base class and a templated derived class. boost::asio::detail::op_base+op The technique can be implemented with either function pointers or virtual functions.
If you could provide an elegant way of doing that, it'd be pretty cool. The user is free to store his any_derived<> however he sees fit.
My example is a buffered logging class that takes functor< void (std::ostream&)> and stores them in a linear buffer, which gets flushed out later.
Can that be done in a more formal way?
I don't understand. If you want a base/templated derived class, the easiest thing is just to implement it that way.
5) The library overlaps quite a bit with Concept checking libs. Perhaps you should expose this to the user. You can implement an assert_fits_any<any_type,T> (is a macro better)? You can probably also implement a check_any<any_type,T > metafunction and that lets the user check a type to see if it fits and do something else if it doesn't.
Not possible with the current interface.
6) Could you add an example where it has a call operator like boost::function?
This is callable<R(T1, T2, ...)>. In Christ, Steven Watanabe