Talk:C plus plus:Modern C plus plus:Vectors

From GPWiki

( For reference, http://gpwiki.org/index.php?title=C_plus_plus%3AModern_C_plus_plus%3AVectors&diff=15223&oldid=15183 is the removal being discussed below )

Why was all of 84.56.154.73 text removed? It contained some useful and unbiased information that could have been modified.

I don't know, but it's the second time me22 removed a contribution of mine. Is he an actual or a self-declared mod for this wiki? The article is already totally biased (see the do-it-yourself vs. vector comparison. Propably the worst implementation he could think of, just to proove his point), maybe me22 just wanted to keep it that way... --Tannin

I agree, it's a bad implementation, but it's also the straight forward, intuitive (if naive) one that would quite likely be used, which is the whole point. The points about the code being easier to write and exception safety are also valid even for a more complex solution. If you can come up with a faster way that doesn't involve tracking a capacity, let's see it. By the time you're passing in a pointer, a size, and a capacity to a function, it's time to wrap it up in a class anyways at which point you're jsut recreating std::vector.

Furthermore, this one article is not the be all and end all of Containers. The point here is to get people that were using new[] to switch to vector, without dragging in complications. Also, Section 23.1.1 of the ISO C++ Standard says "vector is the type of sequence that should be used by default". A discussion of choosing a container doesn't belong here either, as the other containers have not yet been mentioned. It will, however, be added to the Containers page where it belongs.

My issues with what was added:

* The iterator invalidation part would be better discussed on the iterators page, when iterators have been properly introduced. That way checked std::lib implemnentations can be mentioned, which make that kind of bug very easy to find, so long as you remember that iterators aren't pointers.

* The list of functions that invalidate iterators is wrong. The whole point of reserve on a vector is to make it possible to know that push_back or resize will not cause reallocation, while under capacity. Reserve itself also does not nessesarily reallocate, as reserve cannot shrink the capacity of a vector. pop_back will never reallocate, for exception safety and because they're only shrinking size, which does not change their capacity. clear could safely reallocate without exception safety trouble, but that would shrink capacity, which isn't allowed, so it will never reallocate either. Not to mention that keeping pointers to something in a container that you've cleared is obviously stupid anyways.

* list is not a great replacement either, because (barring a custom allocator), a list push_back involves a heap allocation of the node, which is much slower than a below-capacity push_back in a vector, and for small n or cheap-copy elements (such as memcpy'able PODs), even a reallocation will be cheaper than all the new'ing in using a list. To avoid the big-block-of-memory issue with a vector, a deque is a much better choice.

Hope that clears things up,

--me22 10:37, 4 May 2006 (EDT)

Next time you should probably let it be known why you reverted a legitimate edit (like you're doing now) instead of just rolling it back. If you roll back edits with no explanation there's nothing to stop Tannin (for example) to go ahead and re-add his additions if the thinks it is correct, and then we go back and forth. Also (not sure if it applies in this case), but if the addition contains useful information in the wrong place and you don't want to edit it and would rather just remove the section to keep the article clean, move the addition to the talk page instead for someone else (or yourself) to edit later. - sik0fewl 13:13, 4 May 2006 (EDT)

I do think it's rude to remove a contribution from a public wiki without explanation just because you don't agree with it. Since this is not a tutorial but a wiki, you can't expect exeryone reading articles in the order you write them. I think an article about std::vector should contain information about how and when to use it, not only 5 sections about how great they are and that everyone should always use them for every problem and then explain limitations in another article... Or, if you want this article to be pure advertisement for stl at least add a node at the top "This article is biased and wants to stay like that".

Otherwise, if you don't agree with a contribution or find a mistake, please just correct it or add your opinion, don't just delete it without comment. I'm not going around deleting your contributions I don't agree with. --Tannin

Actually, it *is* a tutorial. This isn't an article about std::vector, it's a tutorial on "Modern C++" and this is the chapter about std::vector. See the top of the page for the other "chapters" in this tutorial. In particular, you should read "Preface", as it gives exactly what you just asked for. - sik0fewl 13:58, 4 May 2006 (EDT)

Agreed. However, I still agree with Tannin that it's bad form to remove content without explanation. In the future, please give an explanation, and attempt (where possible/needed) to find a new home for the content rather than removing it outright. --Ryan Clark 15:06, 4 May 2006 (EDT)

I have added the content in question (modified to remove the misinformation and fit with the page) to C_plus_plus:Standard_Template_Library#Vector and C_plus_plus:Standard_Template_Library#List, where I believe it fits better. That page is more of a reference and hopefully closer to Tannin's goal of keeping all the information together.

The idea for the whole series to be treated like one book, separated into chapters for organization and avoiding a gigantic page. I mentioned in the preface the intent to keep chapters building on the previous ones. If someone reads only the vectors chapter and that results in that person using vector in many places, perhaps some of which it's not the ideal choice, then the chapter has done its job. Introducing extra topics is more likely to scare them away and have them go back to new[], which is worse than misusing vector. If the reader ends up in a situation that vector is desperatly ill-suited for, perhaps he'll remember the What's Next section mentioning other possibilities, or could easily be pointed back to the next chapter after asking for help in a forum post or chat room.

And yes, the article is (slightly) biased. As sik0fewl mentioned, however, the preface is there to explain the starting assumptions and goals of the series. It's intended to promote the Standard Library. I don't, however, think that's it's unreasonably biased. I've tried to be careful to keep the information precise and accurate, with statements appropriately qualified. For example, I do not claim that std::vector is faster than new[], only that in the example (whose code is readily available) one version was measured to be faster than the other. There is also a (parenthetical) note there linking to an explaination of why the vector version is faster.

I also object to the claim that I removed content because I "don't agree" with it. The content was imprecise, wrong in places, and didn't fit with the clearly stated organization and goals of the series. Nor was any effort made in the wikilinks to link to pages that actually exist, when in both cases (iterators and std::list) there were good targets in both the Modern C++ series and elsewhere in the wiki. I accept and agree with most of the other criticism, and will endeavour to avoid these problems in the future. For this case, I believe that my recent edits have managed to cover most of the concerns and have explicitly mentioned all issues that were raised in Tannin's edit, though in a different chapter.

--me22 02:13, 5 May 2006 (EDT)

Thanks for taking care of this, me22. --Ryan Clark 22:35, 4 May 2006 (EDT)

That seems to be the best solution. I'm sorry for any problems caused. I'm just starting to contribute and I felt a bit annoyed by my contributions being rejected like this, that's all.--Tannin 04:24, 5 May 2006 (EDT)