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.
proto mailing list