Re: [boost] [review] Fusion review, finalization

From: Joel de Guzman (joel_at_[hidden])
Date: 2006-05-11 21:50:35

Tobias Schwinger wrote:
> Joel de Guzman wrote:
>> Tobias Schwinger wrote:

> 5. BTW...
> 
>    I found it surprising that "iter->second" didn't work in place of "(*iter).second" 
>    (see lines 456, 485)...

This is tough. operator-> is required to be a member function.
Unfortunately, that would also mean that the type dereferenced
should also be known at compile time. This will ultimately break
the MPL requirement that an iterator pointing at the *end* should
not be dereferenced-- that's what will happen by the very act of
computing the operator->'s return type.

Nullary (non-templatable) member functions such as this and
operator() with no args are such PITAs! If I have a wish for C++0x,
one would be to allow them to be templated non members. In Phoenix,
I had to go through hoops just to disable_if the nullary operator().
Eager evaluation wreaks havoc! Look:

     typename
         mpl::eval_if<
             typename Eval::no_nullary
                // avoid calling apply_actor when this is true
           , mpl::identity<detail::error_expecting_arguments>
           , apply_actor<eval_type, basic_environment<> >
         >::type
     operator()() const;

Eval::no_nullary has to search the expression tree! A compile-time
expensive operation!

Unfortunately for Fusion iterators, I can't find a suitable workaround
to enable operator-> return type deduction only when appropriate. In
general, an iterator does not know if it is at the end.

Regards,
-- 
Joel de Guzman
http://www.boost-consulting.com
http://spirit.sf.net