boost::dynamic_array
I stumbled about boost::dynamic_bitset in the documentation which is a runtime sized version of std::bitset. Now I wonder why there is no boost::dynamic_array. 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 :-)? Boris
"Boris" <boris@gtemail.net>, news:dhrrne$ues$1@sea.gmane.org...
I stumbled about boost::dynamic_bitset in the documentation which is a runtime sized version of std::bitset. Now I wonder why there is no boost::dynamic_array. 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. Boris
"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? /Pavel
"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
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? Ian McCulloch
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 Oct 4, 2005, at 1:37 AM, 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 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. Discussions of this library stopped on the Boost list, after some members wanted a full-fledged policy-based vector instead, which was then never developed. For those who need it, the library is now published under the Boost license as a part of the ALPS libraries (http://alps.comp-phys.org/). It would be worth reconsidering this project, and maybe extending it. Matthias
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).
| -----Original Message----- | From: boost-bounces@lists.boost.org | [mailto:boost-bounces@lists.boost.org] On Behalf Of Matthias Troyer | Sent: 04 October 2005 08:23 | To: boost@lists.boost.org | Subject: Re: [boost] boost::dynamic_array | | 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. | | Discussions of this library stopped on the Boost list, after some | members wanted a full-fledged policy-based vector instead, which was | then never developed. For those who need it, the library is now | published under the Boost license as a part of the ALPS libraries | (http://alps.comp-phys.org/). | | It would be worth reconsidering this project, and maybe extending it. Agreed. Paul Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539 561830 +44 7714 330204 mailto: pbristow@hetp.u-net.com www.hetp.u-net.com
"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
participants (1)
-
Boris -
Ian McCulloch -
Matthias Troyer -
Paul A Bristow -
Pavel Vozenilek -
Simon Buchan -
Theodore Papadopoulo