December 2nd, 2012, 06:15 PM
Re: Vector iterators
AH HA MOMENT!
Originally Posted by Paul McKenzie
I can see now that when the vector of structs is instantiated, space for the string is not allocated "within" the struct. Just a pointer to the string is the actual member in the struct itself. The string is actually stored elsewhere in memory. So the size of the struct remains constant and the compiler knows exactly how many bytes make up the struct which is always a constant value.
Then all the compiler has to do is:
interator * jumpValue
to get to the next struct.
You're the man Paul. Thanks for helping me understand it! (Hope that's right anyway )
This technique can actually be used in programs I write in the future.
Last edited by raptor88; December 2nd, 2012 at 06:17 PM.
December 4th, 2012, 10:01 AM
Re: Vector iterators
in all fairness. the real motivation behind why STL works the way it does and why method 1 is preferred, is because it allows you to change the underlying container without changing the rest of code.
If for some reason you decide tomorrow that you would rather have a list instead of a vector, then the iterator approach will continue to compile and run. This flexibility can be a HUGE benefit. And a benefit that is made manifest among others by the various <algorithms> YOu can build your own library of algoritms and templates that are based of containers, and even containers of your own. if you follow the "stl way of doing things", you get the benefit that all those algoritms and other templates will be interchangable (to a degree ofc, there are limits to how much you can make one container behaviourly identical to another).
breaking down the code into 2 or 3 works ONLY under the assumption that the container has a  operator that takes an index. That's true for vector, but not for other containers.
Using the containers in the way they were intended means you benefit from the flexibility of changing the underlying container if you need to (within reason). It also means you could benefit from improvements in the library and how the compiler handles the STL code (some compilers have specific optimisations for the STL code). Which you may not get from accessing the container via method 2 or 3.
Click Here to Expand Forum to Full Width