Is there a self contained vector-like container?
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi!
Is there in Boost a container that is statically "max sized" and
contains its own storage like a std::array, but manages a size and can
construct and destruct elements. I guess it would look something like:
template
On 03/01/2012 09:13 PM, Frank Birbacher wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi!
Is there in Boost a container that is statically "max sized" and contains its own storage like a std::array, but manages a size and can construct and destruct elements.
Not in Boost, but such a thing was proposed. I believe it's called auto_array or auto_vector
On Mar 1, 2012, at 12:13 PM, Frank Birbacher wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi!
Is there in Boost a container that is statically "max sized" and contains its own storage like a std::array, but manages a size and can construct and destruct elements. I guess it would look something like:
template
struct self_contained_vector { size_t max_size() const { return N; } size_t size() const { return size_; } private: size_t size_; aligned_storage<T> data_[N]; //...implement random access container... };
I've written one of these; I'm thinking about adding it to Boost.Array. I have to write tests and docs, though. -- Marshall Marshall Clow Idio Software mailto:mclow.lists@gmail.com A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). -- Yu Suzuki
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi! Am 01.03.12 22:05, schrieb Marshall Clow:
I've written one of these; I'm thinking about adding it to Boost.Array. I have to write tests and docs, though.
I'd like to see it. Actually I need one of those but with some special property: the size type shall be changable to e.g. unsigned char. My use case is a 7 element char array that has sizeof 8 or maybe 15 elements sizeof 16, something like that. I'm trying to optimize a data structure for size. I could help with documentation and test creation. I'd also adjust it to make the size type switchable. Otherwise I'd implement this thing myself and propose it. Frank -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: keyserver x-hkp://pool.sks-keyservers.net iEYEARECAAYFAk9P5wYACgkQhAOUmAZhnmpsyQCfXJ0VQ8F5xw5AOiEbbZs8loIa QYEAn222LQSfnDu5XkgiUosDH2fqmGK3 =avs1 -----END PGP SIGNATURE-----
On 1 March 2012 15:15, Frank Birbacher
I'd like to see it. Actually I need one of those but with some special property: the size type shall be changable to e.g. unsigned char.
In the interface or the implementation? If it is in the interface, I'd rather it match the other containers and be a size_t. In the implementation, well, that's just a detail that should be weighed against other concerns (what is the efficiency (both space and typical access) tradeoff between storing the size vs. storing a pointer to end vs. conversion of a "smaller" size to size_t). Your use case (char array) is fairly easy to whip up with just an array and a size. Alignment, exception safety or move semantics is what makes this container non-trivial to write. -- Nevin ":-)" Liber mailto:nevin@eviloverlord.com (847) 691-1404
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi! Am 01.03.12 23:07, schrieb Nevin Liber:
In the interface or the implementation?
Implementation.
Your use case (char array) is fairly easy to whip up with just an array and a size.
You have a point here. I don't need the fully fledged container semantics for my use case. Maybe I should just static_assert its value_type to be POD and implement it with an array.
Alignment, exception safety or move semantics is what makes this container non-trivial to write.
Right, and in such places the size of the size member is usually irrelevant. Anyway it would not hurt to statically select the size member type by the max size template parameter in order to cover a use case like mine. Frank -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: keyserver x-hkp://pool.sks-keyservers.net iEYEARECAAYFAk9P/nYACgkQhAOUmAZhnmqBEACdHFV8liBNLt0GdQIKdGDuIx/f Jp8AnjF9LnNv2TDnJN3rT8Pk3gTZH7j7 =CxXM -----END PGP SIGNATURE-----
On 1 March 2012 16:55, Frank Birbacher
Right, and in such places the size of the size member is usually irrelevant. Anyway it would not hurt to statically select the size member type by the max size template parameter in order to cover a use case like mine.
Note: I'm not against it in the implementation (I've done this kind of thing myself); only in the interface. My only concern is the performance cost for typical uses. The feature I suggested to Marshall that I would like to see is a way to default initialize elements (normally unspecified elements should be value initialized so as to match the other containers) for construction, resize, push_back, emplace_back, insert, etc. -- Nevin ":-)" Liber mailto:nevin@eviloverlord.com (847) 691-1404
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi! Am 02.03.12 00:32, schrieb Nevin Liber:
Note: I'm not against it in the implementation (I've done this kind of thing myself); only in the interface.
Agreed. :)
The feature I suggested to Marshall that I would like to see is a way to default initialize elements (normally unspecified elements should be value initialized so as to match the other containers)
Good thing, it should behave like other containers. No surprise for users, please. So what is Marshall to say about this? :) Frank -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: keyserver x-hkp://pool.sks-keyservers.net iEYEARECAAYFAk9QDJ8ACgkQhAOUmAZhnmp1nQCeL9k26uzdSJjWzr7N22QG4mMf 6nEAn1RKI9jMqBYfFDikgQHyIg0yvQbS =8kuW -----END PGP SIGNATURE-----
participants (4)
-
Frank Birbacher -
Marshall Clow -
Mathias Gaunard -
Nevin Liber