Proto for Boost mailing list page: Re: [proto] Hold terminals by "smart" reference

Subject: Re: [proto] Hold terminals by "smart" reference
From: Eric Niebler (eric_at_[hidden])
Date: 2012-06-04 11:52:43

On 6/3/2012 5:37 PM, Mathias Gaunard wrote:
> On 03/06/2012 18:36, Eric Niebler wrote:
> 
>>> Plus I don't have a good way to distinguish between a terminal of
>>> shared_ptr<T>  and a terminal of T which is held through a shared_ptr.
>>
>> Have you tried a grammar? Something like (untested) proto::terminal<
>> boost::shared_ptr<  proto::_>  >  ?
> 
> That would match expressions of the form (assuming I have binary plus in
> my grammar)
> 
> shared_ptr<T> p1, p2.
> p1 + p2;

I don't understand. p1 and p2 are not Proto terminals, so "p1 + p2"
doesn't make sense. Even if it did, it would build a plus node which
would *not* match the grammar I gave above.

Let's back up. What are you trying to do?

> This is exactly what I do not want. I don't want my grammar to be
> cluttered by implementation details. It makes no sense semantically for
> shared_ptr to be values, it's just a technique used for life time
> management of specific values.
> 
> If I ever introduced shared_ptrs as values in my grammar, they might do
> something entirely different.

OK. If you want to hide the use of shared_ptr, I suggest writing a
custom wrapper class named, say, my_detail::by_ref_holder<T> which
stores a shared_ptr<T> as a data member. You can then choose how you
want to handle terminals of this type.

> To separate this more or less cleanly, I use a special tag for nullary
> expressions where shared_ptr is just an implementation detail, but it's
> still not really satisfying since the value doesn't have the right type
> in the tree.

I don't know what you mean by the "right type". If you want it held by
shared_ptr to manage lifetime, then shared_ptr is the right type, it
seems to me. Or use a wrapper around a shared_ptr, whichever.

-- 
Eric Niebler
BoostPro Computing
http://www.boostpro.com