hi all, i have a small class, something between std::vector and boost::array. if others find it useful, i could submit it as an extension to the boost.array libray. it basically implements a dynamically sized array, similar to boost::array, but its size can be defined at run-time, rather than compile-time. in contrary to std::vector, which is only required to support random-access iterators (which are implementation-defined), my class guaranties to allocate the data in one consecutive memory area. it can basically be used like boost::array, the only difference is its constructor, which takes either an integer size or a container. boost::array<float, 5> ba; sized_array<float> sa(5); // initialize to size 5 assert(sa.size() == ba.size()); // container size ba.assign(pi); sa.assign(pi); // assignment sized_array<float> sa2(ba); // construct from container the code is available at [1], would be interested to hear, if other people find it useful .. thanks, tim [1] http://tim.klingt.org/git?p=nova-server.git;a=blob;f=source/utilities/sized_... -- tim@klingt.org http://tim.klingt.org Art is either a complaint or do something else John Cage quoting Jasper Johns
On 8 February 2010 19:09, Tim Blechmann <tim@klingt.org> wrote:
[...] in contrary to std::vector, which is only required to support random-access iterators (which are implementation-defined), my class guaranties to allocate the data in one consecutive memory area. [...]
As of C++03, std::vector is contiguous, so I'm not convinced by the utility of this.
[...] in contrary to std::vector, which is only required to support random-access iterators (which are implementation-defined), my class guaranties to allocate the data in one consecutive memory area. [...]
As of C++03, std::vector is contiguous, so I'm not convinced by the utility of this.
interesting ... it seems, my assumption was based on c++98 ... i guess, my class is pretty useless then :) thanks for clearing this up! tim -- tim@klingt.org http://tim.klingt.org It is better to make a piece of music than to perform one, better to perform one than to listen to one, better to listen to one than to misuse it as a means of distraction, entertainment, or acquisition of 'culture'. John Cage
Zitat von Tim Blechmann <tim@klingt.org>:
[...] in contrary to std::vector, which is only required to support random-access iterators (which are implementation-defined), my class guaranties to allocate the data in one consecutive memory area. [...]
As of C++03, std::vector is contiguous, so I'm not convinced by the utility of this.
interesting ... it seems, my assumption was based on c++98
I don't think that was changed from 98 to 03. but your description reminded me of something I do think would be a useful addition to Boost.Array. a vector that resides on the stack as long as it fits in there(like a boost::array) but still supports dynamic allocation in case the vector size exceeds the reserved space. my implementation of this: template<class T,std::size_t EmbeddedSize,bool Expand=true> class embedded_vector; embedded_vector<T,Size,false> should be equivalent to boost::array<T,Size>, but if Expand==true max_size() is unlimited, with no allocation as long as size() <= EmbeddedSize
strasser@uni-bremen.de skrev:
Zitat von Tim Blechmann <tim@klingt.org>:
[...] in contrary to std::vector, which is only required to support random-access iterators (which are implementation-defined), my class guaranties to allocate the data in one consecutive memory area. [...]
As of C++03, std::vector is contiguous, so I'm not convinced by the utility of this.
interesting ... it seems, my assumption was based on c++98
I don't think that was changed from 98 to 03. but your description reminded me of something I do think would be a useful addition to Boost.Array.
a vector that resides on the stack as long as it fits in there(like a boost::array) but still supports dynamic allocation in case the vector size exceeds the reserved space.
my implementation of this:
template<class T,std::size_t EmbeddedSize,bool Expand=true> class embedded_vector;
See also here for a lib in the review queue: http://www.cs.aau.dk/~nesotto/boost/trunk/libs/auto_buffer/doc/html/index.ht... -Thorsten
[...] in contrary to std::vector, which is only required to support random-access iterators (which are implementation-defined), my class guaranties to allocate the data in one consecutive memory area. [...]
As of C++03, std::vector is contiguous, so I'm not convinced by the utility of this.
interesting ... it seems, my assumption was based on c++98
I don't think that was changed from 98 to 03. but your description reminded me of something I do think would be a useful addition to Boost.Array.
i cannot comment on c++03, since i don't have access to the iso specification, but for c++0x it seems to be the case. n2800 tells me the following: 23.2.6.1: The elements of a vector are stored contiguously, meaning that if v is a vector<T, Alloc> where T is some type other than bool, then it obeys the identity &v[n] == &v[0] + n for all 0 <= n < v.size(). in addition to that, 23.2.6.3 defines: pointer data(); const_pointer data() const; these two paragraphs would give me the guaranties, that i need for my application.
a vector that resides on the stack as long as it fits in there(like a boost::array) but still supports dynamic allocation in case the vector size exceeds the reserved space.
my implementation of this:
template<class T,std::size_t EmbeddedSize,bool Expand=true> class embedded_vector;
See also here for a lib in the review queue:
http://www.cs.aau.dk/~nesotto/boost/trunk/libs/auto_buffer/doc/html/index.ht...
interesting ... for EmbeddedSize==0 or StackBufferPolicy==boost::store_n_objects<0> both implementations would match the guaranties of my class ... cheers, tim -- tim@klingt.org http://tim.klingt.org Silence is only frightening to people who are compulsively verbalizing. William S. Burroughs
Am 09.02.2010 11:09, schrieb strasser@uni-bremen.de:
Zitat von Tim Blechmann <tim@klingt.org>:
[...] in contrary to std::vector, which is only required to support random-access iterators (which are implementation-defined), my class guaranties to allocate the data in one consecutive memory area. [...]
As of C++03, std::vector is contiguous, so I'm not convinced by the utility of this.
interesting ... it seems, my assumption was based on c++98
I don't think that was changed from 98 to 03. but your description reminded me of something I do think would be a useful addition to Boost.Array.
a vector that resides on the stack as long as it fits in there(like a boost::array) but still supports dynamic allocation in case the vector size exceeds the reserved space.
my implementation of this:
template<class T,std::size_t EmbeddedSize,bool Expand=true> class embedded_vector;
embedded_vector<T,Size,false> should be equivalent to boost::array<T,Size>, but if Expand==true max_size() is unlimited, with no allocation as long as size() <= EmbeddedSize
I think the problem of std::vector is that it can be moved if objects are assigned (more than the buffer allows)
Zitat von Hansjoerg <hansipet@web.de>:
I think the problem of std::vector is that it can be moved if objects are assigned (more than the buffer allows)
why is that a problem? the vector is moved from stack to heap when that happens.
See also here for a lib in the review queue:
http://www.cs.aau.dk/~nesotto/boost/trunk/libs/auto_buffer/doc/html/index.ht...
thanks. which reminds me, it's the middle of february and there has not been a single review this year, even though the queue is longer than ever and there are multiple libraries with review managers. why is that?
See also here for a lib in the review queue:
http://www.cs.aau.dk/~nesotto/boost/trunk/libs/auto_buffer/doc/html/index.ht...
thanks. which reminds me, it's the middle of february and there has not been a single review this year, even though the queue is longer than ever and there are multiple libraries with review managers. why is that?
last year, there were 6 reviews, the current review queue contains 24 libraries, and some libraries (e.g. boost.atomic) haven't even been added to the queue, yet ... so enough work for the next 4 years if a library like boost.atomic is reviewed in 4 years, it could be obsolete, since hopefully most compilers will provide c++0x atomics by that time :( otherwise, maybe unofficial/unsupported boost packages with libraries from the review queue could be provided? tim -- tim@klingt.org http://tim.klingt.org Linux is like a wigwam: no windows, no gates, apache inside, stable.
On Tuesday 09 February 2010, strasser@uni-bremen.de wrote:
Zitat von Tim Blechmann <tim@klingt.org>:
[...] in contrary to std::vector, which is only required to support random-access iterators (which are implementation-defined), my class guaranties to allocate the data in one consecutive memory area. [...]
As of C++03, std::vector is contiguous, so I'm not convinced by the utility of this.
interesting ... it seems, my assumption was based on c++98
I don't think that was changed from 98 to 03. but your description reminded me of something I do think would be a useful addition to Boost.Array.
According to the following link, the contiguousness of std::vector was made explicit in c++03: http://herbsutter.wordpress.com/2008/04/07/cringe-not-vectors-are-guaranteed...
strasser@uni-bremen.de wrote:
a vector that resides on the stack as long as it fits in there(like a boost::array) but still supports dynamic allocation in case the vector size exceeds the reserved space.
That's the point of auto_buffer (listed at http://www.boost.org/community/review_schedule.html, but not yet scheduled for review because I've been slow to get things rolling). _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
participants (7)
-
Frank Mori Hess -
Hansjoerg -
Scott McMurray -
Stewart, Robert -
strasser＠uni-bremen.de -
Thorsten Ottosen -
Tim Blechmann