Namespaces
Variants
Views
Actions

Talk:cpp/container/forward list

From cppreference.com

std::forward_list never existed before C++11. So why is it mentioned (until C++11?) T must meet the requirements of CopyAssignable and CopyConstructible. (until C++11) The requirements that are imposed on the elements depend on the actual operations performed on the container. Generally, it is required that element type meets the requirements of MoveConstructible and MoveAssignable, but many member functions impose stricter requirements.

--Balki (talk) 13:16, 9 January 2014 (PST)

Simply because Template:cpp/container/param_list_T was not specialized for C++11-only containers. Thanks for pointing that out, it will be fixed soon. --Cubbi (talk) 16:22, 9 January 2014 (PST)
Ouch, I guess I stepped on your toes. Sorry for that. --P12 16:29, 9 January 2014 (PST)
No worries! --Cubbi (talk) 16:59, 9 January 2014 (PST)


The second paragraph could use some clarification. In the phrase "Addition, removal and moving..." does this mean "addition or removal of elements" or "Additionally, removal...". Also, as it is it says that removal of elements does not invalidate the iterators but deletion of the the element does. Is this really what is meant (i.e., you can take the element out of the list but until you call delete on it the iterators are still OK)? I can make the change after this point is clarified Arbalest (talk) 15:19, 18 April 2014 (PDT)

indeed, "removal" and "deleted" are meant to refer to the same action (erasing an element from the container: that action invalidates references and iterators to the element being erased, and does not invalidate references or iterators to any other element). Likewise, "addition" is really insertion. --Cubbi (talk) 17:18, 18 April 2014 (PDT)
OK, made the change and also looked at the spec. The spec is a bit troubling in that it mentions that an iterator referring to an element is invalidated when the element is deleted via erase_after() [section 23.3.4.5]. Why does it mention that way to remove an element and not the other ways including clear() or pop_front()? Arbalest (talk) 19:48, 18 April 2014 (PDT)
Yeah, that's a little funny. Maybe it's because e.g. pop_front is defined in terms of erase_after, so the invalidation semantics are implied? And maybe clear is missing semantics because it's kind of obvious that clearing a list will invalidate any iterators pointing at the list? --Nate (talk) 08:19, 19 April 2014 (PDT)