Re: [Boost-users] [PROTO] Custom functions, scalar terminal and make_expr vs details::as_expr_if

Subject: Re: [Boost-users] [PROTO] Custom functions, scalar terminal and make_expr vs details::as_expr_if
From: Eric Niebler (eric_at_[hidden])
Date: 2008-11-30 12:28:51

Joel Falcou wrote:
> Eric Niebler a écrit :
>> The first question to ask is if it is really absolutely necessary to 
>> prevent users from creating invalid expressions with 
>> my_custom_binary_func(), or if you can catch the error someplace else; 
>> e.g., when users try to evaluate the expression. Reporting a hard 
>> error later can often yield a better error message then using SFINAE 
>> to prune overload sets earlier.
> OK then, but I don't really want my user face a large template error 
> because they mismatched some binary function arguments when they can 
> have a nice 'no such function F(A,B)' error message instead.

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.

> The solution of enumerating the (expr,expr) (expr,scalar) (scalar,expr) 
> variants is maybe what's needed then ?
> The only problem I see is that enumerating the ternary one will be real 
> long.
>> If you want to improve compile times even more, you can avoid 
>> make_expr entirely and code by-hand what make_expr would do. So, e.g., 
>> the second overload above would be:
>> <snip>
> Why is this faster than calling make_expr ? 

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.

> Even worse, doesn't it 
> defeat the proto purpose ?

What do you want from me?

> Or am I in a situation I have to write dirty code like this and only use 
> Proto as a expression builder ?

I gave you a few options to choose from. I told you which I prefer. Pick 
the one that meets your needs. If you absolutely need this to compile as 
fast as possible, do what it takes to bring down the number of templates 
you instantiate. That might mean eschewing some of the nice high-level 
facilities Proto provides.

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