
On Thu, Mar 18, 2010 at 4:23 PM, Eric Niebler
That is an interesting approach. The two problems I see are:
1) Your use of BOOST_AUTO leaves a bunch of dangling references and creates undefined behavior. As you have it defined, program_generator no longer has the effect of deep-copying the expression tree. Try displaying typeid(p).name() and see, for instance, that the intermediate expressions are stored by reference, and the literal 2 is stored by int const&. Any attempt to use p will likely expode sooner or later. The fix is to deep-copy the expression when you wrap it in program_expr, but a simple deep-copy will break your scheme because every program_variable will be deep-copied too. A simple fix would be to make program_variable<T> a wrapper for a boost::shared_ptr<T>, but ...
2) Your program objects are not thread safe. Since they contain mutable data, you can't stick the program in, say, a boost::function, make a few copies and evaluate them concurrently within different threads. That may not be important to you, but I consider it a pretty serious shortcoming.
I did think about thread-safety. The in-place approach is definitely not thread-safe. But under restricted conditions (single-threaded, evaluated in the same scope as the free variables), and a reasonable optimizing compiler, the performance of this method should approach hand-coded C, no? Manjunath