Question

First, I’m wondering if both “feature” have the same goal.
Secondly, if yes (or only partially yes), is there any significant limitation in boost proto over
c# expression tree

thanks

Answer 1

I’m the author of Boost.Proto, and I only recently discovered C# expression trees. AFAICT, they are similar in intent, but different both in implementation and scope.

C# has language support for capturing a LINQ expression as a dynamically typed tree. This is used by LINQ consumers to optimize the evaluation of queries. A query against an in-memory data structure would be a straightforward evaluation via the LINQ extension methods, but one against a remote database would be more optimally executed by walking the LINQ expression at runtime, computing a T-SQL string, and passing it to the SQL server for remote execution. As it currently stands, C# expression trees are best at these kinds of optimization problems.

Boost.Proto OTOH has a somewhat broader scope. Proto expression trees are statically typed, allowing complex transformations and code generation to be done at compile-time. More importantly, Proto provides tools for introspecting and transforming trees, and generating custom code from them. That could be useful for optimization, but also for giving expressions completely different domain-specific semantics. So Proto is more accurately thought of as an embedded domain-specific language toolkit.

The same could be done with C# expression trees, but AFAIK there currently exists no framework for tree transformation and code generation. The ability to do runtime code generation on .NET makes this a compelling possibility. Maybe some enterprising developer (you?) would be willing to write a Proto# on top of C# expression trees. 🙂