Why are Sparta::Buffer::erase(const iter&) return type void? Does Sparta::Buffer:erase(const iter&) invalidate iterators? How to handle erase() in an iterator loop?

[timsnyder]

In

map/sparta/sparta/resources/Buffer.hpp

Lines 663 to 683 in e876f58

	/**
	* \brief erase the index at which the entry exists in the Buffer.
	* \param entry a reference to the entry to be erased.
	*/
	void erase(const const_iterator& entry)
	{
	sparta_assert(entry.attached_buffer_ == this, "Cannot erase an entry created by another Buffer");
	// erase the index in the actual buffer.
	erase(entry.getIndex_());
	}
	/**
	* \brief erase the index at which the entry exists in the Buffer.
	* \param entry a reference to the entry to be erased.
	*/
	void erase(const const_reverse_iterator& entry)
	{
	sparta_assert(entry.base().attached_buffer_ == this, "Cannot erase an entry created by another Buffer");
	// erase the index in the actual buffer.
	erase(entry.base().getIndex_());
	}

The return types of Sparta::Buffer::erase(const iter&) are void. Based on the STL semantics for erase(), I would expect them to return a copy of the iterator adjusted for the erasure. Does Sparta::Buffer::erase() invalidate the iterator?

For example, with a std::vector, I would expect to need to handle iterator invalidation something like:

#include <vector>


int main() {
    std::vector<int> junk = {1,3,5,7,9};

    for(auto itr = junk.begin(); itr != junk.end();) {
        if (*itr == 5) {
            itr = junk.erase(itr);
        } else {
            itr++;
        }
    }
}

Do I need to worry about the same type of thing with Sparta::Buffer or is the iterator somehow not invalidated by Sparta::Buffer::erase()?

[klingaard]

No, there's no good reason that it doesn't return the next iterator. I think this was based on an older C++ STL design. In fact, there are a few issues with Buffer, Queue, etc that I already started documenting here: #247

Feel free to convert this to an issue and either make the changes or leave it unassigned and I'll grab it.

[klingaard]

Converted to issue #464