[C++] Don't use arrays in C++!

[Justin_]

Actually the label was just to emphasize that I need an int instead of an iterator in the [] operator. My actual program implements a vector of objects. Currently I am accessing individual elements in the array by counting the iteratations and supplying the intended integer value.

I hope there is a very efficient way to do it cause so far vectors have just made things more complicated and I haven't seen an advantage to them (cause i kinda like arrays).

[jernst]

nice tutorial making use of it right now for some work

[avok23]

Vectors are performance hogs. i'll rather advise u use lists or make your custom data struct. and this topics should be name "An alternate to arrays/struct/etc.."

case there is nothing wrong with this data types. arrays grant u high performan and if u ever work on a small system u have no choice yuo MUST use them. you can not go about enforcing your coding style like its some gospel you can only enlighten people to its ups and downs. please people keep an open mind and if in doubt use all available alternates.

and ++i is faster than i++.

[md]

avok23 @ 2008-05-05, 6:03 pm wrote:

Vectors are performance hogs. i'll rather advise u use lists or make your custom data struct. and this topics should be name "An alternate to arrays/struct/etc.."

case there is nothing wrong with this data types. arrays grant u high performan and if u ever work on a small system u have no choice yuo MUST use them. you can not go about enforcing your coding style like its some gospel you can only enlighten people to its ups and downs. please people keep an open mind and if in doubt use all available alternates.

and ++i is faster than i++.

Methinks your information is wrong... since vectors and lists are both collections are are based on the same code structures... both are equally fast (or slow as the case may be). Vectors could theoretically be made even faster then lists because they are less generic. Yes you could write your own class and data structures - and you may be able to tailor it to your specific needs slightly better then the STL, but you the STL is still pretty damned fast.

Also, any compiler worth it's salt will generate the same code for ++i and i++ if they are on their own. Heck, even if they don't it works out to basically the same assembly anyways. Perhaps one instruction more.

[StealthArcher]

Seeing his post I decided to run some benchmarks:

On the GCC Compiler:
On Codeblocks (for timing):
Using a for loop, with one instruction, number output, tested to 2000000:
t++ took an average of 103 seconds to complete.
++t took an average of 109.

Either I'm doing something wrong, or your info is indeed incorrect.

[md]

First; Test Code:

c++:

#include <iostream> #include <ctime> const unsigned long TIMES = 100; const unsigned long LOOPS = 2000000000; int main( int argc, char** argv) {         clock_t start, end, dif;         double total, avg;         unsigned long i = 0, j = 0;                 std::cout << "++i, test, 1 to " << LOOPS << "; " << TIMES << " times (++j)" << std::endl;         avg = 0;         total = 0;         while( j < TIMES )         {                 start = clock();                 while( i < LOOPS )                         ++i;                 end = clock();                 ++j;                                 dif = end - start;                 total += dif;         }         std::cout << "Time: " << total << " Avg: " << (total / TIMES) << std::endl;         std::cout << "i = " << i << " j = " << j << std::endl;         i = 0; j = 0;         std::cout << "i++, test, 1 to " << LOOPS << "; " << TIMES << " times (j++)" << std::endl;         avg = 0;         total = 0;         while( j < TIMES )         {                 start = clock();                 while( i < LOOPS )                         i++;                 end = clock();                 j++;                                 dif = end - start;                 total += dif;         }         std::cout << "Time: " << total << " Avg: " << (total / TIMES) << std::endl;         std::cout << "i = " << i << " j = " << j << std::endl; }

Compiling and running:

code:

[john@arkady Projects]$ g++ test.cpp [john@arkady Projects]$ ./a.out ++i, test, 1 to 2000000000; 100 times (++j) Time: 9.74e+06 Avg: 97400 i = 2000000000 j = 100 i++, test, 1 to 2000000000; 100 times (j++) Time: 9.49e+06 Avg: 94900 i = 2000000000 j = 100 [john@arkady Projects]$

Now, with optimization:

code:

[john@arkady Projects]$ g++ -O3 test.cpp [john@arkady Projects]$ ./a.out ++i, test, 1 to 2000000000; 100 times (++j) Time: 0 Avg: 0 i = 2000000000 j = 100 i++, test, 1 to 2000000000; 100 times (j++) Time: 0 Avg: 0 i = 2000000000 j = 100 [john@arkady Projects]$ g++ -O2 test.cpp [john@arkady Projects]$ ./a.out ++i, test, 1 to 2000000000; 100 times (++j) Time: 0 Avg: 0 i = 2000000000 j = 100 i++, test, 1 to 2000000000; 100 times (j++) Time: 0 Avg: 0 i = 2000000000 j = 100 [john@arkady Projects]$

Clearly the compiler can optimize away such a trivial example - and that at least on this computer and with this particular build/version of g++ i++ is faster (trivially so... since iirc CLOCKS_PER_SEC is 1000).

Oh, and g++ version:

code:

[john@arkady Projects]$ g++ -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../configure --prefix=/usr --enable-shared --enable-languages=c,c++,fortran,objc,obj-c++,treelang --enable-threads=posix --mandir=/usr/share/man --enable-__cxa_atexit --disable-multilib --libdir=/usr/lib --libexecdir=/usr/lib --enable-clocale=gnu --disable-libstdcxx-pch --with-tune=generic Thread model: posix gcc version 4.3.0 (GCC)

[btiffin]

Re; ++ and which is faster;

Don't forget. gcc has the ever so teachable -S option. Try it with both post and pre increment. You'll see exactly what the compiler and optimizer are up to at the assembler level. diff -y on the .s files to get a quick grok of deltas. Not many when it comes to integral data types. The issue really comes to rise when objects are involved and with operator++ overloading.

And for some technical details check out http://en.allexperts.com/q/C-1040/Increment-operators.htm

Cheers

[Analysis Mode]

if you have two arrays a1 and a2 and you want to copy from a1 into a2:

memcpy(a2,a1,sizeof a1);

you can do this with other data strucutres likes a deque to vector, etc.

and vectors are slower than arrays (i.e. adjacency lists compared to adjacency matrices).

[DemonWasp]

You can't really compare a Vector with an array. One does a whole lot more than another with regards to bounds-checking (among other things) than the other does. You have to compare the utility of the faster result versus the utility of faster / easier / cheaper maintenance and modification, which is a lot harder than invoking your executable with time in front. In most areas, it should be obvious which one you want.

Pre-increment and post-increment can be compiled out when you have an integer incrementing, but C++ allows you to overload operators, and as I recall, iterators overload ++. However, the way that the function works for myIterator++ involves at least one, possibly dozens, of object-creations and copies, which is a lot slower than ++myIterator, which does nothing of the sort (and unfortunately, the compiler can't really do a whole lot about this).

Mixing C and C++ works out well for performance, but is awful for cross-platform compatability and maintenance. Unless you KNOW you need the performance, use one or the other but not both. Remember: premature optimisation is the root of much (if perhaps not all) evil.

[Briggs]

If you want to use pointers, though, then arrays are the way to go. I'll just put that bit in.

[btiffin]

Just old guy rambling, having encountered a meme

Quote:

"We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil." - Donald Knuth

Followed closely by

Quote:

"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." -Brian Kernighan

and then one of mine

Quote:

"Those that can, do. Those that can't teach, write documentation."

Cheers

[Dark]

hmm I'll try this, ty