Markus Werle wrote:
A document "The design and evolution of boost::XXX" would boost C++ development even more than using the library itself. This is why boost rules say the documentation must contain a design rationale (wink, wink).
You mean like this? http://boost-sandbox.sourceforge.net/libs/proto/doc/html/boost_proto/appendi... (wink, wink) I guess I could add a blurb there about the naming convention. <snip>
What about transforms is killing you? Is it something fixable, in your opinion? Or just the steep learning curve?
The steep learning curve only. I am one of those who appreciates lovely step by step explanations like your FOREACH paper. That's how all things should be explained ... yes, I am asking too much here.
I see that transforms will help to implement simplify algorithms, so I really need them. What kills me is to know it is there, but I get no grip on it.
OK, I'll see if I can rework the transformation section to make it more approachable. This is an inherently hard topic, though.
I was just about to request the ban of binary_expr from the docs. For you it is probably nice to have the shortcut, but again this is a shortcut from good old times when expressions had a maximum arity of 2.
That happens not to be the case. And what's wrong with shortcuts?
IMHO the basic expr<> typedef should be provided everywhere in order to ease mental access to the library. I found myself forcing compiler error messages, just to obtain the structure.
Why? There are a lot of largely irrelevant details in the actual type of an expression, like the use of argsN<> and ref_<>. I don't see any advantage in exposing users to all that in the docs, or forcing users to type that in their code.
Please rework "Expression Construction Utilities" such that you simply add the expr<> version where it is missing, e.g. at
// expr_type is the same as this type: typedef proto::binary_expr< MyTag , proto::terminal<int>::type , proto::terminal<char>::type >::type expr_type2;
BOOST_MPL_ASSERT((is_same<expr_type2, expr_type>));
PUT ANOTHER TYPEDEF AND ASSERT HERE OR BETTER: REPLACE
I could do that, but these utilities are provided expressly so that users never have to be troubled with the actual expr<> type, which can be complicated. Like I said earlier, in NONE of the examples does the expr<> type appear. If you're dealing with expr<> directly in your code, you're working at a very low abstraction level. And your code is probably wrong ... there are expression types that are not expr<>, such as a type that uses extends<>. Is it possible that your considerable experience with expression templates is leading you to take too keen an interest in the proto::expr<> type? In Proto, it's largely a detail.
I think this is the beginning of a beautiful friendship :-)
Round up the usual suspects. :-) -- Eric Niebler Boost Consulting www.boost-consulting.com