Here's a seemingly simple problem that I have spent most of my
Thanksgiving weekend on, and still don't have enough to boast:
Given:
1. A Boost.Fusion-compatible sequence;
2. An integral value i computed at runtime, known to be within
0..size(sequence);
implement an algorithm applying some sort of a generic visitor to the
i-th element of the sequence.
However long I looked through the documentation, I didn't find a ready
solution. Here's the best I was able to come up with on my own:
======================================================================
struct at_v {
template struct result :
public fusion::result_of::at
{};
template
typename result::type operator()( Seq& seq, N ) const {
return fusion::at<N>( seq );
}
};
template
void apply_at( F f, Seq& seq, IntV i )
{
fusion::for_each(
fusion::as_vector(
mpl::range_c<
IntV,
0, IntV(
fusion::result_of::size<Seq>::type::value
)
>()
),
phoenix::if_( phoenix::arg_names::arg1 == i ) [
phoenix::function<F>( f )(
phoenix::function()(
phoenix::ref( seq ), phoenix::arg_names::arg1
)
)
]
);
}
======================================================================
Drawbacks:
1. Requires a Boost.Phoenix-compliant visitor -- even though I managed
to hide the Phoenix dependency inside apply_at(), it still requires a
full-blown templatized result metafunction as part of the visitor even
though the latter is not expected to return a value. Be nice to have
simpler requirements for a visitor.
2. Can't figure out an easy way of returning a value from the visitor. I
tried some constructs using fusion::fold() but only halfheartedly: the
big problem is that there is no obvious way to specify that the visitor
always returns results of the same type, no matter what argument type it
is given. Note that the function calls the visitor only once, so, in
principle, there should always be exactly one value to return (index out
of bounds should naturally be a contract violation, which is not checked
in my version).
3. The complexity is O( size(sequence) ) which is quite atrocious for
random access (even though in practice it should not be much of a
problem given that it simply means N integer comparisons with a
relatively small N). Still, a O( log N ) or even a constant-time
implementation should be quite possible...
Even though the solution above should be sufficient for my purposes I'm
still openly wondering whether I have overlooked something in the Boost
libraries and/or whether someone more versed in Fusion/Phoenix/MPL might
suggest a better approach.
Thanks in advance for any responses,
...Max...
PS. Without fusion::as_vector() around the index sequence constructor,
GCC 4.4.3 complained of not being able to match operator(), suggestive
of a forwarding function problem: looks like operator* on an iterator
over mpl::range_c<> returns something that can't be digested by a
Phoenix actor. I wonder if this should really be taken care of by the
Fusion adapter for MPL sequences?
PPS. Is there better documentation for Boost.Phoenix than what's at
http://www.boost.org/doc/libs/1_45_0/libs/spirit/phoenix ? Not even a
straightforward reference manual?
