Re: [Boost-users] [Proto] Storing an Expression Template as a Data Member

Subject: Re: [Boost-users] [Proto] Storing an Expression Template as a Data Member
From: Eric Niebler (eric_at_[hidden])
Date: 2011-01-07 09:12:24

On 1/6/2011 6:48 PM, Hossein Haeri wrote:
> Hi Eric,
> 
>>> MyClass mc(_1 >> &f >> &g >> &h); 
>>> mc.set_input(-61.1);
>>> cout << mc.value();//returns h(g(f(-61.1)))
> 
> Here is my solution:
> 
> template<typename Expr>
> struct MyClass
> {
>   MyClass(const Expr& e): formula_(e) {}
>   double calculate(double d) const
>   {return evaluate(formula_, d);}
> private:
>   const Expr formula_;//***
> };
> 
> #define DEFINE_MY_CLASS(name, exp) MyClass<BOOST_TYPEOF(exp)> name(exp)
> ...
> 
> So that my customers can say:
> 
> DEFINE_MY_CLASS(mc, _1 >> &f >> &g >> &h);
> cout << mc.calculate(-6.1);//prints h(g(f(-61.1)))
> 
> Does the fact that I store formula_ by value (as in line ***) shoot the trouble of dangling references?

No, the problem still exists. You're storing the outer-most node by
value, but all the inner nodes (temporary objects constructed while
building the expression) are held by reference. At the very least, the
constructor of MyClass needs to pass the incoming expression through
deep_copy.

>> I would suggest transforming the expression into a unary
>> function object (see my article on cpp-next.com about function
>> composition), 
> 
> I do follow that series of yours and have to say it's superb! :) I don't see how that's connected though. 

That article takes a sequence of function calls and turns them into a
single callable object. You're taking a sequence of function calls and
are turning them into a callable object.

> So, if you think your suggested solution above would be better than that of mine, I'd be more than happy to see more explanation. Specifically, what are you exactly referring to when you use the term "expression" above? And, leave it if you'd think my solution is good enough... :D

Pros and cons. The solution I had in mind didn't involve the
preprocessor or Boost.Typeof which (on some platforms) is a real, ugly
hack. (But a very useful one, I must admit.) The solution I was
suggesting is more work and would have slightly worse runtime
performance ... type-erasure always involves an indirection somewhere.
It's really a judgment call.

-- 
Eric Niebler
BoostPro Computing
http://www.boostpro.com