Re: [boost] boost::proto possible bug

From: Maurizio Vitale (mav_at_[hidden])
Date: 2007-05-05 11:38:18

Eric Niebler <eric_at_[hidden]> 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