- Boost - lists.boost.org

[MultiIndex] Recursive data structure with MultiIndex
by Sebastian Redl 29 May '09

29 May '09

Hi, I'm trying to implement property_tree in terms of multi_index, but have run into a problem. The old implementation boiled down to this (using no templates for clarity): class ptree { typedef std::pair<std::string, ptree> value_type; typedef std::list<value_type> list_type; list_type m_children; }; This is undefined behavior, because at the point where the list is instantiated, ptree is incomplete, so the pair cannot be fully instantiated. However, apparently it worked on enough compilers. Now I want to use MultiIndex instead, so that I can have both the order of children preserved and offer O(log(N)) lookup of children. (The old code was O(N), but claimed to be O(log(N)).) But MultiIndex actually fails to instantiate with the incomplete type. More concretely, what fails to instantiate is the key retriever, a member<value_type, std::string, &value_type::first>. This is because the member access into the pair requires pair to be fully instantiated, and the instantiation fails as the ptree is incomplete. I'm not very fond of the idea of storing pointers, especially as there is no ptr_multi_index_container. But is there any other way, really? Sebastian

2 4

Trac policy on "won't fix" issue
by Vladimir Prus 29 May '09

29 May '09

Suppose there's an issue in Trac about program_options library. The issue is such that I personally have no hope of *ever* fixing it. What should be done to such issue: 1. Close it as won't fix. 2. Keep it open. (1) has the advantage that the issue won't show up in my searched, making life easier for me, but it reduces chances that somebody else will accidentally see and fix it. OTOH, the chances of such fix are also pretty low. So, I personally prefer (1), but I also think we should have a single consistent meaning of what open issue in Trac means, and under what cases an issue that is not actually fixed can be closed. Any comments? - Volodya

9 12

[asio] Bug in allocation of timer
by puzirev＠gmail.com 28 May '09

28 May '09

Wrong allocation of timer in timer_queue.hpp: template <typename Handler> bool enqueue_timer(const time_type& time, Handler handler, void* token) { ... // Create a new timer object. std::auto_ptr<timer<Handler> > new_timer( new timer<Handler>(time, handler, token)); // <-- ATTENTION ... new timer<Handler>(...) later will be dealocated with asio_handler_deallocate Solution: allocate new timers with asio_handler_allocate // Create a new timer object. typedef timer<Handler> timer_type; typedef handler_alloc_traits<Handler, timer_type> alloc_traits; raw_handler_ptr<alloc_traits> raw_ptr(handler); handler_ptr<alloc_traits> new_timer(raw_ptr, time, handler, token);

1 0

bug in boost::asio
by puzirev＠gmail.com 28 May '09

28 May '09

Wrong allocation of timer in timer_queue.hpp: template <typename Handler> bool enqueue_timer(const time_type& time, Handler handler, void* token) { // Ensure that there is space for the timer in the heap. We reserve here so // that the push_back below will not throw due to a reallocation failure. heap_.reserve(heap_.size() + 1); // Create a new timer object. std::auto_ptr<timer<Handler> > new_timer( new timer<Handler>(time, handler, token)); // <-- ATTENTION ... new timer<Handler>(...) later will be dealocated with asio_handler_deallocate Solution: allocate new timers with asio_handler_allocate // Create a new timer object. typedef timer<Handler> timer_type; typedef handler_alloc_traits<Handler, timer_type> alloc_traits; raw_handler_ptr<alloc_traits> raw_ptr(handler); handler_ptr<alloc_traits> new_timer(raw_ptr, time, handler, token);

1 0

Re: [boost] Second call: The Boost Bug Sprint is coming!!
by Stjepan Rajko 28 May '09

28 May '09

On Tue, May 26, 2009 at 6:10 AM, Marshall Clow <marshall(a)idio.com> wrote: > The boost bug sprint is coming! It starts _this_ Friday, May 28th, and runs > through Sunday June 7th. > Thanks for organizing this. I just started going through fusion tickets, so I guess sign me up :-) Best, Stjepan

1 0

Re: [boost] Spirit Not Parsing
by Aston 28 May '09

28 May '09

ooppss...my bad mistake is in parse_conf_file() below line is incorrect, wrong grammar rule<> conf_lines = l_root | *l_params | l_end; correct line is rule<> conf_lines = l_root >> *l_params >> l_end; sorry for pollution ________________________________ From: Aston <blackapache512-ticket(a)yahoo.com> To: boost(a)lists.boost.org Sent: Thursday, 28 May, 2009 10:18:16 AM Subject: Spirit Not Parsing Hello, I am evaluating Boot.Spirit for parsing a custom format. I have presented the code below and config file as well. I expect numUsers to be 2 but it is zero, indicating that integer_action() was not call at all. I tried with assign_d as well, it also didn't help. I guess I am missing something, and I cannot figure out that since parse() returns 0. can anybody point that out ? thanks, Aston ============ src file begin ============ #include <iostream> #include <fstream> #include <string> #include <boost/spirit.hpp> using namespace boost::spirit; int numUsers = 0; void integer_action( const int& var) { numUsers = var; }; int parse_conf_file( char* buffer) { rule<> l_root = str_p("FakeRC") >> *blank_p >> *alpha_p >> eol_p; rule<> l_params = *blank_p >> *alpha_p >> *blank_p >> str_p("Integer") >> *blank_p >> *int_p[&integer_action] >> eol_p; rule<> l_end = str_p("end") >> eol_p; rule<> conf_lines = l_root | *l_params | l_end; return parse( buffer, conf_lines).full; } int main( int argc, char** argv) { std::ifstream conf(".fakerc", std::ios::binary); conf.seekg( 0, std::ios::beg); int start = conf.tellg(); conf.seekg( 0, std::ios::end); int end = conf.tellg(); int size = end - start; conf.seekg( 0, std::ios::beg); char* buffer = new char[size]; std::fill( buffer, buffer + size, 0); conf.read( buffer, size); buffer[size - 1] = 0; int err_code = parse_conf_file( buffer); std::cout << ( err_code == 0 ? "success" : "failed"); std::cout << ": " << err_code << std::endl; std::cout << "numUsers: " << numUsers << std::endl; delete[] buffer; conf.close(); return 0; } ============ src file end ============ ============ .fakerc contents ============ FakeRC FakeRC_Name Users Integer 2 end ============ end .fakerc ============ ________________________________ Explore and discover exciting holidays and getaways with Yahoo! India Travel Click here! Bollywood news, movie reviews, film trailers and more! Go to http://in.movies.yahoo.com/

2 1

Re: [boost] [pool] object_pool::destroy_all? (from users)
by diego nieto cid 28 May '09

28 May '09

Hi, Anybody knows what happened to the iterator that was suggested? I mean, what keeps it from being added to the library? Michael Marcin-2 wrote: > > Yes, destructing and recreating the object pool will release and > allocate memory with the system heap. > > - Michael Marcin > May that be avoided by calling the destructors and constructors directly? For example, destroy_all (object_pool& pool) { pool.~object_pool(); new (&pool) object_pool(); } I'm not sure about the correctness of those instructions. Anyway, its not something you want all around your code. -- View this message in context: http://www.nabble.com/-pool--object_pool%3A%3Adestroy_all--%28from-users%29… Sent from the Boost - Dev mailing list archive at Nabble.com.

1 0

[Boost-graph] Trunk nightly testing failures
by Belcourt, Kenneth 28 May '09

28 May '09

Hi, All trunk nightly tests are failing with this diagnostic. error: Unable to find file or target named error: 'subgraph_props.cpp' error: referred from project at error: '../libs/graph/test' Seems like a file is missing. -- Noel

2 1

CMake and library requirements
by Vladimir Prus 28 May '09

28 May '09

Looking at: http://www.boost.org/development/requirements.html#Directory_structure I see that sub-directory 'build' should contain 'Library build files such as a Jamfile'. In SVN HEAD I also see: libs/program_options/CMakeLists.txt Now, cmake is clearly build system, so that file is in violation of the above guideline. May I ask to either: 1. Have cmake folks to fix this? 2. Have the guideline adjusted, with associated moving of Jamfiles out of 'build' directory and removal of 'build' directories that become empty as result? The background is that I plan some work that might require adding Jamfiles for header-only libraries and clearly having Jamfiles in build subdir while having CMakeLists.txt one directory higher is gonna be mightly confusing. Thanks, Volodya

4 4

Re: [boost] Integral type with no upper limit?
by Barend Gehrels 28 May '09

28 May '09

>> >>> Perhaps Boost shouldn't reinvent the wheel? There's already an open-source >>> arbitrary precision arithmetic library: http://gmplib.org/ >>> >> Which says: >> GMP is distributed under the GNU LGPL. This license makes the library >> free to use, share, and improve, and allows you to pass on the result. The >> license gives freedoms, but also sets firm restrictions on the use with >> non-free programs. >> >> There are people using Boost for both free and non-free programs. >> It's my understanding that we (Boost) want to continue to support all of >> them. >> >> > > Personally, I think Boost would be best served providing some sort of > expression template wrapper into which different arbitrary-precision > numbers could be plugged. > We (Bruno and me) are creating exactly this thing. It will be finished soon. We will use it in our other library, GGL, but we develop it separately. > That would mean far less work to get something usable, as it could use > the GMP implementation initially. We do GMP, CLN and IEEE (so float/double/long double). So the code using the library will be independant of which numeric type is used, and can use it also for standard numeric types transparently. > Then a BSL version of the > implementation could be developed incrementally, while non-floss users > could license some implementation to use with the Boost interface. > > Regards, Barend p.s. I intentionally send this to the other list because it is a "developers subject" and because my messages don't come through.

2 1