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 _______________________________________________ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
