"Larry Brasfield" <larrybr@earthlink.net> writes:

|>  The expression ++r is an r-value.  It's address cannot
|>  be legitimately taken.

Wrong language.  Your comments are correct for C, but not C++.  (I'll
admit that this surprised me, too, the first time I heard it.)

--
James Kanze      home:     kanze@gabi-soft.fr        +33 (0)1 39 55 85 62
                 office:   kanze@vx.cit.alcatel.fr   +33 (0)1 69 63 14 54
GABI Software, Sarl., 22 rue Jacques-Lemercier, F-78000 Versailles France
     -- Conseils en informatique industrielle --
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Larry Brasfield (larrybr@earthlink.net) wrote:
: John E. Potter <jpotter@falcon.lhup.edu> wrote in article
: <5co80o$7nk$1@jake.esu.edu>...
: > In reading 24.1 - 24.1.5 Iterator Requirements, there are some things
: that
: > are not clear to me.  Clarification appreciated.
: >
: > Table 73 - Input iterator.  The statement &r == &++r is missing.
: > Does this
: > allow returning a reference to an iterator other than self?  Why?

[snip stuff not addressed]

: The expression ++r is an r-value.  It's address cannot
: be legitimately taken.

In C++ the model for the builtins looks like

 X& X::operator++ () { doSomething; return *this; }

Perhaps you were thinking of C or

 X x::operator++ (int) { X t(*this); ++ *this; return t; }

The missing statement is present for the other four iterators, and for
prefix -- for the two that support it.  As a requirement, it states
that the operator must follow the builtin model (maybe).  Input
iterator does require X& as a return type so it certainly is an lvalue.

Thanks to your reply, it has occured to me that the missing requirement
does not say what I assumed.  I could define operator& for the iterator
to return 0.  Then &r == &++s for all iterators of any type.  It seems
that C++ is not a good language for writing requirements.

Enjoy,
John


[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

In reading 24.1 - 24.1.5 Iterator Requirements, there are some things that
are not clear to me.  Clarification appreciated.

Table 73 - Input iterator.  The statement &r == &++r is missing.  Does this
allow returning a reference to an iterator other than self?  Why?  The
return type of r++ is missing, yet *r++ has return type T and is well
defined.  Does this allow r++ to return a proxie for T while ++r must
return an iterator reference?  i = ++r is valid, but i = r++ might not
be?  Is the form of this table intentionally different from the other
four tables?  Does the assignment operator really return a value not
a reference?

Table 74 - Output iterator.  Assignment operator is not required?  Both
*a = t and a = t are required?  *a = t is specified, but a = t is used
in the description of X(a).  I know that ostream_iterator works this
way, but do all output iterators have this requirement?  Since all
iterators except input may be used where an output iterator is called
for, do the others also have this requirement?

Table 75 - Forward and Table 76 - Bidirectional.  r == s implies
++r == ++s and --r == --s implies r == s.  These one way implications
rather than if and only if, allow off-the-end values for different
containers to compare equal?  If no off-the-end values are involved,
are they iff?

Table 75 through Table 77 - Random access.  Why do the dereferenced
types vary?  *a is T&, *r++ is T&, *r-- is convertable to T, and
a[n] is convertable to T.

Thanks,
John
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

John E. Potter <jpotter@falcon.lhup.edu> wrote in article
<5co80o$7nk$1@jake.esu.edu>...
> In reading 24.1 - 24.1.5 Iterator Requirements, there are some things
that
> are not clear to me.  Clarification appreciated.
>
> Table 73 - Input iterator.  The statement &r == &++r is missing.  Does this
> allow returning a reference to an iterator other than self?  Why?  The
> return type of r++ is missing, yet *r++ has return type T and is well
> defined.  Does this allow r++ to return a proxie for T while ++r must
> return an iterator reference?  i = ++r is valid, but i = r++ might not
> be?  Is the form of this table intentionally different from the other
> four tables?  Does the assignment operator really return a value not
> a reference?
The expression ++r is an r-value.  It's address cannot
be legitimately taken.

>
[Q on Tables 74 and up cut, not addressed.]
--
--Larry Brasfield
The aforementioned views are mine alone.
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Hi,

the Jan 96 WP states in [lib.input.iterators] that if a is an input
iterator for the type T then *a must return a value of type T. Later, in
[lib.forward.iterators] it states that if a is a forward iterator for
type T then *a must return T&. IMHO, with these requirements it is
impossible to use proxy objects with iterators. I wonder why the
requirements as described in "STL Tutorial and Reference Guide" by
Musser & Saini haven't been adopted, i.e. that if a is an input iterator
then *a must be convertible to T and if a is a forward iterator then *a
must be convertible to T and *a=t must be valid if t is of type T.

Bye

Roman


[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]