$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
From: David Abrahams (dave_at_[hidden])
Date: 2004-07-13 16:01:19
Glen Knowles <gknowles_at_[hidden]> writes:
>> From: David Abrahams
>> 
>> iterator_facade now has to choose between *r++ = o being 
>> valid and being a conforming TR1 input iterator (which 
>> requires *r++ is of type T -- we have since declared that a 
>> defect and *r++ need only be convertible to T).  It makes 
>> that choice by looking at the CategoryOrTraversal parameter: 
>> iff it's convertible to std::output_iterator_tag, *r++ = o 
>> will be valid.
>> 
>> I am thinking it might be more appropriate to detect that *r 
>> is a proxy, and only make *r++ = o valid in that case.  Can 
>> anyone think of a reason that a non-writable iterator 
>> implementation would need to return a proxy from its operator*?
>
> I may be confused as what qualifies as a proxy, but there is the
> vector<bool> case. 
That is a writable iterator that uses a proxy reference.  Yes, the
const_iterator is non-writable, so that's an example of the case I was
asking about... but actually I can't imagine that it's reasonable to
expect a non-proxy from *r++ for any iterator where you get a proxy
from *r.  So I'm settling strongly on using that criterion to
determine writability of the postfix increment proxy.
> OTOH, if you're talking about needing to reach back into the
> container its probably fine. I can imagine a caching scheme that
> returns a week_ptr and goes back to the container to recreate it if
> its gone, but I don't think I'd want to do it. :)
I don't know what you're talking about, sorry.
-- Dave Abrahams Boost Consulting http://www.boost-consulting.com