Eric Niebler a écrit :
With SFINAE, the error your users are likely to see is something like "No such function f(A,B)" followed by an exhaustive list of potential matches. Then your users are left to figure out for themselves why none of those functions are a good match.
In my experience, a message like "E doesn't match the grammar G" is simpler, often shorter, and has the benefit of taking your users to a single line in your code where you can stick a big comment describing *why* the compile-time assertion failed.
That's a very valid position. So basically, a good ol'MPL_ASSERT_MSG where it fits is better.
To figure it out, just count template instantiations. You're building a new expression type, so you can't avoid instantiating those types. But make_expr is itself a template, and you can avoid that cost.
Indeed, I just did the math and the comparison (went down from 9 to 3s)
There's one more thing I wanted to say about this. No, it doesn't defeat Proto's purpose. Proto provides high-level facilities so you can do a lot in just a little code. This is very important when you are just starting out with your DSEL and your code is in flux. Use those high-level facilities to keep your design fungible. When you're happy with your design, *then* you can go back and optimize for compile times by replacing some of the more expensive facilities with more efficient lower-level ones.
A good example of this is transforms. Joel is using composite transforms (object and callable transforms, specified with function types) when building Spirit2x. It makes the code very small and nimble, and he can easily change his mind and make radical changes at this stage. When things are stable, he'll go through and replace all the composite transforms with custom primitive transforms to improve compile times. Does that mean composite transforms are useless? Not at all. The fact is that I was running my own DSL for years now using hand made code and lots of those 'low level' structures. I first saw Proto as a 'end-all' solution. I obviously miss the largest benefit of Proto design which is indeed going down low level when needed. OK, things are sensibly clearer now. Using the low level constructor was something I thought was frowned upon. Guess I was wrong. I'll then wait for my design to stabilize, cope with compiel-time for a few and do as you said. Thanks you very much.
Thanks for this valuable insight. -- ___________________________________________ Joel Falcou - Assistant Professor PARALL Team - LRI - Universite Paris Sud XI Tel : (+33)1 69 15 66 35 -- ___________________________________________ Joel Falcou - Assistant Professor PARALL Team - LRI - Universite Paris Sud XI Tel : (+33)1 69 15 66 35