Markus Werle wrote:
Eric Niebler wrote:
proto::X is a function, proto::result_of::X is a metafunction that computes the result type of proto::X, proto::functional::X is the function object equivalent of X, and proto::transform::X is the primitive transform equivalent of X.
I guess that is why I get lost all the time: I read the code in the docs and cannot guess from the name whether this is a typename or a function or whatever and which namespace it belongs.
The docs should use qualification where it could be unclear what a name refers to. I can make a pass through the docs to double-check, but if you can point to the places where a lack of qualification led you into trouble, I'll fix them.
Just a daydream: What happens if it is this way:
proto::X is a function, proto::result_of::X_r is a metafunction that computes the result type of proto::X, proto::functional::X_f is the function object equivalent of X, and proto::transform::X_t is the primitive transform equivalent of X.
Do we loose anything? Do we run into trouble?
Well, it would be inconsistent with established practice within Boost. Fusion, for one, uses a similar naming scheme. Spirit-1 used a naming scheme like the one you suggest (trailing "_p" means parser, trailing "_a" means action, etc.). Spirit-2 is dropping this in favor of namespaces, like Fusion and Proto. I believe that was in response to feedback from Dave Abrahams. Perhaps Dave or Joel could chime in on this issue. <snip> Re: the _argN transforms ...
I assumed they were generated by a macro until BOOST_PROTO_MAX_ARITY ... I was preaching against that (inexistent?) macro. Now I took a look at proto_fwd.hpp and found they are made by hand and stop at 9. So now I really have a problem: what happens if I need an arity of 120?
Ha! I imaging you'll need longer than the heat death of the universe to compile your program, but ... ... you're absolutely right, for the _argN transforms, N should go up to at least BOOST_PROTO_MAX_ARITY. I'll need to add a little PP magic.
struct MakePair : when< function<terminal<make_pair_tag>, terminal<_>, terminal<_> > , make_pair( _arg_c<0>(_arg_c<1>) , _arg_c<0>(_arg_c<2>) ) > {};
is OK for me, but I understand your intention. Those transforms kill me, but I need them.
I don't want my code to hurt or kill anybody. What about transforms is killing you? Is it something fixable, in your opinion? Or just the steep learning curve?
The advantage of those numbers is: proto is a typelist tool. If you see the index you do not mix it up. With _arg I always have this second, where I translate it back to _arg_c<0>, etc. At least during my approach to the docs those aliases did not help me (but I do not fear nested templates).
I see your POV, but I see it a different way ... Proto provides a domain-specific language for processing C++ expression trees. Within that domain, unary and binary expressions are the norm, so I provide abstractions for dealing with them in a more natural (IMHO) way. I'd be interested in other people's opinions.
If those _argN scale up to N=300 or more I will not vote against them. Otherwise if 9 is the maximum, I have a problem with that solution.
Agreed. -- Eric Niebler Boost Consulting www.boost-consulting.com