Re: [boost] [circular_buffer] default constructor usually throws std::bad_alloc
OK, will see what can I do with the 1.35.1. release. Btw on the 4th line I don't see a problem to explicitly set the capacity like this: circular_buffer<char> buffer(0); // nothing will be allocated ----- Original Message ---- From: Dean Michael Berris <mikhailberis@gmail.com> To: boost@lists.boost.org Sent: Thursday, 15 May, 2008 2:04:58 PM Subject: Re: [boost] [circular_buffer] default constructor usually throws std::bad_alloc On Thu, May 15, 2008 at 7:48 PM, Jan Gaspar <jano_gaspar@yahoo.com> wrote:
This was an intended behaviour (to allocate the maximum capacity). The reason behind this was to comply with other STL containers. I admin the decision was not the best one. I will change this as you propose but in the Boost version 1.36. For now just use the constructor with the explicit capacity paramater or override the allocator's max_size() to return some sensible value.
Actually, this is going to be really hard to do especially if you are expecting the buffer from another source and just need a default constructed "receiver" to get it: map<string, circular_buffer<char> > input_buffers; input_buffers.insert(std::make_pair("cin", circular_buffer<char>(1000))); input_buffers.insert(std::make_pair("net", circular_buffer<char>(2048))); circular_buffer<char> buffer; // this will throw string source; cin >> source; if (input_buffers.find(source) != input_buffers.end()) { buffer = input_buffers.find(source)->second; }; With the current implementation, you may not be able to get past the default constructed buffer, and if you did set some capacity, you'd be wasting memory. Shouldn't the change make it to Boost 1.35.1? :-D It's a really trivial fix for the constructor, but I haven't looked at how it will affect the other areas of the code. Thanks for the quick response! :) -- Dean Michael C. Berris Software Engineer, Friendster, Inc. [http://blog.cplusplus-soup.com] [mikhailberis@gmail.com] [+63 928 7291459] [+1 408 4049523] _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost __________________________________________________________ Sent from Yahoo! Mail. A Smarter Email http://uk.docs.yahoo.com/nowyoucan.html
On Thu, May 15, 2008 at 9:29 PM, Jan Gaspar <jano_gaspar@yahoo.com> wrote:
OK, will see what can I do with the 1.35.1. release.
Great, thanks. :)
Btw on the 4th line I don't see a problem to explicitly set the capacity like this: circular_buffer<char> buffer(0); // nothing will be allocated
True, I understand. Actually, the problem is also a little more subtle than just that. Consider also the case: map<int, circular_buffer<int> > buffers; circular_buffer<int> buffer(buffers[rand() % 10]); In this case doing buffers[rand() % 10] will cause an implicit creation of a default constructed circular_buffer<int>. There are a lot of cases (especially in STL containers) that when circular_buffer<...>'s can be contained, the implicit requirement of default constructability of items be maintained. It is a subtle issue, and is really hard to trace (i.e., it took me a while to figure out why suddenly when I decided to use a circular_buffer<...>, it kept throwing an std::bad_alloc). I think instead of (mis)behaving in the case of the default constructed buffer, there should be some considerably sane default. I personally chose 0, where adding items to the buffer would most probably fail afterwards, which can be expected behavior. It could also be another number, like how the STL vector chooses a default number of elements and grows accordingly -- but in this case of the circular buffer, it may be hard to determine that default. We can make it degenerate to a 1 element circular buffer where there's really only one value ever in the buffer, but I think that is also wasteful. I hope this helps! -- Dean Michael C. Berris Software Engineer, Friendster, Inc. [http://blog.cplusplus-soup.com] [mikhailberis@gmail.com] [+63 928 7291459] [+1 408 4049523]
participants (2)
-
Dean Michael Berris -
Jan Gaspar