On 6/4/2012 5:51 PM, Mathias Gaunard wrote: > On 04/06/2012 17:52, Eric Niebler wrote: > >> 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. > > I want all tree manipulation and transformation algorithms to see the > value as if it were a T and not a shared_ptr<T> or ref_holder<T>.
OK, I see. > shared_ptr<T> is the right type to contain the terminal in the proto > nullary expression, but in that particular case it is not the logical > type of the value associated to that leaf node. > > I want to be able to manipulate the tree using straight Proto tools > (otherwise I might as well not use Proto at all -- the point is to have > a well-defined de-facto standard framework for tree manipulation). I understand your frustration. > Those algorithms should not need to know how the value is stored in the > expressions. It is just noise as far as they're concerned. > > Alternatively I'll need to provide substitutes for value, > result_of::value and _value, and ban those from my code and the > programming interface, telling developers to use mybettervalue instead > of proto's. That saddens me a bit. I want you to understand that I'm not just being obstructionist or obstinate. Proto's value functions are very simple and low-level and are called very frequently. Adding metaprogramming overhead there, as would be necessary for adding a customization point, has the potential to slow compiles down for everybody, as well as complicating the code, tests and docs. There are also unanswered questions. For instance, how does proto::matches work with these terminals? Does it match on the actual value or the logical one? There are arguments on both sides, but one needs to be picked. Going with the logical value will force proto::matches to go through this customization point for every terminal. I also am thinking about how it effects other proto features such as: as_expr, as_child, make_expr, unpack_expr, literal+lit, fusion integration, display_expr, fold and all the other transforms, etc. etc. I worry that allowing the logical type of a terminal to differ from the actual type opens a Pandora's box of tough question with no obvious answers, and trying to add this would cause unforeseen ripple effects through the code. It makes me very uneasy, especially considering the workaround on your end (sorry) is very simple. Making proto's user's happy must be balanced against feature-creep-ism, which hurts everybody in the long run. So I'm afraid I'm still leaning against adding this customization point. But I encourage you to file a feature request, and if you can find a patch that doesn't negatively effect compile times or end user-complexity and integrates cleanly with all the other features of proto and has docs and tests, then -- and only then --- would I add it. -- Eric Niebler BoostPro Computing http://www.boostpro.com _______________________________________________ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto