Boost logo

Boost :

From: Tobias Schwinger (tschwinger_at_[hidden])
Date: 2006-05-12 18:52:33

Joel de Guzman wrote:
> 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.

*hits hand against forehead* ...and cannot be a template because there are no arguments.

> 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!

Those arbitrary and irregular restrictions on operator
overloading are in general!

> If I have a wish for C++0x,
> one would be to allow them to be templated non members.

Absolutely. I guess, this part of the current standard
annoys both C++ programmers and implementors...

> 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;

Interesting. Just curious: how would you mask "nullaries" whith a non-member template function?
> 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.

There might be none ;-(...

> In general, an iterator does not know if it is at the end.

Something different (that sentence just brought it back to my mind):

I noticd that fusion::pair<end>(begin) works quite well as a "compound iterator" but has a pretty uncool interface. A wrapper around it could give a useful utility...

  'in' is of type fusion::pair<end>(pos),
  '==>' denotes interface transformation provided by an imaginary wrapper

  *in.second ==> *in
  equal_to<typename In::first_type, typename In::second_type> ==> eoi<In>

Since this thing knows when it's at the end, it could (BTW) even have an operator-> that disappears in this case...



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