On 2/25/11 2:24 PM, Thomas Heller wrote:
On Fri, Feb 25, 2011 at 7:08 AM, Joel Falcou<joel.falcou@lri.fr> wrote:
On 25/02/11 03:21, Joel de Guzman wrote:
:-) Mathias has a point. Let's also discuss this off-list. With Spirit, I've already begun the migration towards an object free environment, but that's for terminals --of which proto is known to slow down compilation when there are lots of terminals. I am not quite sure about function objects.
I want to point you again tomy boostcon 2k10 talk. we showed figure where the old nt2, using instance of function object , resulted in a linear compile time, while having template function using make_expr get us constant compile time.
Here the post I made way before on the same issue: http://lists.boost.org/boost-users/2009/02/45591.php <snip>
You have a point for proto terminals. A phoenix::function is _not_ a proto terminal though. here is a sketch of the implementation:
template<typename Func> struct function { template<typename A0 ... typename AN> typename proto::result_of::make_expr<tag::function, Func, A0, ..., AN> operator()(A0 const& a0, ..., A1 const& a1) const { return proto::make_expr<....>(....); } };
It already behaves like the proto generator functions you described. Maybe the instantiation of a phoenix::function<F> also add significantly to compile time and binary size. These were the numbers I was interested in.
Exactly. Phoenix functions are not proto terminals. I agree with Thomas, I'd like to see the numbers first before jumping to a conclusion. Regards, -- Joel de Guzman http://www.boostpro.com http://spirit.sf.net