[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]
>>> On the other hand, perhaps this does belong purely in the
>>> ContainerTraits concept. I wonder whether assignability is always a
>>> quality of a container (and all instances of it) or just the
>>> particular type of value stored in a particular instance. In the case
>>> of the STL containers, I think all template arguments are required to
>>> be Assignable types
>>
>> Yes, but...
>>
>>> and some of the containers (set and map) add
>>> const qualification somewhere in their value_type.
>>
>> ...that fact tends to make the value_type not Assignable.
>
> Of course. I was just thinking about whether it's conceptually related
> to the template arguments or rather to some property of the container
> template. I guess it doesn't actually make much practical difference
> in terms of providing the necessary partial specializations.
>
>>
>>> I've just been taking a look at the unordered_set proposal at
>>> http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1518.pdf and
>>> it looks like the unordered_set::value_type is not const qualified,
>>> which would confuse any assignability determination based on the
>>> container's value_type directly. 
>>
>> I'm not sure if that's intentional.  I've asked.
>>
>>> On the other had, the container only
>>> provides const iterators, so I guess this means that
>>> unordered_set<X>::iterator::value_type is "X const", 
>>> and using the iterator's value type would still work.
>>
>> No, an iterator's value_type is never const.
>
> Hmmmmm... That's really a bit of a shame, since I go to so much
> trouble to pass const_iterator or iterator to the iterator_traits base
> class, depending on whether the container has top-level const
> qualification or not :-) 

What does this have to do with the _container's_ const qualification?

I just mean that iterator_traits<I>::value_type is never a const type
for any valid iterator I.

>>> Possible options include specializing an is_assignable template,
>>> specializing a value_traits template or providing an alternative
>>> ContainerTraits class (the current method).
>>
>> I am not so convinced any more that the current method is worse than
>> the others.
>
> Oh no! I'm starting to think that the value_traits or is_assignable
> templates would actually be better solutions. 

OK, I don't feel strongly either way.

> I say "would be" because neither of them is at all convenient to do
> on MSVC6 owing to the lack of PTS.

How does that come into play?  It's my policy not to make major
interface compromises for broken compilers.

> In fact, that practical difficulty probably means I'll stick with
> the current method, although I'm no longer convinced it is the best
> solution in theory.

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