Namespaces
Variants
Views
Actions

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

From cppreference.com
(Pointer/iterator invalidation and vector::assign.: cmt.)
(Pointer/iterator invalidation and vector::assign.: cmt.)
Line 29: Line 29:
 
: Neither the simplified summary here nor the actual page ({{lc|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 [https://github.com/llvm-mirror/libcxx/blob/master/include/vector#L1372 clear and then a series of push_backs], obviously invalidating everything. GNU libstdc++ [https://github.com/gcc-mirror/gcc/blob/edd716b6b1caa1a5cb320a8cd7f626f30198e098/libstdc%2B%2B-v3/include/bits/vector.tcc#L249 is a little more careful] --[[User:Cubbi|Cubbi]] ([[User talk:Cubbi|talk]]) 12:09, 22 April 2016 (PDT)
 
: Neither the simplified summary here nor the actual page ({{lc|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 [https://github.com/llvm-mirror/libcxx/blob/master/include/vector#L1372 clear and then a series of push_backs], obviously invalidating everything. GNU libstdc++ [https://github.com/gcc-mirror/gcc/blob/edd716b6b1caa1a5cb320a8cd7f626f30198e098/libstdc%2B%2B-v3/include/bits/vector.tcc#L249 is a little more careful] --[[User:Cubbi|Cubbi]] ([[User talk: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 [http://eel.is/c++draft/container.requirements.general#12 <nowiki>[container.requirements.general]/12</nowiki>] kicks in, which would be obviously wrong. [[User:T. Canens|T. Canens]] ([[User talk:T. Canens|talk]]) 14:41, 22 April 2016 (PDT)
 
:: If there's no wording anywhere, I think we'll need an LWG issue, because otherwise the blanket wording in [http://eel.is/c++draft/container.requirements.general#12 <nowiki>[container.requirements.general]/12</nowiki>] kicks in, which would be obviously wrong. [[User:T. Canens|T. Canens]] ([[User talk:T. Canens|talk]]) 14:41, 22 April 2016 (PDT)
 +
:::Ah, it was implied by the old specification pre-[http://wg21.link/LWG2209 LWG2209], but that issue's resolution removed it. [[User:T. Canens|T. Canens]] ([[User talk:T. Canens|talk]]) 15:41, 24 April 2016 (PDT)

Revision as of 14:41, 24 April 2016

--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)