Vectors/Array Questions

I would stay with vector.
Initially, I hesitated to use STL container classes, because of weired syntex and performance consideration. But I found out that they are really well optimaized and vector is as fast as array. (vector is high-performance container.) Now, I like them(vector, list...) very much.

Vectors are nearly always prefferable for long-lived data or data which will be different sizes at run-time.

Internally, a vector is essentially an array. The difference being that things like insertion, resize, etc. are all handled for you.


Only for smallish, short-lived, statically-sized data are arrays a real option from a performance standpoint. An example of this might be a small, statically sized array which holds temporary values within a function.


Of course, there's nothing wrong with arrays, but vectors are just so much more convenient and simpler than doing the lifting yourself -- and aside from that, a good implimentation will have some very fast copying and other routines, faster than you could likely write yourself, not to mention integration with the other parts of the Standard C++ library (algorithms, sorting, etc.)

Thanks a lot people :)

The vector in question is a vector of pointers to tiles , aka my map :).So yeah I guess vector was a good choice sice people here support it.

9 times out of 10, you should start with vectors as opposed to normal arrays. If used correctly, you should not notice any performance hit in your production code. Remember to use vector<>::reserve() if possible to cut down on the number of memory allocations.

Always remember to factor in development time into the equation. It will take much less time to develop using the vector class as opposed to normal arrays, at least once you get proficient with it.

Scott
www.slimcalcs.com

Quote:

Of course, there's nothing wrong with arrays, but vectors are just so much more convenient and simpler than doing the lifting yourself -- and aside from that, a good implimentation will have some very fast copying and other routines, faster than you could likely write yourself, not to mention integration with the other parts of the Standard C++ library (algorithms, sorting, etc.)

I wholy agree that you should use std::vector but just to clarify arrays can still be used with all of the SC++L algorithms etc... because they all act on iterators rather then containers and a pointer is a type of iterator.

Thanks a lot for the info people.Especially for reminding me the existence of reserve() :)

As for iterators .. since you guys mentioned it , I never ever used one.Most of the times I just run through an array/vector with the usual :

for( int i = 0 ; i <= size ; i++) { cout << vector.at(i) //or something else :p }

Is that bad programming or something ? :/

Quote:

Original post by Fukushousha As for iterators .. since you guys mentioned it , I never ever used one.Most of the times I just run through an array/vector with the usual : for( int i = 0 ; i <= size ; i++) { cout << vector.at(i) //or something else :p } Is that bad programming or something ? :/

It's not bad per se, but iterators offer a greater level of abstraction. Consider the following:

container_t my_container;// Put some stuff in 'my_container'...for (container_t::iterator it = my_container.begin(); it != my_container.end(); ++it) {    // Do something with 'it'...}

The above code is largely independent of container type (with the caveat that there are a few containers - container adapters actually - that can't be iterated over). Assuming that container_t is a typedef for your chosen container type, you can easily swap out containers without breaking your existing code. For example, say you were using a std::list to facilitate efficient removal of internal nodes, but later decided that due to the infrequency of the removal operation and the importance of locality, std::vector was a better choice. Just change the typedef and you're good to go.

Also, algorithms from the standard library work with iterators rather than indices, generally speaking. For example, by making use of std::copy() and the genericity of the iterator concept, your code excerpt could be written as:

std::copy(v.begin(), v.end(), std::ostream_iterator<T>(std::cout, " "));

There are many other algorithms and iterator types in the SC++L that can 'automate' various operations that you might otherwise write out manually. The resulting code is usually more expressive, more maintainable, and easier to debug than the corresponding hand-written code - a win all around.

Furthermore, 'raw' pointers are themselves a model of the iterator concept (as mentioned by Julian90), and can for the most part be used anywhere you would use a 'proper' iterator. So just because you find yourself stuck with a raw C-style array for some reason doesn't mean you can't make use of SC++L algorithms :)

That said, the boost::array class provides the same functionality as a 'raw' array, but nicely wrapped in a standard-library-friendly interface. In fact, you could even plug a boost::array in for your container_t typedef - not possible with a plain C-style array.

Finally, the iterator concept is powerful and extensible, allowing you to express different types of problems in a consistent, intuitive way. A good example is the boost::tokenizer class, which treats the process of tokenizing a string as an iteration over the contents of the string.

The preceeding is in no way comprehensive, but does at least touch on a few of the advantages of iterators and their use. So in short, iterating over a vector using an index is not bad programming, but getting in the habit of thinking in terms of iterators will make you a better C++ programmer, and will help you get more out of the tools offered by the standard library.