Click here to Skip to main content
15,887,214 members
Please Sign up or sign in to vote.
0.00/5 (No votes)
See more:
Hi!
I wonder if there is any particular reason for why the default std::list in C++0x11 doesn't support removal of a node in O(1) time. I could just use a hashset and achieve O(1) removal time but then a constant for the hash function is added which isn't really necessary.

The current remove function requires O(n) and I understand how it's implemented but not why one can't access the nodes and just remove them directly since you then already would have the pointer to the node (and therefore also to previous and next node). However I can implement it myself but find it rather strange that such a basic function in my opinion, is missing from the standard library. I suspect it has to do with the memory management principles, I'm I right.

Thankful for all help, feel free to correct me if I'm wrong and I don't proclaim I'm an expert in C++ but I have a lot of experience from Java and C#.
Posted

1 solution

If it could use a hashset, it would not be a list anymore. A hashset does not allow duplicates, but the list does allow them; also, list supports certain item order and access by index, which is O(1) is is the fastest. (You can combine those two features by, say, using a hashset of lists, where each list represents all duplicates, but it hardly makes much practical sense :-).)

Now, it's not clear the time computational complexity of what problem do you mean. If you want to remove the element by its value, the operation will first need the search of the item by its value; and the search itself will be of O(N). This is because the node should first be found; and the only way to find it is the test the items sequentially, until the item is found.

But if you already have the preexisting knowledge of the index of the item to be removed, this is the different story, and will depend on a particular implementation. According to this specification, this should be a doubly-linked list. In this case, the removal time complexity should be of O(1).

If the list implementation is based on the array, the removal will still depend on the size of the list, because the elements following the one being removed should be all relocated to fill the gap produced.

—SA
 
Share this answer
 
v4
Comments
Matthew Faithfull 28-Mar-13 13:56pm    
A good explanation, my 5.
Sergey Alexandrovich Kryukov 28-Mar-13 13:58pm    
Thank you, Matthew.
—SA
Matt T Heffron 28-Mar-13 13:57pm    
"the search itself will be of O(1)."
Shouldn't that be O(N)? (Or am I missing something?)
( Searching a sequential collection is O(N). )
Sergey Alexandrovich Kryukov 28-Mar-13 13:58pm    
This is of course a typo. Thank you very much for the note, I've just fixed it, and added one more clause about the search by value.
—SA
WaZoX 28-Mar-13 18:17pm    
"According to this specification, this should be a doubly-linked list. In this case, the removal time complexity should be of O(1)."
Yes! That's exactly what I mean but in the implementation it's linear in container size. My question is if there is any particular reason for being so. I'm interested in this because I'm coming from C# and there you already have this features in the standard library and I can't really see the use of a linked list where you can't access the internal nodes.
(reference http://www.cplusplus.com/reference/list/list/remove/)

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)



CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900