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

It's also very cheap in terms of compile time and mangled name
lengths.

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

Interesting. I was wondering about this, because just replacing tests
like traits::has_mutable_ref with

traits::property_set::includes<mutable_reference>::value

doesn't seem like much of a win by itself. Being able to do something
like "apply each property to this class_ instance" would be a
different story. This would also provide a neater way of extending the
suite with new Python methods, compared to the current visitor_helper
hooks.

On the other hand, some of the Python methods are provided only when
multiple abilities are present, e.g. "sort" requires is_reorderable
and value_traits_::less_than_comparable. Such decisions are currently
localized in the visitor template, the "monolithic repository" of this
knowledge. I'm not sure that it would make sense to have
ContainerTraits provide a ready-made set of Python methods to inject
instead of just describing the relevant capabilities of the
container. i.e. I'm starting to think that the capabilities are better
off being just on/off flags in one form or another.

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