Boost logo

Boost :

From: Boris (boris_at_[hidden])
Date: 2005-10-04 07:17:43

"Ian McCulloch" <ianmcc_at_[hidden]>,
> Boris wrote:
>> "Pavel Vozenilek" <pavel_vozenilek_at_[hidden]>,
>>> 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.


Boost list run by bdawes at, gregod at, cpdaniel at, john at