Curious question regarding fixed array and std::vector?

No, it won't save you any speed (at least in a release build).

That depends. What do you intend for that code to do? What are you trying to accomplish by that code that you wouldn't accomplish in the first two lines?

EDIT: oh, I see. No, that's not worthwhile. Internally, std::vector looks very much like your dynamic array.

Quote:

Original post by Rasmadrak Would this save me speed in the end? Or simply make it more error-prone?

That won't save you any speed. std::vector is as fast as a naked dynamic array. And yes, it'll make it a whole lot more error prone. Also note that allocating memory is expensive, so creating two arrays will take a lot longer than creating one. Oh, and std::vector::clear does not necessarily delete the memory, just so you know.

[edit]

if (doubleNinja'd == true) ninja'd += 2;

GNU has an extension that goes like this:



which is basically the same es the equally non-standard but yet widely supported alloca:


In the second case, i can be non-const. Both are stack allocations, hence you don't have to explicity de-allocate. In the second case, you can use placement new for non-pods.

Depending on some factors, those could yield better performance.

Ok, thank you all for your time and input.
I'll stick to using regular std::vector's and std::list's !

Cheers!

/Robert

Also, please don't call your std::vector objects `list'. The people that have to maintain your code in the future (that could be a future you) will thank you.

Quote:

Original post by MikeTacular [...] That won't save you any speed. std::vector is as fast as a naked dynamic array.

Not true. A vector will perform bounds checking, so...

some_array[9] = 0;

generate quite different assembly between a normal array and a vector.

Quote:

Original post by agottem Quote: Original post by MikeTacular [...] That won't save you any speed. std::vector is as fast as a naked dynamic array. Not true. A vector will perform bounds checking, so... some_array[9] = 0; generate quite different assembly between a normal array and a vector.

The at member function is required to do bounds checking, but operator[] is not. Passing an out of bound index is undefined behavior, and not doing bounds check is perfectly fine for any valid implementation.

Quote:

Original post by agottem Not true. A vector will perform bounds checking, so... some_array[9] = 0;

You use at() if you want bounds checking; if you index out of range you'll get an exception. operator[] has an undefined result if you index out of range. In practice with most compilers this generally means an assert in debug mode and trashing random memory in release mode. Either way the standard does not specify any bounds checking on operator[].

Quote:

Original post by SiCrane Quote: Original post by agottem Not true. A vector will perform bounds checking, so... some_array[9] = 0; You use at() if you want bounds checking; if you index out of range you'll get an exception. operator[] has an undefined result if you index out of range. In practice with most compilers this generally means an assert in debug mode and trashing random memory in release mode. Either way the standard does not specify any bounds checking on operator[].

Well, visual studio -- in a release build -- generates the necessary assembly to perform the bounds checking and throw an exception.

So if it's undefined, the performance of using operator[] is undefined, and should be avoided for any performance critical operations.

By default it does. Andy you can disable it.

Quote:

Original post by agottem So if it's undefined, the performance of using operator[] is undefined, and should be avoided for any performance critical operations.

The performance of anything is pretty much undefined (ok, so time complexity is, but the performance between two O(n) implementations can easily differ by a lot). The C++ standard usually just says you need to comply with these rules, but how you comply with them is up to you. And I totally disagree with you here. If you are doing any performance critical operations, you should have disabled bounds checking. Don't jump to using naked dynamic arrays when you can easily use something that's just as fast and safer. And it had better be a really, really, really performance critical operation.

Quote:

Original post by agottem Well, visual studio -- in a release build -- generates the necessary assembly to perform the bounds checking and throw an exception.

That's because you're running MSVC in stupid mode.

Quote:

Original post by SiCrane Quote: Original post by agottem Well, visual studio -- in a release build -- generates the necessary assembly to perform the bounds checking and throw an exception. That's because you're running MSVC in stupid mode.

To clarify the above, you're running MSVC in "the user is stupid" mode. Which is actually a fairly sane assumption. They're programming in C++ after all ;-).

The unfortunate side effect of this is that they've built better idiots now, meaning they rewrite std::vector (poorly -- sometimes very poorly by not even writing a class and using raw arrays directly).