Boost logo

Boost :

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


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

Boost list run by bdawes at, gregod at, cpdaniel at, john at