Subject: Re: [proto] Hold terminals by "smart" reference
From: Mathias Gaunard (mathias.gaunard_at_[hidden])
Date: 2012-06-06 02:09:04
On 05/06/2012 20:38, Eric Niebler wrote:
> 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
The change required to provide this feature is to replace the
implementation of value from
and of course to change the specialization of (basic_)expr<Tag,
term<Arg>, 0> accordingly.
That is all. I'm not sure this complicates the code, albeit for good
measure it would be nice to avoid the use of the name proto_child0 for
the type of the terminal, too.
> There are also unanswered questions. For instance, how does
> proto::matches work with these terminals?
I'm not terribly familiar with how proto::matches works, but if it uses
the proto_grammar typedef, then it could be made so that it wouldn't
notice any difference.
> 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 doubt any of these rely on specific implementation details of
basic_expr<Tag, term<Arg>, 0>, so they wouldn't be affected.
> 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.
No problem, I thought it would have been an interesting addition.
Proto list run by eric at boostpro.com