This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: [Patch] First bits of the algo merge
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