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