Siemel Naran wrote in message ...
>In addition, a standard container is supposed to have the typedef
>"typedef T& reference".  From this, it follows that the result of
>applying operator& to a reference is the same as
>vector<T>::value_type*.  IOW, vector<T>::pointer is the same as
>vector<T>::value_type*.

By this logic all containers would need to use dumb pointers for their
iterators.

Just because dereferencing container<T>::pointer has to give a T&, it
doesn't mean that taking the address of a reference has to give
container<T>::pointer.

Try it with std::list some time ;-)
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <7bhn10$nef3@news.research.bell-labs.com>,
  "Igor Sominskiy" <sominskiy@lucent.com> wrote:
>
> I am wondering if there is a place in the C++ standard which states that I
> can or cant make an assumption that vector's iterator type is a pointer to
> an element;

The standard goes out of it's way to avoid letting you make either
assumption. An iterator encapsulates the concept of a pointer.
However, depending on the iterator type, it's actual operation might
be much more complicated than a simple address.

In article <36DD476C.FBC6E445@physik.tu-muenchen.de>,
celtschk@physik.tu-muenchen.de says...

[ ... lib.vector ]:

>       typedef implementation defined                    iterator;       // See _lib.container.requirements_
>       typedef implementation defined                    const_iterator; // See _lib.container.requirements_
>
> Unless this has changed in the final standard (which I don't have
> access to), the standard doesn't mandate pointers. It doesn't
> forbid them eiter, though.

These remain in the final standard.  I suspect for at least some
purposes, pointers will remain in use for quite a while -- using
nearly anything else will sometimes (often) result in a loss of
efficiency.  It can be argued (and has been) that this loss is often
justifiable, many people object to it, if only on principle.



[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

On 03 Mar 99 23:56:42 GMT, Bill Wade <bill.wade@stoner.com> wrote:
>Siemel Naran wrote in message ...

>>In addition, a standard container is supposed to have the typedef
>>"typedef T& reference".  From this, it follows that the result of
>>applying operator& to a reference is the same as
>>vector<T>::value_type*.  IOW, vector<T>::pointer is the same as
>>vector<T>::value_type*.

This paragraph says nothing of iterators.

>By this logic all containers would need to use dumb pointers for their
>iterators.

Got me confused.


>Just because dereferencing container<T>::pointer has to give a T&, it
>doesn't mean that taking the address of a reference has to give
>container<T>::pointer.

Yes, I guess you're right.  One may have overloaded T::operator&.


>Try it with std::list some time ;-)

If T::operator& is not overloaded, then the address of a
container::reference has to be a container::pointer, which in a
standard container is the same as container::value_type*.  Is
this right?

--
----------------------------------
Siemel B. Naran (sbnaran@uiuc.edu)
----------------------------------
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <36DD476C.FBC6E445@physik.tu-muenchen.de>, Christopher
Eltschka <celtschk@physik.tu-muenchen.de> writes
>The following is a quote from the design document of the
>EGCS Standard C++ library v3:
>
>  Replacing the vector iterators, which currently are simple element
>  pointers, with class objects would greatly increase the safety of the
>  client interface, and also permit a "debug" mode in which range,
>  ownership, and validity are rigorously checked.  The current use of
>  pointers for iterators is evil.

Bravo!  And, while they're about it, fix (w)string iterators to be
proper classes at the same time.

--
Cheers,
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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Siemel Naran wrote:
>
> On 03 Mar 99 23:56:42 GMT, Bill Wade <bill.wade@stoner.com> wrote:
....
> >Just because dereferencing container<T>::pointer has to give a T&, it
> >doesn't mean that taking the address of a reference has to give
> >container<T>::pointer.

vector<T>::pointer is required to be allocator<T>::pointer, which in
turn is required to be T*. That makes this whole discussion fairly
trivial.

> Yes, I guess you're right.  One may have overloaded T::operator&.

On the other hand, the only case where this issue becomes non-trivial is
the more general case of vector<T,Allocator>::pointer, which is required
to be Allocator<T>::pointer, which ISN'T required to be T*. (Though
implementations of standard containers are permitted to assume that it
is).


> >Try it with std::list some time ;-)
>
> If T::operator& is not overloaded, then the address of a
> container::reference has to be a container::pointer, which in a
> standard container is the same as container::value_type*.  Is
> this right?

Not in the general sense you described. Firstly, a standard container is
not required to have a container<>::pointer.

The containers required to have a container<>::pointer are deque<>,
list<>, vector<>, map<>, multimap<>, set<>. For each of those containers
except vector<bool> (where it's implementation defined),
container<T,Allocator>::pointer is required to be Allocator::pointer.
Allocator<T>::pointer is only required to be a "pointer to T", and not
necessarily a "T*". Standard container implementators are encouraged
(but not required) to support allocators where it is a user-defined
type.

A container::reference pretty much has to be a container::value_type&;
it's not really possible to do a correct user-defined reference type in
standard C++. Therefore, the address of a reference has to be a
container::value_type*.
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

James Kuyper wrote in message <36DF3A26.69771AF6@wizard.net>...
>> On 03 Mar 99 23:56:42 GMT, Bill Wade <bill.wade@stoner.com> wrote:
>> >Just because dereferencing container<T>::pointer has to give a T&, it
>> >doesn't mean that taking the address of a reference has to give
>> >container<T>::pointer.
>
>vector<T>::pointer is required to be allocator<T>::pointer, which in
>turn is required to be T*. That makes this whole discussion fairly
>trivial.

Oops.  When I read and wrote ::pointer I was thinking ::iterator.

Never mind.
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

I am wondering if there is a place in the C++ standard which states that I
can or cant make an assumption that vector's iterator type is a pointer to
an element;

I have looked through implementations of several std c++ libraries
(Microsoft VC++, g++, EGCS, Metrowerks CW) and they all do the same thing:
typedef pointer to iterator. Unfortunately I could not find a place in the
standard wich states that this is the right or wrong way of doing that.

Please help.

Thanks



[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

"Igor Sominskiy" <sominskiy@lucent.com> writes:

> I am wondering if there is a place in the C++ standard which states that I
> can or cant make an assumption that vector's iterator type is a pointer to
> an element;
>
> I have looked through implementations of several std c++ libraries
> (Microsoft VC++, g++, EGCS, Metrowerks CW) and they all do the same thing:
> typedef pointer to iterator. Unfortunately I could not find a place in the
> standard wich states that this is the right or wrong way of doing that.

It is allowed but not required for vector<T>::iterator to be T*.
The standard only requires that vector<T>::iterator be a mutable
random access iterator whose value type is T.


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

On 3 Mar 1999 00:20:09 GMT, Igor Sominskiy <sominskiy@lucent.com> wrote:

>I am wondering if there is a place in the C++ standard which states that I
>can or cant make an assumption that vector's iterator type is a pointer to
>an element;

There are three things here -- iterator type, pointer type, and pointer
to element or value type.


I. iterator type and pointer

An implementation may make
   std::vector<T>::iterator
   std::vector<T>::const_iterator
into classes that contain a "T *" or "T const *" as private data members.
One advantage of this approach is that iterator class can hold typedefs
(eg, "iterator_category", "reference").  This makes writing iterator
adaptor classes a little easier.  A disadvantage is that the proxy class
may be more inefficient than a builtin class, although with extreme
optimizations, I don't think this has to be the case.


II. pointer type and pointer to element

In addition, a standard container is supposed to have the typedef
"typedef T& reference".  From this, it follows that the result of
applying operator& to a reference is the same as
vector<T>::value_type*.  IOW, vector<T>::pointer is the same as
vector<T>::value_type*.

But an implementation is allowed to specialize std::vector<bool> to
achieve close packing.  So now std::vector<bool>::reference is a
nested class and std::vector<bool>::pointer is a pointer to this
nested class.  So in general you can't assume that
vector<T>::pointer is the same as vector<T>::value_type*.

But std::vector<bool> is not a standard container.  So if you
write an algorithm that expects a standard vector, then document it
as such.

--
----------------------------------
Siemel B. Naran (sbnaran@uiuc.edu)
----------------------------------


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Igor Sominskiy wrote:
>
> I am wondering if there is a place in the C++ standard which states that I
> can or cant make an assumption that vector's iterator type is a pointer to
> an element;
>
> I have looked through implementations of several std c++ libraries
> (Microsoft VC++, g++, EGCS, Metrowerks CW) and they all do the same thing:
> typedef pointer to iterator. Unfortunately I could not find a place in the
> standard wich states that this is the right or wrong way of doing that.
>
> Please help.

AFAIK, you are not assured.