From: Eric Niebler (eric_at_[hidden])
Date: 2008-03-17 20:35:41
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?
I guess I could add a blurb there about the naming convention.
>> 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
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:
> , proto::terminal<int>::type
> , proto::terminal<char>::type
> 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk