Hi, I would like to know exactly when is it a good practice to use std::tr1::array? Any advice or suggestions? If I am not wrong, I think std::tr1::array is non growable. But wouldn't it be also similar if I am to do std::vector but by resizing to the expected size at the start? e.g //an array size of 10 using std::vector std::vector<int> arr1(10); vs std::tr1::array<int, 10> arr2; am I allow to do pointer arithmetic on std::tr1::array<> elements? I do assume that the internal storage of array is a contingous memory chunk like vector? since std::tr1::array::begin() returns a random access iterator regards

Quote:If I am not wrong, I think std::tr1::array is non growable.

Correct.

Quote:But wouldn't it be also similar if I am to do std::vector but by resizing to the expected size at the start? e.g

//an array size of 10 using std::vector
std::vector<int> arr1(10);

Yes, it's similar. The main difference is where the memory comes from. With vector the memory comes from the specified allocator (most likely the free store, assuming the default allocator), while with array the data lives wherever the array object lives.

Reasons to use vector even if you know the array size will not need to change might include:

1. The size of the array is not known at compile time.
2. The array has automatic storage duration and is too large for the stack.

Quote:am I allow to do pointer arithmetic on std::tr1::array<> elements? I do assume that the internal storage of array is a contingous memory chunk like vector? since std::tr1::array::begin() returns a random access iterator

Yes, the semantics of array element access are pretty much the same as those of std::vector. (Generally speaking, at least - if you have something in particular in mind, perhaps you could post an example.)

Thanks for the quick replies. Nope i don't have any particular example in mind. Just reading through the C++ pages and msdn libraries.

Why would I then use std::Tr1::array<> over the normal arrays

int arr1[10];

other than the nice members functions that come with std::tr1::array, like swap etc. Wouldn't the normal c-style array works. I can't really think of any examples on hand, I have not used fixed size arrays for a long time. =)

regards

Quote:Why would I then use std::Tr1::array<> over the normal arrays

Here are a few reasons:

1. array is a 'proper' object, which means you can easily make copies of it, pass it around to functions, etc. (The semantics of built-in arrays in C++, on the other hand, are kind of odd, and can be both counterintuitive and inconvenient.)

2. Range checking. You get guaranteed range checking with at(), which can be useful when performance is not critical. You might also get range checking with operator[], depending on the implementation and compiler flags. (Not sure what the standard has to say about this though.)

3. Consistent interface. Functions such as begin() and end() are convenient, can streamline code that would otherwise be awkward, and can help to facilitate compile-time polymorphism.

4. Built-in arrays don't (necessarily) know their own size, but array does. This means, for example, that you can pass it to a function without also having to pass a 'number of elements' argument (a common occurrence when working with built-in arrays).

Given that array is unlikely to perform any worse than a 'raw' array, I think a more reasonable question to ask is, what would be the reasons for using a raw array rather than boost/tr1::array?

Thanks for the replies it does help me clear things up :)

I have seldom used std::tr1::array which was why I made this thread, (not that I use the raw array much too), I often find myself using other libs like maps, vectors, unorder_map/set

Thanks jyk =)

Examples where you would want to use array are when you need or want functionality that []-arrays don't support or only support via a hack or in a ugly way, but you don't want to pay the overhead of std::vector (which most of the time is not terrible, but nevertheless present).

For example, it is a breeze to use std::tr1::array together with variadic templates for writing a function that takes an arbitrary number of handles and does a WaitForMultipleObjects on them all, and the generated code is as good as it could possibly get.