Re: [boost] [TypeErasure] references

Subject: Re: [boost] [TypeErasure] references
From: Felipe Magno de Almeida (felipe.m.almeida_at_[hidden])
Date: 2013-05-01 11:15:12

On Mon, Jul 30, 2012 at 2:51 PM, Chapman, Alec <archapm_at_[hidden]>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