Maurizio Vitale wrote:
Eric Niebler <eric@boost-consulting.com> writes:
Tough questions. You've touched on a weakness of proto. I hope to make improvements in this area after BoostCon ...
I think proto is a very nice addition to boost, and I'm sure with a few touches to make it easier to use for applications different from what it has been designed for it can get rapidly to the point it can be submitted formally.
Fair. This particular area certainly needs improvement. But are you also referring to your desire for something like proto::eval() to work even when you don't have an expression object to evaluate? I don't consider that a common use case.
Do you have a timeframe in mind for this?
Sometime after BoostCon. That's all I can say right now.
An improvement to the return type would be:
proto::expr< my_plus , proto::args2< typename proto::as_arg<Left>::type , typename proto::as_arg<Right>::type >
const
I have quickly tried this and it doesn't seem to work: as it is gcc complains about as_arg not defining a type in boost::proto (which surely looks like it is from the headers). But indeed as_arg is the right thing here, so I'll try some more.
Sorry, try: typename proto::result_of::as_arg<Left>::type
- a simple example for this would be very nice for the documentation. Agreed.
Please include how to make those new constructs displayable. You need something like:
struct my_plus {}; inline char const *proto_tag_name(my_plus) { return "my_plus"; }
It is important that proto_tag_name is defined in the same namespace as my_plus, otherwise it won't be found (Koenig lookup).
Sure.
In my case my_plus is outside proto::tag and things seem fine with a mix of tags inside and outside the proto::tag namespace, but it would be nice to have this confirmed and spelled out in the docs.
Yes, the tag type doesn't need to be in the proto namespace. -- Eric Niebler Boost Consulting www.boost-consulting.com