- Boost - lists.boost.org

Re: [boost] [circular_buffer] default constructor usually throws std::bad_alloc
by Jan Gaspar 15 May '08

15 May '08

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(a)gmail.com> To: boost(a)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(a)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(a)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

2 1

Re: [boost] [circular_buffer] default constructor usually throws std::bad_alloc
by Jan Gaspar 15 May '08

15 May '08

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. Jan ----- Original Message ---- From: Dean Michael Berris <mikhailberis(a)gmail.com> To: "boost(a)lists.boost.org" <boost(a)lists.boost.org> Sent: Thursday, 15 May, 2008 1:17:27 PM Subject: [boost] [circular_buffer] default constructor usually throws std::bad_alloc I've attached a trivial patch to circular buffer which should allow it to be default constructed (and copy from an existing buffer) without making the default constructor cause an insane request to allocate a huge amount of memory (and fail to throw an std::bad_alloc). I personally think this is a show stopper bug in Boost 1.35.0 and the patch is distributed under the Boost C++ License Version 1.0. Should this be applied to be made part of 1.35.1? -- Dean Michael C. Berris Software Engineer, Friendster, Inc. [http://blog.cplusplus-soup.com] [mikhailberis(a)gmail.com] [+63 928 7291459] [+1 408 4049523] __________________________________________________________ Sent from Yahoo! Mail. A Smarter Email http://uk.docs.yahoo.com/nowyoucan.html

2 1

[circular_buffer] default constructor usually throws std::bad_alloc
by Dean Michael Berris 15 May '08

15 May '08

I've attached a trivial patch to circular buffer which should allow it to be default constructed (and copy from an existing buffer) without making the default constructor cause an insane request to allocate a huge amount of memory (and fail to throw an std::bad_alloc). I personally think this is a show stopper bug in Boost 1.35.0 and the patch is distributed under the Boost C++ License Version 1.0. Should this be applied to be made part of 1.35.1? -- Dean Michael C. Berris Software Engineer, Friendster, Inc. [http://blog.cplusplus-soup.com] [mikhailberis(a)gmail.com] [+63 928 7291459] [+1 408 4049523]

1 0

very poor thread performance
by James Sutherland 15 May '08

15 May '08

I have been testing thread performance on Linux and Mac. My Linux system has two dual-core processors and my Mac has one dual-core processor. Both are intel chips. For the code snippet given below, the execution time should ideally decrease as the number of threads increases. However, the opposite trend is observed. For example, using -O3 flags on my Linux desktop produces the following timings: 1 Thread: 0.66 sec 2 Threads: 0.9 sec 3 Threads: 1.2 sec 4 Threads: 1.4 sec I do not have a lot of experience with threads, and was wondering if this result surprises anyone? James ----- #include <boost/thread.hpp> #include <iostream> #include <vector> #include <time.h> struct MyStruct { explicit MyStruct(const int i) : tag(i) {} void operator()() const { const int n = 100; std::vector<int> nums(n,0); for( int j=0; j<1000000; ++j ) for( int i=0; i<n; ++i ) nums[i] = i+tag; } private: int tag; }; int main() { using namespace std; const int nTasks = 12; const int nThreads = 4; assert( nTasks%nThreads == 0 ); assert( nThreads<=nTasks ); cout << "Executing " << nTasks << " using " << nThreads << " threads." << endl; time_t t1 = clock(); for( int itask=0; itask<nTasks; ++itask ){ boost::thread_group threads; for( int i=0; i<nThreads; ++i ){ threads.create_thread( MyStruct(itask++ + 100) ); } threads.join_all(); } t2 = clock(); cout << "time: " << difftime( t2,t1)/CLOCKS_PER_SEC << endl; } ----

8 17

a new release of Join library. Could a review be arranged?
by Yigong Liu 15 May '08

15 May '08

Hi there, I just uploaded a new version of Join library into Vault under "Concurrent Programming". Could a review be arranged? A brief description: "Join is an asynchronous, message based C++ concurrency library based on join calculus. It is applicable both to multi-threaded applications and to the orchestration of asynchronous, event-based applications. It follows Comega's design and implementation and builds with Boost facilities. It provides a high level concurrency API with asynchronous methods, synchronous methods, and chords which are "join-patterns" defining the synchronization, asynchrony, and concurrency." This update includes code cleanup and exploring using Join for dynamic flow based programming. project website: http://channel.sourceforge.net doc: http://channel.sourceforge.net/boost_join/libs/join/doc/boost_join_design.h… download: http://sourceforge.net/project/showfiles.php?group_id=157583 Thanks Yigong

4 8

Re: [boost] very poor thread performance [OT]
by dhruva 15 May '08

15 May '08

Hi, OFF topic: I am more visible on the boost user list. Threads like this are very helpful to the boost users too. I request the active members on the boost development list to cross post to the users list so that we do not miss out on such discussions. I personally got to learn a lot from this thread, thanks to all the participants. -dhruva -- Contents reflect my personal views only!

1 0

[exception] enable_error_info.hpp uses size_t without including cstddef
by Steven Watanabe 15 May '08

15 May '08

AMDG In addition, size_t should be qualified with std:: In Christ, Steven Watanabe

1 0

[GTL] operator syntax proposal checked into sandbox
by Simonson, Lucanus J 14 May '08

14 May '08

I have completed initial implementation of the operator based syntax I proposed for polygon set operations (Booleans) and hooked up the actual algorithms and data structures to that API. You can see the complete pattern in the sandbox: http://svn.boost.org/trac/boost/browser/sandbox/gtl/gtl The operator&() declaration now looks like this: template <typename geometry_type_1, typename geometry_type_2> polygon_set_view<typename geometry_type_1::operator_arg_type, typename geometry_type_2::operator_arg_type, boolean_op::BinaryAnd, typename geometry_type_1::operator_storage_tag, typename geometry_type_2::operator_storage_tag> operator&(const geometry_type_1& lvalue, const geometry_type_2& rvalue) { return polygon_set_view<geometry_type_1, geometry_type_2, boolean_op::BinaryAnd, typename geometry_type_1::operator_storage_tag, typename geometry_type_2::operator_storage_tag> (lvalue, rvalue, polygon_set_traits<geometry_type_1>::orient(lvalue), boolean_op::BinaryAnd()); } In explanation of what is going on, the polygon_set_view just takes a const ref of each of its arguments and performs the actual algorithm only when its member function is called asking for the result, which it returns by reference because the view has a member to store the result of the algorithm. This has the nice side benefit of eliminating an unnecessary copy that would normally occur if the operator function returned the result of the algorithm by value (which could be very large.) An interesting feature of this design is that the polygon_set_view can accept an polygon_set_view in its geometry type template parameters leading to recursive template instantiation. You can see that in the test case below where the template instantiation recursion depth is equal to the number of chained operator calls made in a single statement. The drawback of the design is that I'll need to overload the operator functions to allow the user to register their own data types as operator arguments since the user geometry type can't be expected to provide a typedef for operator_arg_type. The overloaded operator would use a metafunction that registers the user type as an operator_arg_type. This leads to four declarations for each operator since either or both arguments can be of one flavor or the other. If you drop this miniature test into a cpp and compile against the gtl header files you should see that the compiler handles things nicely. I'm using gcc 4.3.0 to get maximal standard compliance. #include "gtl.h" int main() { polygon_set_data<int> ps1, ps2, ps3; ps1 | (ps2 | ps3); (ps1 | ps2) | ps3; ps2 * ps1; ps1 & ps2 - (ps3 + ps1) ^ ps2; return 0; } I have also changed the point_3d_concept to inherit from the 2d point concept and the polygon_with_holes_concept similarly inherits from the polygon_concept. This leads to a very convenient ability to produce polymorphism of generic geometry types. There are still a few more algorithms that need to be hooked up before the prototype of the re-implemented library is complete, but I wanted to ask for feedback now so that I can get early course correcting advice. The design is still in a state of flux. Thanks, Luke

1 0

Site Accessibility
by David Abrahams 14 May '08

14 May '08

I love the bar at the top of http://www.boost.org/doc/libs/1_35_0/libs/libraries.htm because it makes the getting_started guide and other obvious destinations readily accessible. However, I don't see anything like that at http://boost.org. I would think, at the very least, "Get Boost" should take people to something that /links/ to the getting started guide. Thoughts? -- Dave Abrahams BoostPro Computing http://www.boostpro.com

3 2

random access file iterators ?
by Roland Schwarz 14 May '08

14 May '08

Does anyone know about an implementation of a "random access file iterator"? I.e. an iterator that will allow to access a file via an iterator interface? I know istream and outstream iterators, but these are only output resp. input iterators. I am looking for something that will allow random access too. Thank you for any hints. -- _________________________________________ _ _ | Roland Schwarz |_)(_ | aka. speedsnail | \__) | mailto:roland.schwarz@chello.at ________| http://www.blackspace.at

2 1