This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: [RFC] libstdc++/8780
- From: Martin Sebor <sebor at roguewave dot com>
- To: libstdc++ at gcc dot gnu dot org
- Date: Wed, 04 Dec 2002 11:24:41 -0700
- Subject: Re: [RFC] libstdc++/8780
- Organization: Rogue Wave Software, Inc.
- References: <200212041806.gB4I69Y06150@piper.synopsys.com>
- Reply-to: libstdc++ at gcc dot gnu dot org
Joe Buck wrote:
I wrote:
The short answer is that, given
std::vector<T>::iterator iter_T;
then
&*iter_T
has type T* and points to the same object. As the elements of a vector
must be contiguous, this works portably.
Martin writes:
Unfortunately, it will not work for an iterator pointing at the end
of a container.
You are of course correct that there are no guarantees that
&*some_vector.end() will not produce a one-past-the-end pointer;
debugging implementations of vector<T>::iterator will very likely
throw an exception or abort.
Still, note that I said "has type T* and points to the same object":
in most cases, users that complain about this are trying to interface
data in a vector to a function that wants a pointer, and for them
the &*iter_T mechanism will do.
The most common case where I've needed to use the &* construction is to
pass data in a vector<T> to some function that wants a const T* and
perhaps a count.
Over a year ago, there was a discussion on c++std-lib@research.att.com
(see c++std-lib-7863) about adding vector::data() member function that
would be analogous to basic_string::data(). A function like that would
take care of the problem but, strangely, I don't see an issue about it
on the issues list or a formal proposal. Any takers? :)
Martin