"Pavel Vozenilek" <pavel_vozenilek@hotmail.com>, news:dhschl$h6q$1@sea.gmane.org...

"Boris" wrote:

...

...

We have boost::array but just like with std::bitset you need to know the size at compile time. Is there any interest in boost::dynamic_array (I mean is anyone else interested except me :-)?

Before anyone wonders: I'm talking about a fixed-size array whose size is set at runtime. boost::dynamic_array is probably not a suitable name as someone might think then of std::vector.

How would such dynamic_array be better (different) than std::vector?

I wouldn't say it's better. It would be just a bit more suitable in a situation where you know that you will deal with a fixed number of elements at runtime. The interface would be probably similar to std::vector but without inserting/removing operations. While std::vector is the natural choice when you need a dynamic array and boost::array when you know the (fixed) size at compile time this new array type (whatever the name would be) would be chosen when you know the (fixed) size only at runtime. Boris

Ian McCulloch wrote:

Boris wrote:

...

"Pavel Vozenilek" <pavel_vozenilek@hotmail.com>,

...

How would such dynamic_array be better (different) than std::vector?

I wouldn't say it's better. It would be just a bit more suitable in a situation where you know that you will deal with a fixed number of elements at runtime. The interface would be probably similar to std::vector but without inserting/removing operations. While std::vector is the natural choice when you need a dynamic array and boost::array when you know the (fixed) size at compile time this new array type (whatever the name would be) would be chosen when you know the (fixed) size only at runtime.

You still have not stated what advantages such a container would have over a resizable container. In other words, if you omit the resize() et. al. from std::vector, what extra functionality can be gained in return?

I'm assuming there's some room for optimisation (most std::vector's allocate head-room, for example, which may be bad if, say, you're allocating a vector to hold every prime below 5,000,000, after you use Erasmus' Sieve to find them). Probably not too much need, though.

On Tue, 2005-10-04 at 09:23 +0200, Matthias Troyer wrote:

On Oct 4, 2005, at 1:37 AM, Ian McCulloch wrote:

...

You still have not stated what advantages such a container would have over a resizable container. In other words, if you omit the resize() et. al. from std::vector, what extra functionality can be gained in return?

I see advantages in a variant of this idea, with a compile-time fixed capacity, an implementation of which was done a few years ago by Synge Todo and posted here. There the advantage is that pointer dereferencing can be avoided, and memory usage is minimized.

Another advantage is that you can store iterator to the array in other structures without having a resize in parallel that invalidates all the stored iterators. These are difficult to find bugs... Not that it is impossible to use the current vector by getting the size right at construction time, but the rule "never use resize" is difficult to enforce. Also bound checking might cost less as no operation is susceptible to change the size of the container (and thus an intelligent compiler might remove many checks). And for multidimensionnal arrays, having bounds defined at compile time can help optimization of array access (by generating optimal computation of the array index).

"Ian McCulloch" <ianmcc@physik.rwth-aachen.de>, news:dhsff0$nb9$1@sea.gmane.org...

Boris wrote:

...

"Pavel Vozenilek" <pavel_vozenilek@hotmail.com>,

...

...

How would such dynamic_array be better (different) than std::vector?

I wouldn't say it's better. It would be just a bit more suitable in a situation where you know that you will deal with a fixed number of elements at runtime. The interface would be probably similar to std::vector but without inserting/removing operations. While std::vector is the natural choice when you need a dynamic array and boost::array when you know the (fixed) size at compile time this new array type (whatever the name would be) would be chosen when you know the (fixed) size only at runtime.

You still have not stated what advantages such a container would have over a resizable container. In other words, if you omit the resize() et. al. from std::vector, what extra functionality can be gained in return?

The reason why I don't want to use std::vector in the project I work on is that I need a two-dimensional array. Two-dimensional means that the array stores not only the length but also width and height. Additionally its elements can be accessed with operator()(size_t column, size_t row). Now I could derive my two-dimensional array from std::vector but that doesn't make much sense because how should the dimensions change when someone calls push_back()? A fixed-size array whose size can be set a runtime would be an ideal candidate to derive my two-dimensional array from. For all arrays with more than one dimension std::vector isn't probably an ideal parent class. Boris