Re: [boost] [TypeErasure] references
On Mon, Jul 30, 2012 at 2:51 PM, Chapman, Alec <archapm@fas.harvard.edu>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
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
On Wed, May 1, 2013 at 6:18 PM, Steven Watanabe <watanabesj@gmail.com>wrote:
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
participants (2)
-
Felipe Magno de Almeida -
Steven Watanabe