if i have a an array/vector of which i know the size of at compile time, it's less overhead if it's an array, but if i do not know the size at compile time(and dont want to estimate) and its size might keep changing, its better(easier) if its a vector and there's no difference in overhead between them in that case. please correct me if i am wrong about this assuming those statements were correct, what about when it comes to a class which memembers are created dynamically during runtime, in that case the memory is taken from the heap anyway, so would there be a difference in speed if i used an array or vector in that case? Thanks!

In an optimized version of your program, accessing elements in a vector is equivilent to using a pointer (i.e., a dynamically allocated array).

If you're really hardcore, you can make a 0 element array, stick it at the end of your object, and then dynamically allocate the right number of bytes so that the elements of the array actually exist. This is pretty common in C and saves one level of dereferencing, but it's more troublesome in C++ since you can't use new/delete directly, and you have to call constructors/destructors for the objects you're tacking on to the end of the main object. Actually, forget I said anything. It's more trouble than it's worth. A vector is more than adequate and a bizillion times easier to not screw up.

Quote:Original post by Oggan
if i have a an array/vector of which i know the size of at compile time, it's less overhead if it's an array, but if i do not know the size at compile time(and dont want to estimate) and its size might keep changing, its better(easier) if its a vector and there's no difference in overhead between them in that case.
please correct me if i am wrong about this

You are correct. std::vector just wraps the code you would use if you were directly manipulating a pointer to some dynamically-allocated memory into a neat and convenient package.

Quote:assuming those statements were correct, what about when it comes to a class which memembers are created dynamically during runtime, in that case the memory is taken from the heap anyway, so would there be a difference in speed if i used an array or vector in that case?

Dynamically allocating the object doesn't fundamentally alter the problem.

Quote:This is pretty common in C and saves one level of dereferencing, but it's more troublesome in C++ since you can't use new/delete directly, and you have to call constructors/destructors for the objects you're tacking on to the end of the main object.

You shouldn't do that in C++: the internal layout of non-POD types is implementation-defined. You don't know for a fact that your zero-sized array would actually end up at the end of the object. In fact, if multiple inheritance is involved, it most definitely will not (since the base subobject that contains the array may be followed by another subobject).

Quote:
You are correct. std::vector just wraps the code you would use if you were directly manipulating a pointer to some dynamically-allocated memory into a neat and convenient package.

thanks for that :)

Quote:
Dynamically allocating the object doesn't fundamentally alter the problem.

sorry if im dumb but i don't get it =/

when "Dynamically allocating the object", would a vector be slower than a static array?

"Yes," because you're creating the objects during run time on the heap, where as the array would be on the stack... (I believe so..)

Quote:Original post by Oggan
when "Dynamically allocating the object", would a vector be slower than a static array?

Allocating a static array is a simple pointer adjustment (on the stack) or size adjustment (if part of another object). On the other hand, a vector holds a chunk of dynamically allocated memory, unless you are using a custom allocator (the second template parameter of the vector class) which happens not to. Whether the vector itself is created on the stack or as part of another dynamically-allocated object is irrelevant. So yes, creating a vector is slower than creating a static array, although in a number of cases, initializing the elements would swamp the cost of initialization.

Of course, creating classes which contain large array members causes problems too, as you aren't guaranteed to have sufficient contiguous memory to hold it all. And overflowing your stack with one gignormous array intended to hold the game's map is a common beginner error. Vectors help by dissociating the array from the class (though that can be a problem too in some cases), and deques go even further by slicing up the array itself in smaller chunks. Tradeoffs, tradeoffs, tradeoffs.

Quote:Original post by dbzprogrammer
"Yes," because you're creating the objects during run time on the heap, where as the array would be on the stack... (I believe so..)

but if the static array is in a dynamically created object(allocated from the heap since its created dynamically), doesnt that mean the "static" array is allocated from the heap as well, which means it would be just as "slow" as if it was a vector?

Quote:Original post by Fruny

Quote:Original post by Oggan
when "Dynamically allocating the object", would a vector be slower than a static array?

Allocating a static array is a simple pointer adjustment (on the stack) or size adjustment (if part of another object). On the other hand, a vector holds a chunk of dynamically allocated memory, unless you are using a custom allocator (the second template parameter of the vector class) which happens not to. Whether the vector itself is created on the stack or as part of another dynamically-allocated object is irrelevant. So yes, creating a vector is slower than creating a static array, although in a number of cases, initializing the elements would swamp the cost of initialization.

Of course, creating classes which contain large array members causes problems too, as you aren't guaranteed to have sufficient contiguous memory to hold it all. And overflowing your stack with one gignormous array intended to hold the game's map is a common beginner error. Vectors help by dissociating the array from the class (though that can be a problem too in some cases), and deques go even further by slicing up the array itself in smaller chunks. Tradeoffs, tradeoffs, tradeoffs.

okay, thanks =)
i guess that answers my question then