>>if you can have it in memory, then you can have it in a vector.

No it doesn't. If he is still using 32-bit compiler than the size of the long int is not changed from what it is on a 32-bit operating system, and the STL libraries will still be 32-bit libraries. He will need to use a 64-bit compiler to make any use of the 64-bit os.

Well the poster says he is using a 64bit linux,
so I found it safe to assume he is using a 64bit toolchain.

But your argument is valid. But for sake of completeness, the same can be said about a 16 bit compiler

If I use a 64-bit compiler than a [icode]long int[\icode] is always 8 bytes? Then this basically solves my problem. I didn't know this was always true. Sometimes I see 4 bytes long ints, then maybe they have been compiled with a 32-bits compiler.

So I will just use long ints for my indices, and this will make it possible to address all the memory I have. I will also use multiple vectors for speed. It takes a long time to resize the vectors once they are big.

Thanks for all you replies.

One more question: If v is vector, what is the type of v.size()? Is it an long int?

Thanks.

It's so simple (no need in DaniWeb), ask your compiler:

If you are using that much memory, you will be much better off using the boost array/multi_array classes. Then you will be better off using Blitz.

Word of warning: write the code using boost/stl untill it works with smaller data sets. THEN use Blitz. Otherwize the error messages and other problems are incomprehensible.