469,644 Members | 1,982 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,644 developers. It's quick & easy.

Question about STL Vector design

I have a question about the design of STL vector. One thing I wonder
was why the STL designers chose to have the insert() and erase()
functions take an iterator as the first argument, rather than simply
an array index integer referring to a position in the array.

The reason I wonder this is because firstly, the implementation will
need to convert the iterator to an array index integer anyway, because
the iterator may become invalidated if a reallocation occurs, and
secondly, it's easier to simply type something like vec.erase(5)
rather than vec.erase(vec.begin() + 5).

I suppose the reason they did it was so that you can easily swap a
std::vector with an std::list or something else in your code without
breaking the code. But does anyone agree with me that it makes more
sense for a vector, at least, to take an array index integer rather
than iterator for erase/insert, particularly because the iterator may
become invalidated anyway after the operation?

Oct 12 '07 #1
3 2657
ch******@gmail.com wrote:
I have a question about the design of STL vector. One thing I wonder
was why the STL designers chose to have the insert() and erase()
functions take an iterator as the first argument, rather than simply
an array index integer referring to a position in the array.
Probably because all of the standard algorithms use iterators and not
all of the standard containers have index operators.
The reason I wonder this is because firstly, the implementation will
need to convert the iterator to an array index integer anyway, because
the iterator may become invalidated if a reallocation occurs, and
secondly, it's easier to simply type something like vec.erase(5)
rather than vec.erase(vec.begin() + 5).
Why would it have to perform a conversion? An iterator identifies a
position in a vector.

--
Ian Collins.
Oct 12 '07 #2
On Oct 12, 1:55 pm, chsal...@gmail.com wrote:
I have a question about the design of STL vector. One thing I wonder
was why the STL designers chose to have the insert() and erase()
functions take an iterator as the first argument, rather than simply
an array index integer referring to a position in the array.

The reason I wonder this is because firstly, the implementation will
need to convert the iterator to an array index integer anyway, because
the iterator may become invalidated if a reallocation occurs, and
secondly, it's easier to simply type something like vec.erase(5)
rather than vec.erase(vec.begin() + 5).

I suppose the reason they did it was so that you can easily swap a
std::vector with an std::list or something else in your code without
breaking the code. But does anyone agree with me that it makes more
sense for a vector, at least, to take an array index integer rather
than iterator for erase/insert, particularly because the iterator may
become invalidated anyway after the operation?
Sounds reasonable to me, esp for vector and deque. After all map's and
set's erase members are able to take a Key const& as well as an
iterator. vector and deque indexes are very much like keys, so why
shouldnt it be able to take an index? The only difference would be
that after you erased the index (that is not end()-1), an element
could actually still exist at that index (which is unlike a key). But
this behavior is the same as if it were an iterator erase, so I dont
see much objection about "correctness." i.e. even after you do an
iterator erase (that is not next to last), the iterator is still
valid, it just points to something different.
Post your suggestion on comp.std.c++ and see what sort of feedback you
get. They would even tell you how to submit your idea to the standards
committee.
Lance

Oct 12 '07 #3
On 2007-10-12 19:55, ch******@gmail.com wrote:
I have a question about the design of STL vector. One thing I wonder
was why the STL designers chose to have the insert() and erase()
functions take an iterator as the first argument, rather than simply
an array index integer referring to a position in the array.
Probably since all the STL containers and algorithms operate on
iterators, it would be a shame to leave vector out of all the good stuff
that the other containers enjoy.
The reason I wonder this is because firstly, the implementation will
need to convert the iterator to an array index integer anyway, because
the iterator may become invalidated if a reallocation occurs, and
secondly, it's easier to simply type something like vec.erase(5)
rather than vec.erase(vec.begin() + 5).
First, the implementation does not have to convert it to an index, just
check if the iterator refers to the current element. And even if you
want to convert it to an index that would not be very hard. Second, the
iterator will only be invalid *after* the call to erase. Third, if you
know the index it is very easy to get an iterator to that element:

std::vector<T>::iterator it = vec.begin() + index;
I suppose the reason they did it was so that you can easily swap a
std::vector with an std::list or something else in your code without
breaking the code. But does anyone agree with me that it makes more
sense for a vector, at least, to take an array index integer rather
than iterator for erase/insert, particularly because the iterator may
become invalidated anyway after the operation?
The iterator will become invalid after the operation, always. And no it
does not make sense to make vector a special case when you can just do

vec.erase(vec.begin() + index);

to get what you want.

--
Erik Wikström
Oct 12 '07 #4

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

7 posts views Thread by Jessica | last post: by
12 posts views Thread by BCC | last post: by
31 posts views Thread by grahamo | last post: by
4 posts views Thread by alacrite | last post: by
8 posts views Thread by indrawati.yahya | last post: by
7 posts views Thread by Renzr | last post: by
reply views Thread by gheharukoh7 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.