AMDG On 05/01/2013 08:15 AM, Felipe Magno de Almeida wrote:
I also need something like this. I don't see much difference from using boost::ref and defining my copying and value semantics to not take the attributes into account as my documented semantics
So I really don't see what the problem is. While algorithms might get confused, this is directly related to the semantics given, which might be different from type to type that is erased. That is no difference, to me, from creating a specific wrapper with different copying semantics.
The difference is that you're asking me to handle boost::ref in Boost.TypeErasure, regardless of whether it's correct or not. There is no way for me to determine automatically whether handling boost::ref is safe.
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. Therefore the correct way to handle this is to design your concepts in such a way that they accept boost::reference_wrapper, pointers, etc. In Christ, Steven Watanabe