Manuel Jung wrote:

Eric Niebler wrote:

...

I'd like to merge Proto from trunk to release. The API is stable, the tests are now passing on most toolsets (though it's hard to see from the test results at the moment because of a Boost.Test bug), and much of the review feedback about the docs has been accommodated. I still plan to make doc improvements before 1.37, but I don't think that should hold up the show.

OK to proceed?

Hey,

Could you give a pointer or a list, what changed in the trunk?

Lots changes in trunk all the time. What are you referring to? The recent problems with Boost.Test? Changes to Proto? Something else? -- Eric Niebler BoostPro Computing http://www.boostpro.com

Manuel Jung wrote:

Eric Niebler wrote:

...

Manuel Jung wrote:

...

Could you give a pointer or a list, what changed in the trunk?

Lots changes in trunk all the time. What are you referring to? The recent problems with Boost.Test? Changes to Proto? Something else?

Oh, I mean the changes to Proto since the review.

A lot has changed. First the simple things: * Proto lives at boost/proto/, not boost/xpressive/proto * boost/proto/proto.hpp now includes all of proto with the exception of the typeof registrations. That includes the contexts, the transforms and the debugging utilities. If you just want the core of proto without the other stuff, there is boost/proto/core.hpp * s/posit/unary_plus/ * s/arg/child, s/arg_c/child_c/, s/_argN/_childN * s/bind/lazy/ * s/_visitor/_data/ * The proto::transform namespace is no more. * There is a new _default transform, that is analogous to the default_context. Some bigger changes: The protocol for defining a primitive transform has changed. Previously, primitive transforms were just ternary function objects like this: struct MyTransform : proto::callable { template<class Sig> struct result; template<class This, class Expr, class State, class Data> struct result<This(Expr, State, Data)> { typedef ... type; }; template<class Expr, class State, class Data> typename result<void(Expr, State, Data)>::type operator()(Expr const &expr, State const &state, Data &data) const { return ...; } }; You would now write this as: struct MyTransform : proto::transform<MyTransform> { template<class Expr, class State, class Data> struct impl : proto::transform_impl<Expr, State, Data> { typedef ... result_type; result_type operator()( typename impl::expr_param expr , typename impl::state_param state , typename impl::data_param data ) const { return ...; } }; }; With proto v4, the Expr, State, and Data parameters may be reference types. With v3 they could not. Along with the change to the transform protocol comes the ability to leave off the state and data parameters when invoking a transform. With v3, you had to pass dummy state and data parameters, even if your transform didn't need them. In a related change, when using result_of to calculate the return type of a transform, you need to think about the constness and lvalue-ness of the arguments you pass. So instead of: result_of<MyTransform(E, S, V)>::type you might have to say result_of<MyTransform(E const &, S const &, V &)>::type Finally, the behavior of result_of::child_c (formerly known as result_of::arg_c) has changed. It is now sensitive to const and reference. Old ------------------------------------------ 1) result_of::arg_c<Expr, N>::type 2) result_of::arg_c<Expr, N>::reference 3) result_of::arg_c<Expr, N>::const_reference New ------------------------------------------ 1) result_of::child_c<Expr, N>::type 2) result_of::child_c<Expr &, N>::type 3) result_of::child_c<Expr const &, N>::type These are some internal changes that probably should affect anybody: * ref_ is no more. Children are held by plain reference, not by reference wrapper. * s/args0/term, s/argsN/listN/ That's it, I think. The result is a *much* more expressive, powerful and optimal system of transforms. -- Eric Niebler BoostPro Computing http://www.boostpro.com

Is proto also in trunk? Sean. -----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Eric Niebler Sent: 16 September 2008 19:39 To: boost@lists.boost.org Cc: Markus Werle Subject: Re: [boost] [ATTN Beman] request permission to merge Proto torelease Markus Werle wrote:

Eric Niebler <eric <at> boost-consulting.com> writes:

...

I'd like to merge Proto from trunk to release.

Thank You, Eric! Could you please drop another message to the ML when the merge has taken place?

I got a private go-ahead from Beman and just merged Proto to release. So Proto will be part of 1.37 unless something truly catastrophic happens. -- Eric Niebler BoostPro Computing http://www.boostpro.com _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost __________ Information from ESET NOD32 Antivirus, version of virus signature database 3446 (20080916) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com __________ Information from ESET NOD32 Antivirus, version of virus signature database 3446 (20080916) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com

I got a private go-ahead from Beman and just merged Proto to release. So Proto will be part of 1.37 unless something truly catastrophic happens.

Hi Eric, Does this mean you've finished your Proto documentation changes? I still don't see anything about switch_ and case_. Also, I really like the new glossary. Could you add "context" to the definitions? Thanks, Dave Jenkins