"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