
Christian Engström <christian.engstrom@glindra.org> writes:
Christian Engström <christian.engstrom@glindra.org> writes: , all of the STL algorithms can be used without restriction."
"David Abrahams" <dave@boost-consulting.com> 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