Boost logo

Boost :

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,


Boost list run by bdawes at, gregod at, cpdaniel at, john at