I want to store vertex coordinate data for a surface mesh. Now what would be the better method for doing the same .. using normal C style malloced arrays or should i use STL vectors . I am wondering ,, the indexing operator [] is actually a function call .. will it not pose an overhead while accessing elements from the array. I am looking an application where i would need to access the array repeatedly in a loop.

Well do you really need the things provided by the vector class?

the scenario goes like this



In case of an exception , the vector case will be handled properly and there will be no leak .. but not in the case of the
double* version ..

I cant use auto_ptr here as the delete call will be different and auto release during exception will not work !!
So whats the solution ??

Vectors obviously give me the solution. But i am not going to use anything else provided by the vector ( like push_back() , at() etc ) Is the compiler optimizes [] to do pointer arithmatic .. then the problem is solved. but does it ?

Another is to write a auto_array<> template so that the destructuor calls delete[] on the data ..

??

I would say if you never have to reallocate it just use a regular array. Thats my policy. But if your access to the array is rare just during load times for example the overhead is very minimal. Another minor note is I think an std::vector class its self has a slightly larger size then an allocated array which is just a 4 byte pointer. Its a few additional bytes that means nothing unless you have many thousands of these arrays. Allocated arrays are marginally more efficent in my opinions. But you should use what ever your more comfortable with.

Theres no reason to use C's malloc though use new and delete if you go that route.

**edit** I see your other post now, I would try your auto_array thing if you extremely worried about performance here.

iMalc is right. Use a vector.

its implementation is optimal (or very near to).
theres no need to produce half-baked things and wasting time.
and your own implementation will not be significantly faster (if its faster at all)

Count one more vote for the vector. In release mode, the function calls all get inlined and turn into simple array accesses, and the pointer value will be cached, too (so there's no overhead for selecting that member from the struct). With a sized array, you pay for no extra elements; so your total extra memory overhead (assuming a typical implementation) is a whopping 8 bytes (for the size count and capacity count). (Plus, if you end up passing the vector around, you'll avoid having to pass the size separately.)

In effect, std::vector *is* std::auto_array_ptr. Just with resizing functionality. (I know, sometimes you'd like to save 4 of those 8 bytes and give up the resizability - or more likely, you'd like to deny the resizability deliberately, to document the constant-ness of the size...) The library isn't perfect, but it honestly is leaps and bounds better than most people could do themselves. Familiar with placement new? No? Well, std::vector has a leg up on you for optimization, then. You might not think of its clever reallocation scheme, either.

BTW, you don't even have to resize() the vector separately; the vector<T>::vector(int) constructor lets you specify the size at initialization time.

real strong voices there for stl::vector

guess the picture is very clear :)

For this particular scenario:

If you want to save 8 bytes on a stack or hate vector: use array.

If you want simple code with 8 bytes stack penalty: use static vector with size constructor.

{
coords = new double[size]
...
delete [] coords;
}

OR

{
vector coords(size);
...
}

where ... is you processing code (same for both).

MaR