[Patch] First bits of the algo merge
Howard Hinnant
hhinnant@apple.com
Thu Dec 15 17:31:00 GMT 2005
On Dec 15, 2005, at 10:52 AM, Howard Hinnant wrote:
> Fwiw, here's an updated exploration tool.
I'm not positive yet, but I think I may be getting close to a test
case that shows METHOD_A is non-conforming (which is something I
first did not suspect). If you start out with something like:
template <typename T>
class iterator
{
class proxy
{
friend class iterator;
iterator* const iter_;
explicit proxy(iterator* iter) : iter_(iter) {}
public:
operator T () const {return iter_->deref();}
T& operator= (const T& rh) {return iter_->deref() = rh;}
T& operator= (proxy& p) {*iter_ = *p.iter_; return *iter_;}
proxy(proxy& p) : iter_(p.iter_) {}
};
...
I.e. the proxy is designed to be non-copyable. You can dereference
the iterator and get the value_type. But you can't dereference the
iterator and save or copy the reference/proxy. The iterator can
return a proxy with the given copy ctor:
proxy operator*() {proxy p(this); return p;}
But that's the only way the client can get a proxy. And once it is
an rvalue, it can't be copied again. You can only convert it to a T,
or assign a T through it.
Such an iterator would only qualify as an input iterator, but
otherwise I think would be conforming, reference 24.1.1p2, table row:
*a convertible to T
Such a proxy breaks A, but not B or C.
Note that I do not mean to imply that this proves B is conforming, it
does not. But I think it may prove A is non-conforming.
> I'd like to ask your opinion (guess) about these two related issues:
>
> 1- Using strumentally the improved algorithm simplification
> strategy is
> the only relatively simple way to substantially improve on that QoI
> issue or you can imagine/suggest other (better?) ways?
Sorry, I'm not completely parsing this one.
> 2- Can you figure out relevant use cases that we would get wrong
> anyway
> with the improved __ops::equal_to & co?
I will redouble my efforts to try and prove B non-conforming.
-Howard
More information about the Libstdc++
mailing list