May 2009 - Boost - lists.preview.boost.org

[Graph] how to test/submit patch
by Tim Keitt 29 May '09

29 May '09

I would like to submit a patch for the Graph library. (This is the iterator splitting issue I raised some time ago.) So what is the procedure? 1) check out source from sourceforge SVN (done) 2) make changes 3) run tests??? (what is the best way to ensure the behavior has not changed?) 4) generate the patch (use svn diff?) 5) submit somewhere I just want to be sure I'm pulling the correct tree and there is some means to run regressions on my changes. Thanks. THK -- Timothy H. Keitt Associate Professor Section of Integrative Biology University of Texas at Austin http://www.keittlab.org/

3 2

[graph] Request for help with BGL bugs (Bug Sprint)
by Jeremiah Willcock 29 May '09

29 May '09

For those participating in the Boost Bug Sprint, I would appreciate help with the following items to help resolve BGL bugs: 1. Someone who has a copy of LEDA (or is willing to download one) can work on tickets 373, 375, and 1326. Ticket 1326 has an old patch that does not apply cleanly to the current version of BGL in Boost. I would also appreciate knowing which of these issues still exist in current versions of Boost. 2. I would appreciate someone looking at bug 735 and bringing its patch up to date. If there is a way to get a copy of the patch for bug 900 (requested on the Boost list), bringing that up to date would be good as well. 3. Someone should test the patch in bug 1021 and see if it breaks anything else in BGL (and fixes the relevant bug). Also, the copy of reverse_graph in there should be turned into a patch and tested to ensure that it does not undo other changes to BGL since it was created. Any help with these issues would be greatly appreciated. -- Jeremiah Willcock

1 0

request for interest in a garbage collection library
by Achilleas Margaritis 29 May '09

29 May '09

Hi, I have placed in boost vault a garbage collection library: http://www.boostpro.com/vault/index.php?action=downloadfile&filename=gc.zip… The major features of this library are: 1) it supports threads; a thread can allocate gc objects and send them to other threads. 2) it is 100% portable c++; only boost and stl are used. 3) gc pointers can point to middle of objects and arrays. 4) block allocation and finalization are customizable. The collector does not do any allocation actually, it only manages blocks. 5) the collector uses the classic mark & sweep algorithm. 6) it has good (or not that bad :-)) performance. On my test machine (a dual core Pentium at 2.5 GHz with 2 GB ram), 50000 objects out of 100000 are swept in 63 milliseconds. Of course, this is due to boost::pool :-). 7) it works with STL containers (the 'how' is described in the readme). The zip file contains a set of unit tests, the API documentation and a readme file which explains the inner workings and the design of the collector. I would appreciate it if people could take a look and share their opinions on it. Best regards Achilleas Margaritis

22 64

[gsoc] Official list released
by troy d. straszheim 29 May '09

29 May '09

On behalf of the panel of mentors, congratulations to the students listed here: http://socghop.appspot.com/org/home/google/gsoc2009/boost And a sincere thank you to all those who applied. There are a large number of entirely worthy proposals that we received that are not on that list. We had about 75 proposals, 11 willing mentors, and as you can see, Google gave us seven slots. It was very difficult to narrow down the list to these seven, and if we'd been given more slots, of course more of you would be on that list. Unfortunately, due to the sheer number of submissions and various, ahem, technical problems, it would not have been (and will not now be) possible to offer specific feedback on submissions that didn't make the cut. For this we apologize. Accepted students should eventually receive email from Google with further instructions. Per the schedule, the "community bonding" period now begins, time to get your dev. environment set up, get to know the toolchain, write some 'hello world' quickbook docs, etc. Ask for help if you need it. You can also visit some of your fellow summer coders on #boost-soc on freenode. -t

5 4

The Boost Bug Sprint is here!
by Marshall Clow 29 May '09

29 May '09

The boost bug sprint starts today Friday, May 29th, and runs through Sunday June 7th. Status 5/29: 812 open tickets. The goal is to address a large number of open bugs/patches/feature requests in the Trac system at <http://svn.boost.org/trac/report/1>. There are currently 812 open tickets; we'd like to knock that number down _a lot_. What can you do? 1) You can fix bugs. * If you are a library maintainer, you can commit your fixes. ;-) * If you are not a library maintainer, you can fix a problem on your local machine (and test it!!), and then attach your fix as a patch to the Trac ticket for the library maintainer to commit. If you do this, please provide a test case that exercises the problem; i.e, one that fails w/o your patch, and succeeds afterwards. 2) You can characterize bugs. * You can attempt to replicate the bug on your system(s), and attach information that you discover to the Trac ticket. This will make it easier for other people to solve the problem, even if you cannot. * You can write test cases demonstrating the problem, and attach them to the Trac ticket. * You can determine if the bug still exists; sometimes they get fixed, and the ticket never gets closed. In this case, try to identify a checkin that addresses the bug; it's always suspicious when bugs go away "by accident." 3) You can test patches. * Some of the tickets in the Trac system contain patches - some are quite old. You can install these patches on your system, and determine if they (a) build, and (b) work. If you do this, please provide detail. Don't just say "works for me" - say "I installed this over revision XXX on system YYY with compiler ZZZ. The patch installed and compiled successfully, and passed all the tests." * You can write test cases for the patches, and attach them to the ticket. 4) You can help implement new features. * There are a whole set of "feature requests" in the Trac system. If you have an idea about one of these, you can add comments to the Trac system. You can attempt to implement these new features, and attach the patch to the ticket. (Don't forget the test cases!!). Every day during the bug sprint, I'll post the # of tickets modified/closed/opened on the previous day, as well as the total number of open tickets. If you aren't sure where to start, you can verify existing patches. Here are a list of patches that have been open at least six months. [ Note: The URL for ticket number XXXX is https://svn.boost.org/trac/boost/ticket/XXXX ] Bug # Library Description 2603 smart_ptr patch for owner_before and owner_less support with shared_ptr/weak_ptr 2581 mpi MPI tutorial sample has missing includes 2509 string_algo case conversion (to_upper) fails in Codegear C++Builder 5.9.3 2484 bimap Const-overload needed for bimap associative_container_adaptor::count() 2482 concept_check msvc-9.0 unreferenced formal parameter warning when using boost::breadth_first_visit 2454 fusion Fusion - MSVC level 1 warnings 2452 fusion Fusion vector warning 4512 supression would be nice, 2390 test "[patch] fix gcc-4.3 ""unused"" warning in floating_point_comparison" 2370 lexical_cast [lexical_cast] Patch to reduce warnings for CodeGear (Borland) 2351 spirit Minor BOOST_SPIRIT_RULE fixes (rule_parser.hpp) 2312 smart_ptr intrusive_ptr::operator= should have by-value argument 2304 spirit Patch to fix warnings in spirit 2297 mpl Workaround for GCC bug 2290 serialization Patch for GCC-4.0.1 compatibility (and better compile time). 2271 serialization Cannot load version 1.35.0 xml archives that contain vectors of primitive types 2208 Python Pyste can use ElementTree from Python 2.5 2149 date_time Updated Daylight Savings Time for Australia/Perth 2142 Python Patch for boost.python - return_pointee_value, 2114 none Patch for export symbols from shared library 2064 tokenizer Interval notation is wrong in tokenizer documentation 2053 threads porting boost to avr32 linux platform 1947 iterator traversal access decoupling 1861 date_time time_duration type can not be correctly written or read of the period spans 24 hours of more (vc9 and probably others). 1850 thread request for unlock_guard (and/or unique_unlock) to compliment lock_guard/unique_lock 1811 Building Boost Help packaging by supporting DESTDIR 1791 lexical_cast fix warning on MSVC warning level 4 1702 random serialization for Mersenne twister 1681 filesystem patch for NTFS symbolic links 1541 parameter [parameter] Patch for missing includes 1535 function [result_of] remove unneeded headers 1534 build Add support for winsdk 6.1.6000 to Boost.Build.v2 1533 iterator boost/function.hpp unneeded in transform_iterator.hpp 1529 fusion Missing include statement 1521 bimap Missing #include statements 1519 iterator lvalue-ness resurrection in transform_iterator 1437 random "normal_distribution.hpp, improvements to distribution and possibly speed" 1418 serialization polymorphic archive performance improvement 1377 GIL Add ability to save RGBA image as TIFF with associated-alpha (premultiplied) transparency channel. 1341 asio unused argument and another g++ warning 1338 numeric g++ warnings and incomplete header inclusions 1271 Python unused parameter warning in release build 1116 build disable some warnings in msvc build 1066 Python Patch to make Boost.Python compile on SunCC 1049 mpl Getting mpl/has_xxx.hpp to compile on AIX 1020 iterator Boost.Iterator proposal to add is_constant_iterator 903 Python inconsistent usage of function pointer typedefs 868 thread [thread] thread_specific_ptr::element_type ? 864 lambda [lambda][utility] Make lambda support result<> 863 [parameter] fix operator|| for lazy binding 861 parameter Detect nested template members with has_template_xxx,mpl 857 Python add shared_ptr< const T> support 827 date_time Unused variable in format date parser, 802 thread [thread] MSVS: Allow use of thread headers with /Za 761 mpl [mpl] evc4 port 717 Python Add operator for __repr__ similar to __str__ 637 mpl Adjusts mpl::pair concept to be compatible with STL pairs --------- Sign-up sheet -------- The following people have committed to participate in the bug sprint. Please add you name here, along with what you can do. 1) Marshall Clow (coordination, Mac OS X characterization) 2) Beman Dawes (filesystem, system, timer) 3) Doug Gregor (function, graph, logic, mpi, numeric, property_map, signals) 4) "joel falcou" <joel.falcou(a)u-psud.fr> ( linux gcc testing/VC 2008 testing, patching) 5) Michael Caisse <boost(a)objectmodelingdesigns.com> (bug fixing) 6) Jeremiah Willcock <jewillco(a)osl.iu.edu> (will test and commit graph patches) 7) David Abrahams (iterator, python) 8) Sohail Somani (patches for g++ 4.2.4) 9) Steven Watanabe <watanabesj(a)gmail.com> (bug fixes, como) 10) vicente.botet" <vicente.botet(a)wanadoo.fr> 11) Stjepan Rajko <stjepan.rajko(a)gmail.com> (fusion) 12) Daniel Wallin (parameter, ...) -- -- Marshall Marshall Clow Idio Software <mailto:marshall@idio.com> It is by caffeine alone I set my mind in motion. It is by the beans of Java that thoughts acquire speed, the hands acquire shaking, the shaking becomes a warning. It is by caffeine alone I set my mind in motion.

2 2

minmax_element and sorted data
by Steven Ross 29 May '09

29 May '09

I've noticed that minmax_element makes roughly 3n/2 comparisons, though n - 1 comparisons are all that is required to see if data is sorted, and if it is, the minimum and maximum are known. Sorted data is a relatively common special-case, and I think minmax_element might be better optimized to take advantage of sorted data when it is provided. Also, it would be nice to have a version of it that returns the minimum, maximum, and whether the data is sorted. Also worth considering is whether minmax_element can work more efficiently with long chains of sorted (or reverse-sorted) data, by taking advantage of the fact that the maximum and minimum of sorted data is known, and it takes n - 1 comparisons to tell whether a list of n items is sorted. An example of how sorting can be tested without hurting overall runtime for unsorted data is how I find the minimum and maximum for integer_sort. Note that when the data is sorted, it returns with max and min being identical; a boolean could provide that information in a more general method. Source: //Find the minimum and maximum using < template <class RandomAccessIter> inline void find_extremes(RandomAccessIter current, RandomAccessIter last, RandomAccessIter & max, RandomAccessIter & min) { min = max = current; //It is assumed we have more than 1 element; there are multiple checks for this while(!(*(current + 1) < *current)) { //If everything is in sorted order, return if(++current == last - 1) return; } //The maximum is the last sorted element max = current; //Now that we know it isn't sorted, doing an efficient max/min find std::pair<RandomAccessIter, RandomAccessIter> vals = minmax_element(++current, last); if(*(vals.first) < *min) min = vals.first; if(*max < *(vals.second)) max = vals.second; }

1 0

Re: [boost] [parameter] Testing for existence of a parameter, building ArgumentPacks, more lazy return types
by Jeremiah Willcock 29 May '09

29 May '09

(reposting because of no response) >> I have a few questions about the parameter library. Please note that I am >> using >> argument packs directly, since I am creating them from another data >> structure. >> >> 1. Is there a way to build Boost.Parameter ArgumentPacks from a >> program? > > Yes, and it's documented. Have you read through the documentation, or > do you mean something else? Are you talking about section 3.2.1? I also need to get the types of the resulting ArgumentPacks. >> I am currently using many internal data structures of Boost.Parameter >> (empty_arg_list and such). > > That doesn't sound like a public interface to me, but maybe it should > be. Yes, that is the issue. I could use the operators in 3.2.1 but need a way to get the type of the result. >> 2. Is there a way to tell at compile-time whether a particular >> parameter exists in an ArgumentPack? I currently have a metafunction >> that uses a special default type and tests for that; is there a more >> "official" way? > > Nope, that's the way we recommend. OK. I guess I would prefer an explicit metafunction for that. >> 3. I have a case where the default type for a named parameter cannot >> be instantiated in some cases where that parameter is given >> explicitly. The operator||() lazy defaults don't seem to work for >> that because they get the result_type member from my default right >> away, even if it won't be used. > > Ouch. It would be nice to have a fix for that one. > >> I currently have a hack to work around this using my parameter_exists >> test and some metaprogramming. >> >> The reason I am working on this low of a level is that I am playing >> with converting Boost.Graph named parameter structures into >> ArgumentPacks > > About time! I know. I just started playing with it over the weekend. >> to have access to Boost.Parameter's nicer capabilities >> and syntax. I thus need to build all of the argument data structures >> and such within another function and then access them later. > > I'm not sure what you're saying here, Jeremiah. Are you talking about > building the backward-compatibility interface for the old syntax, here? > The generation macros should be enough to handle all the new-syntax > cases. Yes -- I am starting with keeping the old external interfaces (only) and translating the implementation to use Boost.Parameter internally. This means that users will not see any changes and yet the internals of BGL can use Boost.Parameter default computation and such. Later, once that's working, the external interfaces can be switched. One more question -- I have a situation where I'd like to declare an extra variable only when a certain parameter is not specified, and the type of that variable may not even be valid when the parameter is specified. In more detail, I'd like to write something like (pseudocode): if parameter color_map is specified { auto color_map = color_map parameter } else { std::vector<default_color_type> color_data; auto color_map = f(color_data); } I can stand having something like a dummy int as the default case for color_data, but the type of color_map changes based on whether the parameter was specified or not. Is there an easy way to do that? You can also look at the bottom of boost/graph/named_function_params.hpp and in boost/graph/depth_first_search.hpp (the one file I've tried to convert) to see the ways I'm doing things now and what I'm trying to do. Thank you. -- Jeremiah Willcock

1 0

[Signal] Variadic template implementation of signal/slot
by Kevin Brandon 29 May '09

29 May '09

Would anyone be interested in seeing my implementation of Signals/Slots that uses the variadic template capability that will be a part of c++0x standard? It seemed to me a natural evolution for the current library that is Signal\Signal2. I did not baseline from the current boost code; but, if the interest exists, I would love to submit my code for formal review and equally try to integrate and respect the design decisions that already fostered the growth for the other two versions. Regards, Kevin Brandon

5 7

[fusion] adding infinite sequences to fusion
by Stjepan Rajko 29 May '09

29 May '09

Hi all, There's been some off-list discussion between Dan Marsden, Joel de Guzman and myself on how to address infinite sequences in fusion. Joel suggested to bring the discussion back to the list for more feedback: On Wed, Apr 15, 2009 at 6:21 PM, Joel de Guzman <djowel(a)gmail.com> wrote: > Stjepan Rajko wrote: >> >> Here is a list and description of all of the concepts that might be >> relevant: >> >> >> Forward Sequence >> begin(s) - returns a Forward Iterator >> empty(s) - returns a bool >> front(s) - any type >> >> Finite Forward Sequence >> refines Forward Sequence >> end(s) - returns a Forward Iterator >> size(s) - MPL integral constant >> >> Infinite Forward Sequence >> refines Forward Sequence >> empty(s) - returns false >> size(s) - infinity >> >> Bidirectional Sequence >> refines Forward Sequence >> begin(s) - returns a Bidirectional Iterator >> >> Finite Bidirectional Sequence >> refines Bidirectional Sequence, Finite Forward Sequence >> end(s) - returns a Bidirectional Iterator >> back(s) - any type >> >> Infinite Bidirectional Sequence >> refines Bidirectional Sequence, Infinite Forward Sequence >> >> Random Access Sequence >> refines Bidirectional Sequence >> begin(s) - returns a Random Access Iterator >> >> Finite Random Access Sequence >> refines Random Access Sequence, Finite Bidirectional Sequence >> end(s) - returns a Random Access Iterator >> >> Infinite Random Access Sequence >> refines Random Access Sequence, Infinite Bidirectional Sequence >> >> >> How does that look? > > I'd suggest posting that to the Boost list to get more feedback. > I have a feeling that infinity is a separate concept orthogonal > to traversal. But I'm not sure. > The above layout is almost orthogonal, with Infinite Forward Sequence and Finite Forward Sequence serving as "base" concepts related to Finite / Infinite. I suppose you could have less refined Infinite Sequence and Finite Sequence concepts, but I'm not sure how useful they would be (AFAICT, they could only describe `size` and `empty`). Things aren't perfectly orthogonal because Finite + Bidirectional require `back`, but Finite + Forward do not, and neither do Infinite + Bidirectional. Best, Stjepan > Regards, > -- > Joel de Guzman > http://www.boostpro.com > http://spirit.sf.net >

2 2

[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

sparse bitset
by Anuj Garg 28 May '09

28 May '09

my application requires sparse bitsets. Type requirements: *Block *is an unsigned integer type how hard would it be to replace this with a custom structure. basically instead of storing them as a Array or uint's i would like to store them as a link-list of uint or hash-map.

2 1

Spirit Not Parsing
by Aston 28 May '09

28 May '09

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 http://in.travel.yahoo.com/

1 0

G++ hack/challenge?
by David Abrahams 27 May '09

27 May '09

Hi all, In preparation for BoostCon, I'm looking for a workaround for the problems described in http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2855.html. In particular I need a way to detect whether a type "has a move constructor" (without causing a compiler error, of course) in GCC 4.4. Ideally, "has a move constructor" would mean - when constructed from an rvalue of the same type, a copy constructor with signature T(T const&) is not used. though I would settle for - has a constructor with the signature T(T&&) I'm willing to use G++-specific hackery if necessary. I strongly suspect it's impossible, but if you can think of any way to do it, I'd really appreciate knowing about it. You'll be my hero forever ;-) TIA, -- Dave Abrahams BoostPro Computing http://www.boostpro.com

3 3

Review request: gil::io
by Christian Henning 26 May '09

26 May '09

Hi to all, the new gil::io extension is ready for review. The release candidate is available from the link below containing the header files, tests, and documentation. There are jamfiles available to run the tests and to compile the documentation. http://gil-contributions.googlecode.com/files/rc2.zip This file is almost 9 MB due to the amount of test images I'm using for testing. If that's a problem I can certainly create a slimmer release candidate. A lot of things have changed for this extension but also a lot of things haven't. The interface is more or less the same. But the list of features has been grown by a lot. For instance, all formats support now in-memory read and write. The tiff extension supports a lot more formats to be read and written. n-bit images are now supported for all formats that include those. etc. etc. Right now the lib is called gil::io_new but once it's accepted it will be renamed to gil::io. Of course, I'm open for all kinds of input, critiques, and insights. Thanks a lot to all people who have helped me on this release! Regards, Christian

6 14

Using boost with visual studio 2010
by Sean Farrow 26 May '09

26 May '09

Hi: I am looking at using boost with the beta 1 of visual studio 2010. If this compiler isn't detected automatically, what files will I need to alter? Any help Appreciated Sean. __________ Information from ESET NOD32 Antivirus, version of virus signature database 4102 (20090525) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com

2 1

The Boost Bug Sprint is coming!!
by Marshall Clow 26 May '09

26 May '09

The boost bug sprint is coming! It starts next Friday, May 28th, and runs through Sunday June 7th. The goal is to address a large number of open bugs/patches/feature requests in the trac system at <http://svn.boost.org>. There are currently 795 open tickets; we'd like to knock that number down _a lot_. What can you do? 1) You can fix bugs. * If you are a library author, you can commit your fixes. ;-) * If you are not a library author, you can fix a problem on your local machine (and test it!!), and then attach your fix as a patch to the Trac ticket for the library author to commit. If you do this, please provide a test case that exercises the problem; i.e, one that fails w/o your patch, and succeeds afterwards. 2) You can characterize bugs. * You can attempt to replicate the bug on your system(s), and attach information that you discover to the Trac ticket. This will make it easier for other people to solve the problem, even if you cannot. * You can write test cases demonstrating the problem, and attach them to the Trac ticket. * You can determine if the bug still exists; sometimes they get fixed, and the ticket never gets closed. 3) You can test patches. * Some of the tickets in the trac system contain patches - some are quite old. You can install these patches on your system, and determine if they (a) build, and (b) work. * You can write test cases for the patches, and attach them to the ticket. 4) You can help implement new features. * There are a whole set of "feature requests" in the Trac system. If you have an idea about one of these, you can add comments to the trac system. You can attempt to implement these new features, and attach the patch to the ticket. (Don't forget the test cases!!). Every day during the bug sprint, I'll post the # of tickets modified/closed/opened on the previous day, as well as the total number of open tickets. --------- Sign-up sheet -------- The following people have committed to participate in the bug sprint. Please add you name here, along with what you can do. 1) Marshall Clow (coordination, Mac OS X characterization) 2) Beman Dawes (filesystem, system, timer) 3) Doug Gregor (function, graph, logic, mpi, numeric, property_map, signals) -- -- Marshall Marshall Clow Idio Software <mailto:marshall@idio.com> It is by caffeine alone I set my mind in motion. It is by the beans of Java that thoughts acquire speed, the hands acquire shaking, the shaking becomes a warning. It is by caffeine alone I set my mind in motion.

4 3