4

I thought of this problem due to some of the answers I got to the following problem suggesting that I could use vector<T>::assign or copy with a back_insert_iterator here. My problem is, what are the drawbacks and advantages of using one method over another?

Community
  • 1
  • 1
nakiya
  • 14,063
  • 21
  • 79
  • 118

5 Answers5

5

assign overwrites the content of the vector where as copy with back_insert_iterator does a push_back on the vector thus preseving its content.

EDIT: If the question is generic (i.e. whether to use a member function defined in the container or an algorithm), I prefer to use the member function as it might have been optimized for the particular container compared to a generic algorithm.

Naveen
  • 74,600
  • 47
  • 176
  • 233
  • 1
    It may be optimized for the particular container, too. Vector, for example, can reserve() on assign() if given random access iterators, while making that optimization for copy() into a vector is ... rather difficult. –  Nov 11 '10 at 09:24
  • 2
    A better alternative to `copy` with a `back_insert_iterator` is to call `insert`, passing `end()` as the location at which to insert. – user200783 Nov 11 '10 at 09:28
  • Did you change "compiler" to "container" within the 5 minute window after seeing my comment, or am I going crazy? :P –  Nov 11 '10 at 10:58
  • @Roger Pate: Yes, I changed it from "compiler" (that was by mistake) to "container" after about 1 minute of posting. – Naveen Nov 11 '10 at 11:14
2

Complementing Naveen's answer, using std::copy() is also much more versatile, as this way you can easily write to any output iterator. This could be a stream or something entirely custom.

Community
  • 1
  • 1
Björn Pollex
  • 75,346
  • 28
  • 201
  • 283
2

In the general case, prefer member functions to functionally-equivalent algorithms. Scott Meyers discusses this in depth in Effective STL.

Steve Townsend
  • 53,498
  • 9
  • 91
  • 140
  • I disagree with Meyers in this case. – John Dibling Nov 11 '10 at 14:22
  • @John - in general, or specific instances? – Steve Townsend Nov 11 '10 at 15:37
  • 1
    As pertaining to preferring member functions or ``s, I disagree with Meyers in general on this point, because he is advocating what in many cases boils down to premature micro-optimization. There are however many exceptions to the rule, and you have to pick one side or the other if you're going to come up with a "prefer X" method. I'm not saying Meyers' advice is *bad*. I'm saying my *general* approach is to code for robustness & maintainability first, and improve performance second when there is a demonstrated need. There again are many exceptions to even this approach – John Dibling Nov 11 '10 at 15:45
  • +1 anyway though, because I think your answer gets to the root of what this question really *should* be about – John Dibling Nov 11 '10 at 16:02
1

In essence, they are the same. Vector's reallocation behavior (defined in terms of how it behaves with push_back) avoids too many reallocations by progressively using more memory.

If you need identical code to work with multiple container types (i.e. you're writing a template), including those containers not in the stdlib, then generally prefer free functions.

If you don't mind rewriting this code if/when container types change, then you can prematurely optimize if you like, or simply use whichever is more convenient.

And just for completeness' sake, copy+back_inserter is equivalent to vector::insert at the end(), while vector::clear + copy+back_inserter is equivalent to vector::assign.

  • But all sequence containers should have the necessary `assign` and `insert` methods? With user-defined containers one needs to assume either way that it has suitable member functions to support the generic code (either the above-mentioned or `push_back` for `back_inserter`) – visitor Nov 11 '10 at 10:28
  • @visitor: All of the stdlib containers have those, but I've written custom containers that don't meet all of the Sequence requirements. That's the point above: what interface is to be required. I find an iterator interface is, in these situations, more versatile and more easily adaptable for containers lacking it; so I prefer free functions for generic code. –  Nov 11 '10 at 10:55
1

Your question can be generalized as follows:

When dealing with STL containers, should I prefer to use member functions or free-standing functions from <algorithm> when there are functional equivalents?

Ask 10 programmers, and you'll get 12 responses. But they fall in to 2 main camps:

1) Prefer member functions. They are custom-designed for the container in question and more efficient than the <algorithm> equivalent.

2) Prefer free-standing functions. They are more generic and their use is more easily maintained.

Ultimately, you have to decide for yourself. Any conclusion you come to after giving it some reasoned, researched thought is better than following anyone else's advice blindly.

But if you just want to blindly follow someone's advice, here's mine: prefer the free-standing functions. Yes, they can be slower than the member functions. And "slow" is such a dirty word. But 9 times out 10 you just don't (or shouldn't) care how much more efficient one method is than the other. Most of the time when you need a collection, you're going to periodically add a few elements, do something, and then be done. Sometimes you need ultra-high performance lookup, insertion or removal, but not normally. So if you're going to come down one one side or the other with a "Prefer Method X" approach, it should be geared for the general case. And the approach that prefers the member methods seems to be slanted towards optimization -- and I call that a premature micro-optimization.

John Dibling
  • 99,718
  • 31
  • 186
  • 324