Re: [boost] Interest in flat_iterator for nested containers?

Subject: Re: [boost] Interest in flat_iterator for nested containers?
From: Christoph Heindl (christoph.heindl_at_[hidden])
Date: 2009-09-28 15:20:00

Jeff,

>
> Clever!  Though in this instance, the minimum is identical to the gcd, at
> which point you could just assign the traversal tags to consecutive integers
> ;)

I'm not sure if I understood you correctly: Assigning, for example,
1:readable, 2:single pass and 3:forward iterable would yield
1:readable for the gcd of 2:single pass and 3:foward which is not true
(IMHO :).

> But this is something I'll have to keep in mind for any fixed class
> hierarchy, as the gcd could provide a nice way to compute the "least common
> ancestor".

I'm glad I could help.

>
> The widest_convertible metafunction I have is slower than one specialized
> for a linear hiearchy (O(n^2) instead of O(n)), and based on
> boost::is_convertible.  See below.

Thanks for your input! It's gonna take a while for me to understand
the code as I'm not to familiar with all the meta-functions in place.

>> Do you think that piece of code might be of general interest?
>
> It would be much more useful if it were variadic, either taking a variable
> number of template parameters or (my preference) accepting a Boost.MPL
> sequence of traversal tags.

You are quite challenging my meta-programming knowledge :) Fortunately
I found out about mpl::fold and applied it straight forward to my
previously created widest_convertible_traversal_cat (although renamed
to widest_convertible_binary):

------
template<class Sequence>
struct widest_convertible_sequence {
  typedef typename boost::mpl::if_<
    boost::mpl::empty<Sequence>,
    boost::no_traversal_tag,
    typename boost::mpl::fold<
      Sequence,
      boost::random_access_traversal_tag,
      boost::widest_convertible_binary<boost::mpl::_1, boost::mpl::_2>
    >::type
  >::type type;
};
----
I've attached my adopted version.
I think your idea of re-using this pattern for "least common ancestor"
for a fixed class hierarchy shouldn't require to many adoptions to the
current code basis. If the user is able to provide the mapping the
rest is already in place (I think).
Best regards,
Christoph