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

[Raoul Gough]

David Abrahams <dave at boost-consulting.com> writes:

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

Are we talking about a mathematical proof or testing strategy here :-)
You would have to prove that for all i, correct(i) implies
correct(i+1) and then go on to prove e.g. correct(0). Proving general
things about code is hard though, so the i -> i+1 implication would be
difficult. In this case, restricting the testing to 0 and 1 element
sets completely ignores potential problems with ordering of elements.

e.g. is set<a,b> == set<b,a> ???

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

OK, thanks! I think I'll go with the supported_features approach.

-- 
Raoul Gough.
export LESS='-X'