Re: [boost] Formal Review Request: TypeErasure

Subject: Re: [boost] Formal Review Request: TypeErasure
From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2012-06-07 01:21:22

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