Quote:Original post by maspeir

Yes, I know. My point was that Microsoft hides the code to any and all internal C/C++ ANSI and other standards in DLLs and LIBs. This means I would need to understand x86 assembly (which I don't) to see how these are implemented internally. Compilers used to provide the code along with the libraries.

STL is completely templated, which means every compiler delivers full source code - it's all headers. Including Microsoft's.

Quote:So it can replace linked lists?

No, it's a different kind of container, sort of the opposite of linked list, what is expensive in linked list is cheap with vector and vice versa.

Whenever you see somebody write a response with that level of vitriol, you know that their words are based more in emotion than reason. There's a certain small kernel of truth to what he's saying, but I think the only thing you need to read from that rant is this:

Quote:C++ leads to really really bad design choices.

No, C++ doesn't lead to bad design choices--your inability to use it well does. The design is governed by the programmer, not the language. Unfortunately, there's a huge number of programmers out there who don't know how to use it well because, frankly, C++ is harder to use well (or rather, easier to use poorly) than C.

C'est la vie.

To the OP: I recommend really diving into the theory behind templates and generic (meta)programming in C++ before ever using anything that requires you to type '<>'. Like Linus is ranting about, it can be very easy to misuse, and many compilers will allow you to do things that you shouldn't be able to do, so it's very very useful to have a good theoretical and functional understanding about what's going on behind the scenes before you even touch it.

Quote:Original post by Antheus

Quote:So it can replace linked lists?

No, it's a different kind of container, sort of the opposite of linked list, what is expensive in linked list is cheap with vector and vice versa.

std::list replaces linked lists, std::vector is a dynamic array: guarantee that elements appear contiguously in memory.

std::vector is the functional equivalent of a C array that gets realloc'd whenever it's full. The default growth policy of std::vector is that whenever it's realloc'd it consumes double the memory (i think that's right...). So if it's 4 elements long and you push_back a 5th element it will realloc to have a new max capacity of 8 elements.

There are many caveats with vector so it's good to really know how it operates, which you can generally learn just by googling "stl vector". For instance, removing the last element is constant time, but removing a middle element requires basically a memcpy of all subsequent elements one slot up. So if ordering is not important std::swap the current element with the last and do a pop_back(). If ordering is important and you're frequently removing interstitial elements, std::vector is obviously not the correct data structure, std::list is likely more appropriate.

The STL provides implementations of a WHOLE LOT of algorithms: queue, map, stack, vector, list to name a few. It is obviously important that you really know your data structure performance characteristics before choosing one.

-me

Quote:Original post by alvaro
vector is just a bad name. They called it that because (3,1,5) is a 3D vector, so they call an arbitrary finite sequence a vector. For it these sequences to be vectors (by the mathematical definition) you should be able to add them, subtract them and scale them.

Vector is a perfectly good name. It's related to vector processing and other computer science-y things, and has nothing to do with 3D vectors... well, I guess they're like 3rd cousins or something.

EDIT: Oh, I see what you mean. Nevermind.

Quote:Original post by Palidine
std::vector is the functional equivalent of a C array that gets realloc'd whenever it's full. The default growth policy of std::vector is that whenever it's realloc'd it consumes double the memory (i think that's right...).

Exact growth characteristics are unspecified so long as push_back() is amortized constant. I've seen implementations with growth ratios anywhere from 1.5 to 3.