ChatGPT解决这个技术问题 Extra ChatGPT

C++ STL Vectors: Get iterator from index?

So, I wrote a bunch of code that accesses elements in an stl vector by index[], but now I need to copy just a chunk of the vector. It looks like vector.insert(pos, first, last) is the function I want... except I only have first and last as ints. Is there any nice way I can get an iterator to these values?

If I'm not wrong, none of the answers does any bounds checks, which might be a problem. Specifically, std::advance docs say the behavior is undefined if you use it to get past the underlying container bounds.

d
dirkgently

Try this:

vector<Type>::iterator nth = v.begin() + index;

Generally, you can use the same arithmetic with STL iterators than with pointers. They are designed to be exchangeable when using STL algorithms.
@VincentRobert: Other way around. Pointers are valid implementations of STL random iterators, the most powerful category. But other, less powerful categories such as forward iterators do not support the same arithmetic.
I'd want ot add my five cents to this answer and recommend std::next(v.begin(), index)
b
bayda

way mentioned by @dirkgently ( v.begin() + index ) nice and fast for vectors

but std::advance( v.begin(), index ) most generic way and for random access iterators works constant time too.

EDIT differences in usage:

std::vector<>::iterator it = ( v.begin() + index );

or

std::vector<>::iterator it = v.begin();
std::advance( it, index );

added after @litb notes.


doesn't std::advance require a non-const iterator as the first argument?
you can use std::advance with const and non-const iterators
you should not trust msvc in that regard. it has a non-standard extension that makes it accept this kind of thing, nevertheless all other compilers behave standard and refuse it.
I think the problem is confusion over the meaning of "const": advance() will happily work on a const_iterator, which is a mutable iterator that refers to a const element of type T; it won't work on an iterator object which is itself const (i.e. "const iterator" or "iterator const").
If you know that you're dealing with a std::vector, there's no point in using std::advance. It only lures you into thinking you're writing container-agnostic code (which you don't, thinking of iterator invalidation rules, different runtime complexities and whatnot). The only case when std::advance makes sense is when you write a template yourself which doesn't know what kind of iterator it's dealing with.
V
Viktor Sehr

Also; auto it = std::next(v.begin(), index);

Update: Needs a C++11x compliant compiler


It should be noted that this is the C++11 way! std::next is equivalent to std::advance. Using these functions rather than using arithmetics makes swapping container types a lot easier. Even works on c-arrays afaik, just like std::begin and std::end.
for( auto it=begin(c); it != end(c); advance(it, n) ) { ... }
std::list lst; iterator fifth_element = *std::next(lst.begin(), 5);
Both have their uses. stda::advance is useful for altering the iterator in place. It's a performance concern in loops. I'd prefer next in the case of assignment, as you suggest. I just found it a bit harsh claiming it to be idiotic. Both functions were designed with different situations in mind, even though they are basically the same.
@Zoomulator: If copying your iterator is a performance concern, you have bigger issues to deal with.
S
SRG

You can always use std::advance to move the iterator a certain amount of positions in constant time:

std::vector<int>::iterator it = myvector.begin();
std::advance(it, 2);

y
yves Baumes

Actutally std::vector are meant to be used as C tab when needed. (C++ standard requests that for vector implementation , as far as I know - replacement for array in Wikipedia) For instance it is perfectly legal to do this folowing, according to me:

int main()
{

void foo(const char *);

sdt::vector<char> vec;
vec.push_back('h');
vec.push_back('e');
vec.push_back('l');
vec.push_back('l');
vec.push_back('o');
vec.push_back('/0');

foo(&vec[0]);
}

Of course, either foo must not copy the address passed as a parameter and store it somewhere, or you should ensure in your program to never push any new item in vec, or requesting to change its capacity. Or risk segmentation fault...

Therefore in your exemple it leads to

vector.insert(pos, &vec[first_index], &vec[last_index]);

Makes me wonder why they decided to abstract away to iterators if they're just pointers... they're essentially "hiding" these capabilities.
For consitency ? As it would allow you to easily remove vector instance for any other kind of container in your code so.
&vec[i] yields a pointer which is not necessarily compatible with vector<>::iterator. vec.begin()+i still has the benefit of being whatever iterator your library defines it to be -- including checked iterators in debug mode, for example. So, if you don't need a pointer (for I/O for example), you should always prefer iterators.
@KerrekSB From 23.3.6.1 in the c++ standard draft: "The elements of a vector are stored contiguously, meaning that if v is a vector where T is some type other than bool, then it obeys the identity &v[n] == &v[0] + n for all 0 <= n < v.size()"
@yvesBaumes: that has nothing to do with vector iterators. However, it is true that naked pointers are also iterators -- they're just not vector iterators.