This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]