[C++-sig] Re: indexing_v2 status update

[David Abrahams]

Raoul Gough <RaoulGough at yahoo.co.uk> writes:

> David Abrahams <dave at boost-consulting.com> writes:
>
>> Raoul Gough <RaoulGough at yahoo.co.uk> writes:
>
> [snip]
>>> Does mpl::set currently work? I seem to remember that you
>>> suggested using mpl::vector at the moment, which raised some doubt
>>> about this.
>>
>> see libs/mpl/test/set.cpp.  You can try it yourself and find out.
>
> I've looked at the test cases, which I *think* I understand after
> looking at the preprocessor output. From what I can see, there are
> tests for empty and one-element sets only. If that really is the case,
> I don't find it very convincing. 

If zero one and two all work, then N works by induction.  But anyway...

> I'm tending towards the bitflag approach at the moment anyway.

OK.

> By the way, I've been wondering about what the container suite
> interface should look like after moving to feature sets instead of
> static boolean constants. I'm thinking along these lines:
>
> template<
>      class Container,
>      SOME_KIND_OF_SET features = supported_features<Container>,
>      class Algorithms = algorithms<Container>
>> container_suite;
>
> where supported_features does the traits-like work of figuring out
> what the container can support. This would allow client code to
> override the features explicitly if something is not needed.
> Curiously, I think the Algorithms implementation doesn't need to know
> this information itself, since it is up to the container_suite to
> decide what Algorithms functions to instantiate.
>
> Another option would be to determine the supported features within the
> existing container_traits framework, and provide an optional
> features_to_disable parameter to the container_suite. Any thoughts or
> preferences on this front?

Nope; so far it sounds great.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com