Talk:Vector (C++)
This redirect does not require a rating on Wikipedia's content assessment scale. It is of interest to the following WikiProjects: | |||||||||||||||
|
Text and/or other creative content from this version of Vector (C++) was copied or moved into Sequence containers (C++) with this edit. The former page's history now serves to provide attribution for that content in the latter page, and it must not be deleted as long as the latter page exists. |
Requested move
[edit]- The following discussion is an archived discussion of the proposal. Please do not modify it. Subsequent comments should be made in a new section on the talk page. No further edits should be made to this section.
The result of the proposal was no consensus to move. JPG-GR (talk) 18:45, 26 March 2008 (UTC)
Maybe std::vector would be a better title - it's more precise, and doesn't require any disambiguation. --Zundark 15:57, 24 July 2006 (UTC)
I actually agree with this. std::vector is much more appropriate.Dlother (talk) 18:20, 21 February 2008 (UTC)
- OK, I've now listed it at Wikipedia:Requested moves, so we'll see what happens. (I think it could be moved without admin intervention, but I'm doing it this way to encourage discussion.) --Zundark (talk) 11:26, 7 March 2008 (UTC)
- I am concerned that the WP software will attempt to read std, or std: as a namespace; could we have some reassurance on that? Septentrionalis PMAnderson 16:34, 7 March 2008 (UTC)
- There's not usually a problem with colons in an article name - the software doesn't interpret the preceding string as a namespace or interwiki prefix unless it has been defined as such. So, for example, the software treats Alive: The Story of the Andes Survivors as being in the article namespace. --Zundark (talk) 13:06, 8 March 2008 (UTC)
- I am concerned that the WP software will attempt to read std, or std: as a namespace; could we have some reassurance on that? Septentrionalis PMAnderson 16:34, 7 March 2008 (UTC)
I don't agree. Wikipedia is an encyclopedia, not a reference manual. I understand that other languages provide very similar constructs. In my opinion, this page should be primarily about this construct and its implementation, rather than about the particular syntax of C++. (I'm not going to be militant about this; just recording my opinions since you asked for discussion.) Sam Staton (talk) 13:56, 8 March 2008 (UTC)
- Ahh. I see this is discussed at Wikipedia talk:WikiProject C++#Wikipedia is not a programming manual. Guideline WP:NOT#MANUAL is relevant. Changing the name to std::vector brings this one step further to a reference manual (if we're not there already). Sam Staton (talk) 14:07, 8 March 2008 (UTC)
- Oppose per the general naming conventions, "article naming should prefer what the greatest number of English speakers would most easily recognize" and "the names of Wikipedia articles should be optimized for readers over editors, and for a general audience over specialists." The proposed title reads like something only familiar to a reader already experienced in the subject. Also though, I do not think "(STL)" is a good disambiguator, for the same reasons. Should be Vector (Standard Template Library) or similar. Horsesforcorses (talk) 11:36, 9 March 2008 (UTC)
- The above discussion is preserved as an archive of the proposal. Please do not modify it. Subsequent comments should be made in a new section on this talk page. No further edits should be made to this section.
Side Box
[edit]Why isn't there a template with a box on the right linking this to all the other STL pages? (or C++ Standard Library pages, for that matter?) This should be worked on. Figs 21:35, 4 March 2007 (UTC)
Disputed
[edit]I have tagged the article because I think it makes a quite a few dubious or outright false claims. Examples:
- Vectors can store any type (false)
- Erases all of the elements. (For most STL implementations this is O(1) time and does not reduce capacity) (dubious)
- (...)the address of the (zero-indexed) 7th element in a vector v is &v[6]. (begging the question)
I'll get to fixing these issues shortly. decltype 10:51, 29 January 2009 (UTC)
- How is the third one "begging the question"? 68.239.78.86 (talk) 23:03, 23 March 2009 (UTC)
- It may be that my use of the term begging the question was inaccurate. If you mentally "translate" &v[6] to English, and read the sentence out loud, you get something like:
“ | the address of the (zero-indexed) 7th element in a vector v is the address of the 7th element (zero-indexed) of the vector v | ” |
- As such the sentence fragment provides little useful information. Begging the question may not be the right term, however. decltype (talk) 06:38, 24 March 2009 (UTC)
- I don't think it's a tautology. The truth of the statement (the original, not your translation) is contingent on what operator[] returns. In general, that could be anything, in terms of both type and value. Even for a somewhat vector-like class, it could be something other than a reference to the internal storage of the element. v[6] does not translate to "a reference to the 7th element of the vector v", it translates to "the value returned by v[6]". 68.239.78.86 (talk) 13:07, 24 March 2009 (UTC)
- Yeah, I agree, good point. operator[]'s semantics are described earlier in the article, though. But now that you mention it, the C compatibility example could have been more clear on the use of &v[0], which may be confusing. decltype (talk) 13:24, 24 March 2009 (UTC)
- I've removed the O(n) note on vector::clear (unsourced, probably because it's O(1) for vectors of POD) and the "For most implementations" qualification on "this does not reduce capacity" (equally unsourced, and such implementations would violate the standard, see LWG 1102) —Preceding unsigned comment added by 82.210.249.81 (talk) 12:51, 23 November 2010 (UTC)
Renaming this article to follow a consistent convention
[edit]Hi, I am currently considering renaming this article to conform to a common convention for C++ Standard Library components. The full discussion can be found here. decltype 09:46, 6 March 2009 (UTC)
Paraphrasing
[edit]In the Pros and cons section, one can read the two following statements:
- One major benefit of vectors is that they also allow random access; that is, an element of a vector may be referenced in the same manner as elements of arrays are by array indices whereas linked-lists and sets do not support random access or pointer arithmetic.
- Vectors allow random access; that is, an element of a vector may be referenced in the same manner as elements of arrays (by array indices). Linked-lists and sets, on the other hand, do not support random access or pointer arithmetic.
The second paragraph was contributed later on, did the author forget to remove the first one? Erebadan (talk) 04:29, 27 May 2009 (UTC)
- Removed duplicate entry. Nice find. decltype (talk) 05:23, 27 May 2009 (UTC)
vector is in the template library
[edit]There shouldn't be any argument that vector is part of the standard template library. If you think that it isn't, go argue that point with the sidebar people. —Preceding unsigned comment added by 141.189.251.1 (talk) 15:15, 1 September 2009 (UTC)
- I suppose I should. This article describes the vector class template of the C++ Standard Library. While this template is largely based on the vector class template in the original 1995 STL, ISO C++ as described in ISO/IEC 14882:2003 has no notion of the Standard Template Library. decltype (talk) 15:29, 1 September 2009 (UTC)
- I'm going to go ahead and change this page to say Standard Template Library to keep it in aligned with the side bar. If you have the sidebar changed, you can change this as well. That way there won't be a confusing discrepancy. 141.189.251.1 (talk) 12:46, 4 September 2009 (UTC)
- Well, two wrongs does not make a right :) I'll see what I can do about the sidebar. Regards, decltype (talk) 12:50, 4 September 2009 (UTC)
- I'm going to go ahead and change this page to say Standard Template Library to keep it in aligned with the side bar. If you have the sidebar changed, you can change this as well. That way there won't be a confusing discrepancy. 141.189.251.1 (talk) 12:46, 4 September 2009 (UTC)
Other languages
[edit]I know this is written as a C++ article, but should some mention be made about the existence of the Vector data structure in other languages? I know for sure that Java has them, and I'm sure there are others as well. Perhaps this should be given a more generic name, such as "Vector (programming)" or "Vector (data structure)" (to distinguish it from programming geometrical vectors). And maybe some code samples from other languages could be added. Much of the rest of the article would be true for any language, so it seems redundant to create a new article for each language (e.g. "Vector (Java)", etc.) Lurlock (talk) 21:33, 26 December 2009 (UTC)
Useage example
[edit]well, maybe I'm slow but from the example, "It is located at index 6 (implementation-dependent)" makes no sense to me, it's going to be 7, right? I've tried it in sev'l compilers.--Billymac00 (talk) 18:31, 29 March 2010 (UTC)
- The numbers have been randomly shuffled using the
random_shuffle
algorithm. The position of the largest number depends upon the underlying implementation of that algorithm, and therand
function used internally. The result is 6 on VC9.decltype
(talk) 18:41, 29 March 2010 (UTC)- yes, obvious now, thanks--Billymac00 (talk) 14:19, 30 March 2010 (UTC)
erasing elements does not deallocate memory _because_(?) initial max size estimates future size
[edit]Erasing elements from a vector or even clearing the vector entirely does not necessarily free any of the memory associated with that element. This is because the maximum size of a vector since its creation is a good estimate of the future size of the vector. -- shouldn't the second sentence begin with "Thus" instead of "This is because"? —Preceding unsigned comment added by 79.160.125.105 (talk) 10:04, 16 May 2011 (UTC)
- I think the point is that if the current number of elements in the vector is n, then there will probably be about n elements in the vector at some time in the future too. So when clearing the vector, it's probably not worth freeing up the memory, because it'll probably be needed again soon. Freeing it up would just then necessitate some expensive reallocation as it grows back to its previous size. Thrapper (talk) 15:07, 25 November 2011 (UTC)
- You can always use vector::resize to manually shrink the vector if you know that the vector will not grow. 1exec1 (talk) 17:22, 29 November 2011 (UTC)
- However, that would be equivalent to calling
erase
, and would not affect memory usage of the vector (capacity
is unchanged).decltype
(talk) 07:21, 2 December 2011 (UTC)- Ah, yes, you correct and I'm totally wrong. Resize never touches the capacity. Having said that, a solution to the problem still exists, even though only in C++11: vector::shrink_to_fit. 1exec1 (talk) 15:42, 2 December 2011 (UTC)
- However, that would be equivalent to calling
Inline links to an external reference?
[edit]After accidentally stumbling on wctype.h, I've got an idea that it would be a good addition to link the names of the member functions to some external reference. I think we could link to this third-party wiki. It uses the same wiki engine and content licensing terms as the Wikipedia, so as a bonus it could serve as a good place to dump any material that fails WP:NOT#MANUAL. What do others think about this?
P.S. I use that website personally, so there's slight conflict of interest :). Anyways, I think this shouldn't be a problem.1exec1 (talk) 20:39, 1 October 2011 (UTC)
Reorganization
[edit]There's an ongoing discussion about an reorganization of the articles about the C++ containers. This page is one of the subjects of that discussion. Please express your opinion. 1exec1 (talk) 20:15, 2 December 2011 (UTC)