Talk:cpp/container

Is there a reason the table does not have std::list "Operations", such as 'remove' and 'splice'?

69.84.133.248 12:11, 28 June 2012 (PDT)

Feel free to add any missing functions. -- P12 16:02, 28 June 2012 (PDT)

---

There might be some minor issues with the grid but looking at the "edit" tab I don't see a way to change it myself. Also, since I don't know if the to following is intentional I might not change it anyway. So here are what I see:

1) For the last three columns "emplace" is sharing the row for "emplace back" rather than being on the "emplace" row. Also, it seems like it should be lime green rather than violet.

2) "pop" is inconsistently sharing a row with "pop front" and "pop back" - even if it must share a row rather than have it's own.

3) "top" is inconsistently sharing a row with "front" and "back" - even if it must share a row rather than have it's own.

Arbalest (talk) 18:10, 12 September 2013 (PDT)

Ad 1: The location is correct -- emplace on queue/stack is the inplace variation of push, and is an operation on the back of the container. All non-queue/stack emplaces take a position (key or index), and do not apply to the back of the container.

Ad 2: The location is now correct (it was indeed wrong for priority_queue). For stack pop() applies to the back of the container, for a queue it applies to the front.

Ad 3: The location was and is correct: for stack the top is the back of the container, for queue the top is the front. The whole point of stack and queue is to make the programmer not need to think too hard about conventions about front/back, but rather think in terms of push/pop/top.

Jeroen (talk) 03:20, 4 May 2015 (PDT)

We should probably mention that it is illegal to create containers with incomplete types

I bumped on this article http://www.drdobbs.com/the-standard-librarian-containers-of-inc/184403814 , which quotes the Standard saying: "the effects are undefined ... if an incomplete type is used as a template argument when instantiating a template component". It is worth noting that the author of this article happens to be "the chair of the C++ standardization committee's library working group".

This is an interesting information. I, for example, have never known this. I think this might be worth noting both on this page, as well as on http://en.cppreference.com/w/cpp/language/type#Incomplete_type .

However, the article dates back to 2002, and it says itself that "in a future revision of C++, it might make sense to relax the restriction on instantiating standard library templates with incomplete types", although "clearly, the general prohibition should stay in place". Which is why I do not know how how correct this info is as of C++11 or C++14.

The curious thing is that both code snippets the article's author explicitly provides as examples of illegal constructs (the one with vectors and the one with maps) seem to work for me, both in gcc and in clang. Sure, the article says itself that the vector one tends to be supported nevertheless – yet elsewhere the article claims that it would be a pain to implement such functionality with sets, and still doing the same with sets works for me.

Incomplete types were indeed not allowed, but they are allowed now. It's part of type requirements for the containers on this wiki, e.g. see cpp/container/vector#Template_parameters. Perhaps it should say "complete type" explicitly in the pre-C++11 section. --Cubbi (talk) 18:31, 21 December 2015 (PST)

pop function of priority_queue should base on underlying container's pop_back

There seems a mistake in Member function table: pop function of priority_queue should base on underlying container's pop_back member function, instead of pop_front. What's your opinion? Thanks. Wljin (talk) 07:51, 20 August 2017 (PDT)

pop for priority_queue removes the top (i.e., front) element of the priority queue, and so is logically a pop_front. It's indeed implemented by pop_back, but that's not what the table is about. T. Canens (talk) 11:12, 20 August 2017 (PDT)

But isn't it inconsistent with push, which does not necessarily append an element to the end, but still shares a row with push_back? --D41D8CD98F (talk) 05:32, 21 August 2017 (PDT)

Unordered containers, rehash and iterators validity

We probably should describe (on this page) the iterators/references validity after direct invocation of rehash() of any unordered container, e.g. unordered_map::rehash. For instance, the datum such as "unordered_map→Iterator invalidation" could be summarized and appended to that table (or somewhere else). --Space Mission (talk) 14:18, 7 May 2021 (PDT)

span/mdspan: views, rather than containers

Despite convention, I propose not to classify span/mdspan as containers. They do not 'contains' anything for they are no more than views, so I can hardly put them into the container table, either. On the other hand, they are not mentioned everywhere else other than their own 'Views' section in this page, showing their independence and isolation.

More aggressively I'd like to put basic_string into the container table, since it behaves quite like a container and has many common functions with containers.

--Yaossg (talk) 01:44, 23 September 2022 (PDT)

I agree with leaving span/mdspan from this page for the stated reasons. --Ybab321 (talk) 23:02, 23 September 2022 (PDT)

I have downgraded span/mdspan to cpp/container#See also. Agreed with std::basic_string reasoning too, with appropriate remark or footnote that IS does not treat it as a standard container (though it satisfies at least Container, I guess), but in practice it can be used as such, obviously, as once was hinted here: Brian Ruth “std::basic_string: for more than just text” CppCon 2018 Lightning Talk, 00:04:38... --Space Mission (talk) 10:55, 24 September 2022 (PDT)

Move the table out

I propose we move the (non-)member function tables out to their own page; they're stretching out the webpage and they're not really all that useful (to justify having in the overview page) --Ybab321 (talk) 09:44, 20 February 2023 (PST)