Eric Niebler <eric@boost-consulting.com> writes:
Maurizio, I didn't see this message the first time because for some reason, all your messages appear out of order on GMane. Is the clock on your computer wrong? Is it something you can fix?
Should be fixed now. I noticed the problem yesterday when I started backing up to Amazon S3.
Maurizio Vitale wrote:
I don't know if it is a bug or not, but I was surprised by the effect of a seemingly minor code change.
<snip>
So I said to myself: let's get rid of all those operators and replace them with a single templatized version, like:
template <typename Expr> struct my_expression : proto::extends<Expr, my_expression<Expr>, my_domain> { typedef proto::extends<Expr, my_expression<Expr>, my_domain> base_type;
my_expression (Expr const& expr = Expr()) : base_type (expr) {};
using base_type::operator =;
template<typename T> operator T () const { return static_cast<T>(proto::eval(*this, my_context<Expr> ())); } };
OK, your expression wrapper has an implicit conversion to any type T. That is, IMO, a bad idea, but nevertheless, proto shouldn't stop you from doing that.
The full plan is to later limit to a set of user specified (builtin) types. I cannot boost::enable_if the operator itself, but since I'll need a number of transformations as part of eval (among those quantization and overflow handling), I'll fail with as a meaningful error message as possible somewhere in the pipe. At least this is what I hope. So builtin_type v = expression should pass through the operator T() above, but my_int v = expression should not. I hope this will work without ambiguities, otherwise I'll clearly remove operator T () here. Does the plan still sound bad?
I think I have fixed the problem in CVS.
Thanks a lot.
Incidentally, you were running into an ambiguous conversion deep in the guts of callable_context, which uses an implicit conversion to a hidden type to detect whether your context has an overload of operator() that accepts the current expression. The code now uses a less-preferred conversion, avoiding the ambiguity with yours.
I take this is the explanation why operator T() above had problems. Best regards, Maurizio