On Mon, Jul 30, 2012 at 2:51 PM, Chapman, Alec wrote:

On 7/26/2012, 5:45 PM, Chapman, Alec wrote:

...

...

The problem is that there are significant differences between references and values. This is okay for Boost.Function, because Boost.Function doesn't expose ant mutating operations. However, in the more general case this behavior is too error prone. Just think about what would happen if we allowed using boost::ref for any_iterator. Some Algorithms assume that they can make copies of iterators and that these iterators are independent of each other.

These are exactly the sorts of algorithms I have in mind. What I am suggesting is that the original object is held by reference, but when a copy is made the underlying object is copied as well. With your method I do not see a way to capture by reference and then pass that object to an algorithm that does not have special logic to handle Boost.TypeErasure.

Perhaps the false parallel with Boost.Function would be confusing. I have also done it by overloading the constructor with a dummy parameter:

int i = 0; any<requirements> x(i, type_erasure::as_reference); // x holds a pointer to i any<requirements> y(x); // y allocates a new integer and initializes it with i ++y; // i is still 0

Hi Steven, Have you had a chance to consider this? Please let me know if something I'm suggesting isn't clear or if there is already a way to achieve this with your library.

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. 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.

Alec

Regards, -- Felipe Magno de Almeida