Boost logo

Boost :

From: Christian Engström (christian.engstrom_at_[hidden])
Date: 2004-02-22 05:34:08

>>Christian Engström <christian.engstrom_at_[hidden]> writes:
>>[...], an algorithm that performs concept
>>checks for concepts that it doesn't actually need is just that:
>"David Abrahams" <dave_at_[hidden]> wrote
> 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.

True, it's the specification that's faulty in that case, not the
implementation as such.

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

If that is how the specification in STL is written, I am indeed making
that argument.

All the STL algorithms are guaranteed to work on containers of built-in
types, such as a Container<int>, which does not even have operator->,
let alone any particular semantics for it. If there is a
"specification" somewhere that claims that operator-> must be defined in
any particular way for the algorithms to work, even though this is
obviously not true, then I consider that specification to be faulty.

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

What an unusual position to adopt. What do you propose then, actual
requirements plus 10%? Plus 20%?

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

If we are talking about "specifications" that do not accuratetely
describe the actual requirements of the algorithm, I indeed have very
little respect for them, which seems to be exactly the amount they deserve.

But if we are talking about real, accurate specifications, I have the
deepest respect for them. It is for this reason that I am so very
interested in finding any cases where a proxy_iterator would not work
properly, but an "ordinary" iterator would, so that I can add them to
the specifications for 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.

Okay, so a more accurate way of describing the problem would be:

"Due to a glitch in the formal specification for iterators in STL,
algorithms are allowed to place semantic restrictions on the -> operator
when it exists, even though the algorithm can never acutally use the
operator in question, since is not actually required to exist at all.

The proxy_iterator:s may not work with STL implementations that
deliberately take advantage of this glitch to do over-reacing
concept-checking for concepts that they do not actually require. It is
not known if any such implementations actually exist or are in common use."


Boost list run by bdawes at, gregod at, cpdaniel at, john at