search

mattreecebentley / plf_list

A drop-in replacement for std::list with 293% faster insertion, 57% faster erasure, 17% faster iteration and 77% faster sorting on average. 20-24% speed increase in use-case testing.
https://plflib.org/list.htm
zlib License
151 stars 21 forks source link

make plf::list::erase compatible with std::list::erase #14

Closed gharveymn closed 4 years ago

gharveymn commented 4 years ago

The standard specifies that the ranged version of erase should return the iterator following the last removed element. This should rectify that. I've also slightly modified the tests involving erase for this. Looks good on GCC, Clang and MSVC.

mattreecebentley commented 4 years ago

Wow, that is terrible design on behalf of the standard library. Yikes. Returning a variable that doesn't change and which is supplied directly to the function. I dunno. Do we need this? Is there a use-case where people are going to lose out by not having the return variable? Genuinely asking.

gharveymn commented 4 years ago

Yeah, I haven't really found a use for it either. In fact, I only found the incompatibility because I misread the original definition. I'd guess that's it's pretty much for people who want to write their entire program in one line.

On the other hand, I don't think we really lose anything because the return will be optimized by the compiler. It's really just a question of if you want this library to be a drop-in replacement or not.

mattreecebentley commented 4 years ago

Yes, fair enough. I'll implement this, using your code - my preferred formatting is slightly different, and I don't want to include Quite so many tests of the return value of range erase, so I'll likely re-write rather than accept the pull, but will credit you with the changes in the commit notes :) Have tested the different solutions and you're right that the compiler seems to just optimize out.