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

/Christian


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk