[C++-sig] Re: indexing_v2 status update
RaoulGough at yahoo.co.uk
Thu Jan 8 16:13:21 CET 2004
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:
>>>> 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.
>> 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:
>> class Container,
>> SOME_KIND_OF_SET features = supported_features<Container>,
>> class Algorithms = algorithms<Container>
>> 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.
More information about the Cplusplus-sig