On Wed, May 1, 2013 at 6:18 PM, Steven Watanabe
AMDG
On 05/01/2013 08:15 AM, Felipe Magno de Almeida wrote:
[snip]
Your argument about any_iterator is valid because a forward iterator that doesn't save its position is not a forward iterator at all, but that's not true for all concepts. And using boost::ref by the user and implementing a non-ForwardIterator directly is no different. And creating specific wrappers will be a pain for these concepts that allow the implementation to use pointer/references. Using the _self& is no use for these concepts, since the whole point is to type erase, having multiple types to implement the same concept with a type-erased interface won't scale at all.
Support for smart pointers and naked pointers would be a great plus as well.
using boost::ref is safe iff. boost::reference_wrapper<T>
can be considered a model of the concept.
Yes.
Therefore the correct way to handle this is to design your concepts in such a way that they accept boost::reference_wrapper, pointers, etc.
Do you mean algorithms in such a way that they accept boost::reference_wrapper, pointers, etc? If so, that's how I already do it for these concepts where I want to use boost::ref with type_erasure. But if I use type_erasure, my algorithms won't receive boost::reference_wrapper or pointers because it will use type_erasure::any. What I need is to be able to use type_erasure::any the same way as generic algorithms that accept boost::reference_wrapper, but I can't do it with type_erasure::any as is. Only by creating a specific model with the same semantics as reference_wrapper as a proxy to the real implementation and use this proxy to construct the type_erasure::any, which is not great because I wanted the user to decide how it should be handled and automatically convertible to type_erasure::any.
In Christ, Steven Watanabe
Regards, -- Felipe Magno de Almeida