Difference between revisions of "Talk:cpp/container/vector"

Revision as of 01:23, 29 January 2018

--BohdanKornienko (talk) 13:23, 16 October 2013 (PDT)

Small example to use vector header:

#include <iostream>
#include <vector>

int main(int argc, char **argv)
{
    std::vector<int> vec;

    vec.insert(vec.begin(), 1);
    vec.insert(vec.end(), 2);
    vec.insert(vec.end(), 3);

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

    std::cout << "count: " << vec.size()
        << "\ncapacity: " << vec.capacity() << std::endl;

    return 0;
}

Pointer/iterator invalidation and vector::assign.

Does vector::assign invalidate iterators? It's not on the list, but I have to assume that if the new size blows the capacity, they have to be invalidated, right? What does the standard say about this?

Neither the simplified summary here nor the actual page (std::vector::assign) say anything about invalidation because the standard (Table 107 — Sequence container requirements) does not say anything about invalidation; it just says "Replaces elements ... with copies of". For input iterators, LLVM libc++ just calls clear and then a series of push_backs, obviously invalidating everything. GNU libstdc++ is a little more careful --Cubbi (talk) 12:09, 22 April 2016 (PDT)

If there's no wording anywhere, I think we'll need an LWG issue, because otherwise the blanket wording in [container.requirements.general]/12 kicks in, which would be obviously wrong. T. Canens (talk) 14:41, 22 April 2016 (PDT)

Ah, it was implied by the old specification pre-LWG2209, but that issue's resolution removed it. T. Canens (talk) 15:41, 24 April 2016 (PDT)

Wrong description of operator[]

It currently describe operator[] as "access or insert specified element", which is incorrect, since std::vector::operator[] never inserts an element, unlike std::map::operator[]. This is because the description uses the standard operator_at template. I'd argue it's better to give a correct description. 2620:0:105F:2:6169:A7F:B58D:284B 01:23, 29 January 2018 (PST)