[boost] Re: Proxy --- an indirect container adaptor

From: David Abrahams (dave_at_[hidden])
Date: 2004-02-21 16:56:27

Christian Engström <christian.engstrom_at_[hidden]> writes:

>>>> Christian Engström <christian.engstrom_at_[hidden]> writes:
>>>>, all of the STL algorithms can be used without restriction."
>>>
>>> "David Abrahams" <dave_at_[hidden]> wrote in message
>>>False.  They are allowed to contain concept checks that cause
>>>compilation to fail if you pass them non-conforming iterators.
>> Jeff Flinn wrote:
>> I just ran into this moving a project from VC6.5 to VC7.1, where home-grown
>> pre-boost::iterator_adaptors were no longer valid for use with several
>> algorithms. It was very easy(and appealing) to replace them with their
>> Specialized Adaptor equivalents.
>> Jeff F
>
> Yes, faulty implementations of underlying components can always be a
> problem.  I don't know if this was the case in the situation you
> describe, but generally speaking, an algorithm that performs concept
> checks for concepts that it doesn't actually need is just that:
> faulty.

The implementation is not faulty.  The algorithm's implementation
cannot be called faulty just because it exercises a part of the
parameter's interface that's required by the algorithm's
specification.

You could make an argument that the specification is faulty because it
only contains a concept "iterator" and not a less-refined concept
"iterator that may not support the usual operator-> semantics".  I
think it's unreasonable to expect every concept to be broken down to
its bare minimum to avoid placing any unneeded requirements on
parameters.

Meta-comment: you seem to have little respect for the value of
specifications.

> So if (which has not been shown, but anyway) there are algortithm
> implementations that would not accept proxy_iterator:s because they do
> over-reaching pre-condition testing, this is a problem with that
> algorithm, not with the proxy_iterator.
>
> But I agree, it's a point well worth keeping in mind, that since the
> proxy package is designed in a way that may not coincide with many
> people's expectations, it may possibly run a higher than normal risk
> of triggering latent bugs in various third-party components.

We're not talking about bugs, and we're not talking about third-party
components.  We're talking about standard-conforming implementations
of the standard library.

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