Difference between revisions of "Talk:cpp/container"

Revision as of 07:44, 22 September 2022

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. (perhaps adding some 'see also' links to strings would be more appropriate in this sense). Due to facts above, I can hardly put them into the giant container table, either.