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

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