[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:
>>
>>> David Abrahams <dave at boost-consulting.com> writes:
> [snip]
>>>> The use of static constants in ContainerTraits is unattractive to
>>>> me, because it's not particularly extensible.  What about asking
>>>> the user to provide an mpl::set of the property type tags:
>>>>
>>>>    typedef mpl::set<mutable,find,insert,push_back> capabilities;
>>>>
>>>> or something?
>>>
>>> Looks like a good idea. I'll give this a go.
>>
>> We may need to whip mpl::set into shape.  In the meantime you could
>> use an mpl::vector, and mpl::find which will give slightly longer
>> compiles but should work.
>
> Actually, I'm not so sure about the benefits of making this change
> now. For instance, the current boolean flag approach is the same one
> used in std::numeric_limits.

numeric_limits is hardly a model of good (based on the best
information we have today) design.

> What would you think about using bitwise-combinations of flags? 
> I've recently introduced this as a way to disable expensive features
> that you don't need, and it seems pretty convenient. The only
> drawback I can think of is a limitation (on many systems anyway) to
> 32 selectable properties.

As you say, it's also limiting, but it's not terrible.

> Is there anything else that using mpl::set or mpl::vector would get us
> in terms of functionality that bitsets (or seperate bools) don't have?

Yes.  These symbolic tags can have operations built into them, so that
when you process them you don't have to keep the knowledge about each
one's meaning in one monolithic place.  Instead you can let the tags
themselves do the work, leading to better modularity and
extensibility... at least, this may be possible.

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