3

std::vector::erase will accept either a single iterator denoting the position of the element to be erased, or two iterators denoting a range. But you can't do this:

std::vector<int> vec = { 1, 2, 3 };
vec.erase(1);

Rather you have to do something like

vec.erase( vec.begin()+1 );

This seems like needless extra work--just wondering, is there some reason from the POV of class design why this overload wouldn't be included?

Edit: Chose the most comprehensive answer, all were good. Also as I write this this post has 4 close votes for being 'not constructive'; however, given the quality of the answers I think this was clearly a useful question, certainly for me.

Matt Phillips
  • 9,465
  • 8
  • 44
  • 75
  • 7
    Syntactic sugar can lead to cancer of the semicolon. – David Schwartz Sep 17 '12 at 20:25
  • 3
    I would argue that the use of indexes is the real philosophical problem here. You shouldn't be using those to access your vector unless there's really some particular intrinsic meaning to the index (like in a permutation) - but those situations are rare compared to "normal" container use. – Kerrek SB Sep 17 '12 at 20:35
  • @KerrekSB Ha you know what? I looked at my pre-`C++11` code where this issue came up and indeed, now with `C++11` `lambda`s it's cleaner to do the indexing I wanted with iterators. – Matt Phillips Sep 17 '12 at 20:39

3 Answers3

2

My understanding is that the stl wants to seperate indeces and integers as they are not the same thing (sementically): If you want to do arithmetics use integer, if you want to access an element in an stl container use an iterator. Also it serves abstraction: Often integers can serve as index, sometimes it doesn't make sense.

Mene
  • 3,739
  • 21
  • 40
  • 2
    [Be careful with term "STL".](http://kera.name/articles/2010/08/it-is-not-called-the-stl-mmkay/) – Griwes Sep 17 '12 at 20:34
  • 1
    @Griwes: I am often ridiculed because I insist on "std lib != STL", but even I can't think of a reason for not using the term "STL" for those parts of the std lib that derive from it. – sbi Sep 17 '12 at 20:37
  • @sbi, that's why I said "be careful with it" rather than "it's not STL!!!1111one" ;) – Griwes Sep 17 '12 at 20:39
  • Good point! I wasn't aware of the history of "STL", guess I'll have to read a bit ;D – Mene Sep 17 '12 at 20:39
  • Though I may conclude that the initiator of the original STL was thinking something like I said in my post ;P – Mene Sep 17 '12 at 20:41
2

Imagine if you had

typedef std::set<int> MyContainer
MyContainer c;
// ...
c.erase(5);  // Or a programmatic int

Now if you change the underlying container of MyContainer (by updating the typedef) to vector all of a sudden your erase has completely changed in semantic meaning and still compiles! I can't think of any other case where such a simple change of container type would result in such different behavior.

To avoid that, erase has only value or iterator inputs, never index.

Mark B
  • 95,107
  • 10
  • 109
  • 188
1

There are two reasons I can think of:

1) erase is common member function for containers. Using indices only make sense for some containers, so by using iterators you do not have to worry about the type of container you are working on. For example, indices only make sense for random-access containers, by using iterators you make your code more flexible, etc.

2) erase works well with the standard algorithms like std::remove, std::remove_if, std::unique, etc. It is much more common to want to erase elements based on some predicate, etc. rather than hard coding an index number. Look up "erase-remove idiom" for more information.

Basically, iterators are consider to be superior to indexing for many reasons and is what you will see used extensively in the C++ standard library. Indices are merley provided for simulated array access were it makes sense.

Jesse Good
  • 50,901
  • 14
  • 124
  • 166
  • Good, #2 especially is relevant to me. `C++03` made defining predicates such a chore, numeric indexes were easier. But now with `lambda`s the very code which inspired this question could be rewritten more efficiently just with iterators. – Matt Phillips Sep 17 '12 at 21:36