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:
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
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
Meta-comment: you seem to have little respect for the value of
> 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk