"Matvei Brodski" <mbrodski@bear.com> wrote in message
news:3B0D1F94.6C63132C@bear.com...
> Anthony Williams wrote:
> > Exactly - a vector of proxies, not a vector of SomeClass objects - what
if I
> > want to call a member function on the object, or maintain a pointer to
it
> > for use elsewhere. What if I want to do +=, not just =?
>
> Ok, so, you can define all those operations for that proxy. Consider
> this: *wherever* we are using a proxy we have to either know that it
> is a proxy, or supply all the necessary operations that it is going
> to forward to a "real object" for execution. It is not something specific
> to proxies-in-a-container.

Yes, but containers are often generic templates, which means you want a
generic proxy, which is not currently possible. One of my desires for C++0x
is proper support for generic proxies, so the _user_ doesn't have to know
it's a proxy, and the _implementor_ doesn't have to know what _type_ it's a
proxy for.

Anthony
--
Anthony Williams
Software Engineer, Nortel Networks Optoelectronics
The opinions expressed in this message are not necessarily those of my
employer



---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Anthony Williams wrote:

> "Matvei Brodski" <mbrodski@bear.com> wrote in message
> news:3B0D1F94.6C63132C@bear.com...
> > Anthony Williams wrote:
> > > Exactly - a vector of proxies, not a vector of SomeClass objects - what
> if I
> > > want to call a member function on the object, or maintain a pointer to
> it
> > > for use elsewhere. What if I want to do +=, not just =?
> >
> > Ok, so, you can define all those operations for that proxy. Consider
> > this: *wherever* we are using a proxy we have to either know that it
> > is a proxy, or supply all the necessary operations that it is going
> > to forward to a "real object" for execution. It is not something specific
> > to proxies-in-a-container.
>
> Yes, but containers are often generic templates, which means you want a
> generic proxy, which is not currently possible. One of my desires for C++0x
> is proper support for generic proxies, so the _user_ doesn't have to know
> it's a proxy, and the _implementor_ doesn't have to know what _type_ it's a
> proxy for.

Oh, I see. Now I understand what Dietmar ment too.
So, what you want is to orthogonalize iterator_traits:
one set that describes how iterators "move around",
another - the type of access to the "containee" they provide.

Thanks,
Matvei.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

"Dietmar Kuehl" <dietmar_kuehl@yahoo.com> wrote in message
news:5b15f8fd.0105230552.10a1d8fe@posting.google.com...
> Hi,
> "Anthony Williams" <anthwil@nortelnetworks.com> wrote
> > Any comments?
>
> Have a look at some of the other threads: I seem to repeat this in about
every
> second article I have written recently... What you described is one of the
> problems with combining data access (operators *, ->, and []) with
positing
> (the remainder of the iterator classes). IMO there should be a completely
> separate concept for property access with using the currently used
operators
> as the default.

Yes, I posted this before seeing the thread on comp.lang.c++.moderated

> This would solve some other problems than just the proxy container stuff,
most
> notably appropriate access to a part of the sequence elements (eg. when
> creating a "map" in a std::vector<key, value>: the search algorithms
operate
> only on the keys, not on a std::pair<key, value>). Also, this approach can
be
> defined in a clearer way than using implicit conversions used by typical
proxy
> approaches.
>
> I should probably post a more concrete example of what I'm talking off
than
> merely sketching what I have in mind. ... but then, the "property maps" in
> the Boost Graph Library (see <http://www.boost.org/>) and the stuff
described
> in a C++ Report article (I think in 1997) on "Data Access Templates" are
> just this!

I like the idea of separating property access from iteration, and I will
look at boost. Is the C++Report article available online?

Anthony
--
Anthony Williams
Software Engineer, Nortel Networks Optoelectronics
The opinions expressed in this message are not necessarily those of my
employer



---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

On Thu, 24 May 2001 12:44:16 GMT, Anthony Williams <anthwil@nortelnetwork=
s.com> wrote:
[=B7=B7=B7]
> Basically, under the current scheme, the user of the
> container/sequence/iterator has to be aware that it uses proxies, and
> not real objects, because it limits what can be done with the
> referred-to objects.

Maybe more importantly, the proxy type has to be provided even if it is
not intended to ever be used, for the iterator to qualify as a forward
iterator as specified by the standard. I think the original concern was
not that there are situations where it is impossible to provide
reference access to the container elements, but that there are
situations where this doesn't make too much sense, and hence the
implementor shouldn't be forced to provide that functionality.

-- Niklas Matthies

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Anthony Williams wrote:

> "Matvei Brodski" <mbrodski@bear.com> wrote in message
> news:3B0BCA40.1EC5B089@bear.com...
> > Anthony Williams wrote:
> >
> > > In particular, I am thinking of something like a file iterator - you can
> > > seek to a given file position, you can read the character there, you can
> > > write the character there, but you cannot get a real reference to that
> > > character.
> > >
> > > Such an iterator would fulfill all of the random_access_iterator
> concepts
> > > _Except_ that it does not (cannot) return a reference to the underlying
> > > object.
> >
> > But it can return a reference to a some kind of underlying-object-adapter,
> that
> > it contains. Such an adapter can have two operators defined: casting
> operator to
> > the underlying object (reading from file), assignment operator (writing to
> > file). It can also implement all the advance-through-file operations.
> > Pimpl-like.
> >
> >
> > > This is a general problem with proxy iterators, and IMO needs a
> solution.
> > >
> > > Proper support for proxy types (so they behave as a specified type by
> > > forwarding all operations on that type through some mechanism that
> permits a
> > > read-modify-write sequence) is one solution.
> >
> > I am confused. What other support do we need?
> > We have a proxy type that holds a position in file, reads/writes to it,
> advances
> > through the file, an object of this proxy class is contained in an
> iterator,
> > when asked for a reference, iterator returns a reference to that proxy.
> Did I
> > miss something?
> > In other words, your file can be viewed by the client code as a vector of
> > proxies.
>
> Exactly - a vector of proxies, not a vector of SomeClass objects - what if I
> want to call a member function on the object, or maintain a pointer to it
> for use elsewhere. What if I want to do +=, not just =?

Ok, so, you can define all those operations for that proxy. Consider
this: *wherever* we are using a proxy we have to either know that it
is a proxy, or supply all the necessary operations that it is going
to forward to a "real object" for execution. It is not something specific
to proxies-in-a-container.

Matvei.


> Basically, under the current scheme, the user of the
> container/sequence/iterator has to be aware that it uses proxies, and not
> real objects, because it limits what can be done with the referred-to
> objects.
>
> Anthony
> --
> Anthony Williams
> Software Engineer, Nortel Networks Optoelectronics
> The opinions expressed in this message are not necessarily those of my
> employer

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Hi,
"Anthony Williams" <anthwil@nortelnetworks.com> wrote
> Any comments?

Have a look at some of the other threads: I seem to repeat this in about every
second article I have written recently... What you described is one of the
problems with combining data access (operators *, ->, and []) with positing
(the remainder of the iterator classes). IMO there should be a completely
separate concept for property access with using the currently used operators
as the default.

This would solve some other problems than just the proxy container stuff, most
notably appropriate access to a part of the sequence elements (eg. when
creating a "map" in a std::vector<key, value>: the search algorithms operate
only on the keys, not on a std::pair<key, value>). Also, this approach can be
defined in a clearer way than using implicit conversions used by typical proxy
approaches.

I should probably post a more concrete example of what I'm talking off than
merely sketching what I have in mind. ... but then, the "property maps" in
the Boost Graph Library (see <http://www.boost.org/>) and the stuff described
in a C++ Report article (I think in 1997) on "Data Access Templates" are
just this!
--
<mailto:dietmar_kuehl@yahoo.com> <http://www.dietmar-kuehl.de/>
Phaidros eaSE - Easy Software Engineering: <http://www.phaidros.com/>

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Anthony Williams wrote:

> In particular, I am thinking of something like a file iterator - you can
> seek to a given file position, you can read the character there, you can
> write the character there, but you cannot get a real reference to that
> character.
>
> Such an iterator would fulfill all of the random_access_iterator concepts
> _Except_ that it does not (cannot) return a reference to the underlying
> object.

But it can return a reference to a some kind of underlying-object-adapter, that
it contains. Such an adapter can have two operators defined: casting operator to
the underlying object (reading from file), assignment operator (writing to
file). It can also implement all the advance-through-file operations.
Pimpl-like.


> This is a general problem with proxy iterators, and IMO needs a solution.
>
> Proper support for proxy types (so they behave as a specified type by
> forwarding all operations on that type through some mechanism that permits a
> read-modify-write sequence) is one solution.

I am confused. What other support do we need?
We have a proxy type that holds a position in file, reads/writes to it, advances
through the file, an object of this proxy class is contained in an iterator,
when asked for a reference, iterator returns a reference to that proxy. Did I
miss something?
In other words, your file can be viewed by the client code as a vector of
proxies.

Matvei.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

"Matvei Brodski" <mbrodski@bear.com> wrote in message
news:3B0BCA40.1EC5B089@bear.com...
> Anthony Williams wrote:
>
> > In particular, I am thinking of something like a file iterator - you can
> > seek to a given file position, you can read the character there, you can
> > write the character there, but you cannot get a real reference to that
> > character.
> >
> > Such an iterator would fulfill all of the random_access_iterator
concepts
> > _Except_ that it does not (cannot) return a reference to the underlying
> > object.
>
> But it can return a reference to a some kind of underlying-object-adapter,
that
> it contains. Such an adapter can have two operators defined: casting
operator to
> the underlying object (reading from file), assignment operator (writing to
> file). It can also implement all the advance-through-file operations.
> Pimpl-like.
>
>
> > This is a general problem with proxy iterators, and IMO needs a
solution.
> >
> > Proper support for proxy types (so they behave as a specified type by
> > forwarding all operations on that type through some mechanism that
permits a
> > read-modify-write sequence) is one solution.
>
> I am confused. What other support do we need?
> We have a proxy type that holds a position in file, reads/writes to it,
advances
> through the file, an object of this proxy class is contained in an
iterator,
> when asked for a reference, iterator returns a reference to that proxy.
Did I
> miss something?
> In other words, your file can be viewed by the client code as a vector of
> proxies.

Exactly - a vector of proxies, not a vector of SomeClass objects - what if I
want to call a member function on the object, or maintain a pointer to it
for use elsewhere. What if I want to do +=, not just =?

Basically, under the current scheme, the user of the
container/sequence/iterator has to be aware that it uses proxies, and not
real objects, because it limits what can be done with the referred-to
objects.

Anthony
--
Anthony Williams
Software Engineer, Nortel Networks Optoelectronics
The opinions expressed in this message are not necessarily those of my
employer



---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Iterator concepts are good things - if I write a new kind of container, I
can write an iterator that is most suited to that container, and then attach
a concept to it so the standard algorithms can use the correct
specialization. e.g. if random access is tricky (some kind of linked list),
then my iterator need only conform to the bidirectional iterator concept. At
the most basic level, we have input iterators and output iterators.

However, there is one problem with the iterator requirements - there is no
concept for iterators that

(a) can be read from and written to
(b) cannot return a reference to the current object

In particular, I am thinking of something like a file iterator - you can
seek to a given file position, you can read the character there, you can
write the character there, but you cannot get a real reference to that
character.

Such an iterator would fulfill all of the random_access_iterator concepts
_Except_ that it does not (cannot) return a reference to the underlying
object. Indeed, it must be declared as either an input iterator, OR an
output iterator, since it can only be declared as one using iterator_traits,
and the other concepts require a reference return.

This is a general problem with proxy iterators, and IMO needs a solution.

Proper support for proxy types (so they behave as a specified type by
forwarding all operations on that type through some mechanism that permits a
read-modify-write sequence) is one solution.

Another is to separate the "returns a reference" requirement from the other
iterator requirements, so you can have a random_access_iterator that doesn't
return a reference, and a random_access_iterator that does - maybe an
additional flag in iterator_traits? In theory this is already present, as we
have a typedef iterator_traits<T>::reference, which could be
iterator_traits<T>::value_type&, or it could not, but a bool might be more
obvious.

We could also have a parallel proxy_iterator concepts hierarchy
(proxy_forward_iterator, proxy_random_access_iterator ...), but this seems
wrong IMO.

Any comments?

Anthony
--
Anthony Williams
Software Engineer, Nortel Networks Optoelectronics
The opinions expressed in this message are not necessarily those of my
employer


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]