Whose ideas was it to call std::vector a vector!
 

Thanks to the STL, I can't include the name "vector" in my variables without someone being confused about whether I mean a mathematical vector or an STL vector container.

Now, I would be content to have small difficulties in life come about due to the complexities of life but this is not such a case! Whoever came up with these STL names had no clue what a "vector" is but thought the name was cool and used it... Without realizing that, perhaps, a lot of people would like to code vectors using C++.

So, who came up with this container name? Has anyone else experienced the same frustration over this or a similar situation?

At least those variables aren't being confused for rats..

Redlemon's definition was the 1st thing I thought of when I saw the header: "std vector".

I've never really found a good explanation for why they re-used a perfectly good term for things with a magnitude and a direction to mean "a dynamic array," so I'll agree with you there.

However, couldn't you use namespaces, such as use mynamespace; instead of STL so that Vector is recognized as YOUR vector, rather than the STL vector? The entire purpose of a namespace is to prevent this type of naming conflict, isn't it?

EDIT: Added an example:
http://www.cplusplus.com/doc/tutorial/namespaces.html

Why dont you just extend the vector class to add magnitude, dot, and cross methods?
I do agree with you 100% on the vector being a poor choice. I recently coded a matrix class with gaussian reduction, but I didnt run into this. I wish the math class in every language went beyond highschool level mathematics.


Still, I think java used an arrayList, so java is better in this instance. However, I now end up doing everything in XML, XSD, XSLT, and SVG. I create file or strings, and an engine does all the processing. Not really fun, but there are a lot of options for creative solutions....so its not so bad.

It makes sense to me; it's a collection of values, and I doubt the term's use in computer science started with STL. Not exactly the same as a mathematical vector since the same operations aren't defined, but you could easily define them to make it more like one (which can also have any number of values n-dimensional). Don't blame the creators of STL for your own confusion (seems to be a common thing with C++ in general, and like L.A., I find it my duty to defend it); I'm sure there are plenty of mathematicians getting along fine with it. =P

You misunderstand my complaint. I'm not afraid of a name conflict, I'm afraid of confusing the readers of my code with ambiguous variable names. So, for instance:
Someone reading this might mistake the various vectors in this function to be STL vectors and there's nothing about namespace or C++ that can fix this! Now, while this is a rather contrived example, I hope you can see that this can seriously limit how you'd like to name your mathematical routines, especially if you're trying to write clean and self-documenting code!

...and for what? In what manner is std::vector a vector? It's a rather non-descriptive name.

Not to mention that I have a few other complaints about the STL naming conventions--along those same lines!

Please allow me to be a mathematical snob for a moment and point out that neither of you (nor JinnKai) understand what a mathematical vector is, which is why I included a link with my original post (and here too, so you don't miss it). You all think like physicists...

A vector is merely an element of a set that follows the vector axioms. So, for instance, the most popular vector space, aside from the Cartesian vectors everyone has already mentioned, is the set of continuous functions. Interestingly enough, the set of sinusoidal waves of integral frequencies forms a basis for this set! This is the basis of fourier analysis and is very important for signal processing, for which there is plenty of software written!

Can continuous functions be represented as n-tuples of values? Not really... Let's face it, std::vector has nothing to do with vectors!
Why not call it exactly what it is: an array. What would have been wrong with std::array?

I very well understand that a vector is an element of a vector space, thanks, but it still seems obvious where the name came from. Sure, they could have used array, but either way I don't think the name of that class should cause substantial confusion as in general you shouldn't need to put a variable's type in its name to make your code understandable..at best that's just a longer version of hungarian notation which is hardly universal.

When I learned about the Vector data type, it was described to me as a "carrier class". Having a biology background I thought of a mosquito, as Redlemon explained.

One reason it's not called std::array is becuase they store things two different ways. Arrays use contiguous memory while Vectors don't. This isn't always the case, but following convention, it makes sense for things not to be called an array.

Vectors and arrays are apples to oranges. Sure, they do the same things, but they're implemented in vastly different ways which make them completely seperate concepts.

Umm, someone correct me if I'm wrong but the whole point of a vector is that they do store their elements in contiguous memory, which is why I say that it is an array. What makes you think otherwise?

Vectors don't store their elements in contiguous memory - it wouldn't be possible for them to be dynamically resized if that was the case.

For instance, if you allocate two vectors of length 10 at the start of your program, chances are they'll be stuck next to each other in memory. Later on, you decide you want to add another 100 elements to the first vector. That space isn't available next to the vector, so what's it do? It tries to find space elsewhere in memory and then sets up a pointer for the behind-the-scenes vector math so that when the iterator goes from 10 to 11, it knows to jump to the new segment of memory.

Nope, Vectors don't store their elements in contiguous memory. Each element of a Vector is a reference to an object somewhere else in memory. Depending on the language being used, the Vector's reference list may or may not be stored in contiguous memory. However, this doesn't change the function of the Vector data type. Additionally, the footprint for a reference ("pointer" for c++ people) is very small, so this quirk is considered a trait of the language itself rather than the Vector.

Compare declaring a Vector which will hold 20 elements versus declaring an array of the same size. Assuming an integer is 4 bytes and a reference/pointer/memory address is 2 bytes.

Note: Fictional scenario

int[] array = new int[20]; sets aside 4*20 blocks of contiguous memory.
Vector vector = new Vector(20); sets aside 2*20 blocks in contiguous memory (depending on the implementation/language). To fill up the vector an additional 80 bytes are required somewhere else in memory. The original 40 bytes point to the various places each int is placed.

I thought the STL vector was just an interface and each STL implementation of vector could theoretically be different. What I'm getting at is I don't see any reason why the elements of a vector couldn't be stored in contiguous memory, though actual implementations would find better ways. That wouldn't stop it from being resized because it could simply allocate a larger block of contiguous memory and copy the existing elements over to it. So are you talking about a spec or definition somewhere that says this or the de facto way of implementing it?

It's not just the interface, there are qualities that the interface must honour in order to be defacto STL containers. For instance, the [] operator for std::vector must execute in constant time, O(k). This can't be done with, say, a linked list implementation...

Having said that, after a modicum of research (asking someone who knows), I have discovered that std::vector need not be implemented using contiguous memory. This may not be true in the future since the STL container that does implement contiguous memory, std::valarray, is in the process of being deprecated in favour of std::vector, since almost all implementations of it do exactly that (use contiguous memory).

In answer to Pragma's reasoning, it is false. There's nothing about contiguous memory that makes it impossible to dynamically resize the container. Yes, it might require a lot of copies but there are no constraints to the execution time of insertion for std::vector, so that's okay (in terms of conformance).

This is beside the point. Because std::vector need not be implemented as contiguous memory, that might explain why "array" wasn't used as a name. However, I still feel that "vector" was a poor name in that it's not a vector in any sense of the word. At least the std::vector interface shares almost all of the qualities of an array. So much so that I say it is still a much better name than "vector"...

What I was going at - but failed to mention - is what happens if you have an array that's larger than your largest block of contiguous memory? Using a vector, it's possible to store that, having it broken into chunks scattered wherever there's space, as opposed to simply going "Hrm, we need to add elements, okay, let's go find a new chunk of free memory that's current+50 bytes."

That's what happens when I don't completely explain myself :)

Except that's exactly what most implementations of vector do, including the one shipped by Microsoft. When you resize a std::vector it will typically reallocate a new array and copy what it needs to onto it. If no such block exists, such as if you have a lot of fragmented allocations (surprisngly hard to do), then std::vector will simply throw an out-of-memory exception, just as if you had tried to allocate that block using a call to new(), since that's probably exactly what it did!

Well, you learn something new every day :D