- Boost - lists.boost.org

[gsoc] heaps & queues
by Tim Blechmann 06 May '10

06 May '10

hi all, i'm the student, working on the heaps&queues project during this year's summer of code. i have also been in touch with my mentor about this, but thought, it may be a good idea to hear some comments from other boost devs. i would like to implement the priority queue data as intrusive data structures, which can simply be wrapped to non-intrusive ones. the main reason for this approach is the mutable property. in order to provide a mutable priority queue, one would either need a handle to the inner node (like in dietmar kuehl's pri_queue) or provide a lookup table (as in boost/pending/mutable_queue). both approaches are somehow problematic. otoh, if i want to change the priority of a node, it would be natural to use an intrusive data structure for this. the non-intrusive version would be simply a wrapped version of the intrusive implementation, and would simply lack the mutable property. the question then would be, whether i should try to introduce it into boost.intrusive, or implement it as a library on its own. boost.intrusive already provides a treap, so it would be quite logical to include heap data structures as well. otoh, having a heap library with both intrusive and non- intrusive data structures, one would have everything in one place. so, i see benefits in both approaches, but would like to hear, what other people think about it ... cheers, tim -- tim(a)klingt.org http://tim.klingt.org The first question I ask myself when something doesn't seem to be beautiful is why do I think it's not beautiful. And very shortly you discover that there is no reason. John Cage.

2 3

[1.43.0] Release Candidate available
by Ralf Globisch 06 May '10

06 May '10

boost_1_43_0.7zip build success with msvc-9.0 bjam toolset=msvc-9.0 --build-type=complete OS: Windows7 No python, no ICU, no MPI

2 1

[release][1.43] Release notes and some other things
by Daniel James 06 May '10

06 May '10

Hello all, Please can you add your release notes for 1.43. If you can't, or don't know how, then just send them to me and I'll do it for you. Sorry I'm late asking this time round. If you didn't realise, you don't have to wait for me to ask, I create the file for the release notes at the beginning of the release cycle. Also, if haven't done so already, can you check the inspect report for your library. It's not too late to fix simple inspect errors (eg. missing newlines, tabs, licenses, broken links) although it is too late to change any code (unless it's an actual bug, of course). You can find links to it on the testing page (http://www.boost.org/development/testing.html) And finally, can you have a look at your library's documentation on the beta site and let me know if it's messed up, as I've been tweaking the way the documentation is displayed. It's still displaying the 1.42 documentation, we only update that after the release. thanks, Daniel

7 12

[Inspect] More Apple issues
by John Maddock 06 May '10

06 May '10

I keep getting bug reports from users who want to compile code as Objective-C++ in order to use the Apple OS X headers... unfortunately this adds some more relatively common names that we can't use (http://developer.apple.com/mac/library/documentation/cocoa/conceptual/Objec…) id, Class, SEL, IMP, and BOOL Should we changes the inspect tool to complain about these as well? Obviously this is a pain in the &*^%, but it would stop my code from regressing (again) I guess... Cheers, John.

3 4

spoiled function declarations
by Lorenzo Caminiti 06 May '10

06 May '10

Hello all, I have been looking to which Boost libraries provide an interface that "spoils" usual C++ function declaration using macros. So far I found that both Boost.ConceptCheck and Boost.Parameter replace usual C++ function declaration using macros (see sample code below). Do you know of any other Boost library that "spoils" usual C++ function declaration? Boost.ConceptCheck: template<typename RanIter> BOOST_CONCEPT_REQUIRES( ((Mutable_RandomAccessIterator<RanIter>)) ((LessThanComparable<typename Mutable_RandomAccessIterator<RanIter>::value_type>)), (void)) // return type within macro instead that before function name stable_sort(RanIter,RanIter) { ... } Boost.Parameter (quite a bit more involved): BOOST_PARAMETER_FUNCTION( (void), // 1. parenthesized return type depth_first_search, // 2. name of the function template tag, // 3. namespace of tag types (required (graph, *) ) // 4. one required parameter, and (optional // four optional parameters, with defaults (visitor, *, boost::dfs_visitor<>()) (root_vertex, *, *vertices(graph).first) (index_map, *, get(boost::vertex_index,graph)) (in_out(color_map), *, default_color_map(num_vertices(graph), index_map) ) ) ) { // ... body of function goes here... // use graph, visitor, index_map, and color_map } Thank you very much. -- Lorenzo

6 6

[Bind] Interoperability of bind/mem_fn with transform_iterator
by Samuel Debionne 05 May '10

05 May '10

Hello all, I'm scratching my head about the correct way to use transform_iterator with bind and mem_fn. In brief, bind and mem_fn return object functions that are not Default Constructible, which means that, when used to construct a transform_iterator, the resulting transform_iterator is not even a Trivial Iterator. Most of the case, it's not a problem because the transform_iterator is never default constructed... until some libs that do concept checking on their template parameters are used. See the following code for exemple : #include <vector> #include <boost/bind.hpp> #include <boost/iterator/transform_iterator.hpp> #include <boost/iterator/iterator_concepts.hpp> #include <boost/concept/requires.hpp> struct foo { size_t id_; size_t get_id() const {return id_;} }; template <class ForwardIterator> void check(ForwardIterator _it) { using namespace boost; function_requires< boost_concepts::ForwardTraversalConcept<ForwardIterator> >(); } int main(int argc, char* argv[]) { using namespace boost; std::vector<foo> foo_vec; //Fail to compile since mem_fn is not Default Constructible check(make_transform_iterator( foo_vec.begin(), mem_fn(&foo::get_id))); //Fail to compile since mem_fn is not Default Constructible check(make_transform_iterator( foo_vec.begin(), mem_fn(&foo::id_))); return 0; } What would be the best way to handle the "problem" ? Patch the bind library to add some default constructors ? Best Regards, Samuel

5 13

[Proto] Broken on trunk
by Doug Gregor 05 May '10

05 May '10

Proto and the libraries that depend on it are broken in trunk: http://www.boost.org/development/tests/trunk/developer/proto.html It appears to be due to this change: https://svn.boost.org/trac/boost/changeset/61782 - Doug

2 1

Re: [boost] [xint] Third release is ready, requesting preliminary review
by Jürgen Hunold 05 May '10

05 May '10

On Tuesday, 4. May 2010 17:32:58 you wrote: > On 05/04/2010 05:51 AM, Jürgen Hunold wrote: > > And it make things easiser if you only have on "red" entry in the summary > > page and can just see which test file to look at. > > And smaller test cases are just current Boost standard. > > That works, then. Thanks for satisfying my curiosity. You're welcome. > > And I think the patch > > > > +#ifdef BOOST_XINT_SINGLE_TEST_PROGRAM > > + #define BOOST_TEST_DYN_LINK > > +#else > > + #define BOOST_TEST_MAIN > > +#endif > > > > is wrong. BOOST_TEST_DYN_LINK should always be defined on the command > > line when linking against a shared Boost.Test library. So, no source > > code #define is necessary. > > But removing the BOOST_TEST_MAIN from all but one of the files, when > using a single test program, is. Yes, BOOST_TEST_MAIN is needed. #if !defined(BOOST_XINT_SINGLE_TEST_PROGRAM) #define BOOST_TEST_MAIN #endif is the "correct" solution > I'm fairly new to Boost.Test, but the documentation gave me the > impression that you had to make a decision on whether to use dynamic > linking or not when you wrote the code, because static and dynamic > linking need slightly different setups. That would suggest that you > can't easily switch between them, wouldn't it? Well, I use the same code for static ansd shared linking :-)) You are using AUTO_TEST_CASEs, so there is no problem. All the needed magic is hidden in BOOST_TEST_MAIN in combination with BOOST_TEST_DYN_LINK. Using "manual registration" can be tricky. > > And this issues > > " > > test_main.cpp:95:1: warning: "BOOST_TEST_DYN_LINK" redefined > > <command-line>: warning: this is the location of the previous definition" > > > > when compiling a shared library with all Boost.Build magic enabled. > > Eh? The library code doesn't use Boost.Test, only the testing code does. > And even the testing code only includes that #define when > BOOST_XINT_SINGLE_TEST_PROGRAM is defined, which it should never be > except on my development machine, or that of someone else doing > modifications to the library. That would be me ;-) I've added the single test program locally to get the errors messages. Adding "BOOST_TEST_DYN_LINK" in source code is potentially dangerous. It should really be a commandline-option. It should be possible to set in Code::Blocks. > > By the way: > > You have deleted test/Jamroot. Should there be a "test/Jamfile" instead ? > > Yes, there should. Did it not make it into Subversion? Checking... it > appears that it's there, so I'm not sure what to tell you. Maybe check > it out manually? No, it is definetely missing. > > build/Jamfile.v2 still contains "nothrow_random.cpp" which was deleted in > > 61752 as well. > > Sorry, I didn't remember to update that. I would have caught it before a > final release though, I have an entire checklist of things to do for that. Good. > > And I think you may also check in files for other build systems, too. > > Some libraries have Makefiles as well as visual studio solutions. > > I didn't think anyone would care about my Code::Blocks or Visual Studio > projects. If there's some interest in them, I'll add them in the next > repository update. Not really. I've never used Code::Blocks ;-)) Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! * voice: ++49 4257 300 ! Fährstraße 1 * fax : ++49 4257 300 ! 31609 Balge/Sebbenhausen * juergen.hunold(a)gmx.de ! -- * Dipl.-Math. Jürgen Hunold ! Ingenieurgesellschaft für * voice: ++49 511 262926 57 ! Verkehrs- und Eisenbahnwesen mbH * fax : ++49 511 262926 99 ! Lister Straße 15 * juergen.hunold(a)ivembh.de ! www.ivembh.de * * Geschäftsführer: ! Sitz des Unternehmens: Hannover * Prof. Dr.-Ing. Thomas Siefer ! Amtsgericht Hannover, HRB 56965 * PD Dr.-Ing. Alfons Radtke !

2 1

[xint] Boost.Move vs Copy-on-Write timings
by Chad Nelson 05 May '10

05 May '10

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I've done some further testing, eliminating the Boost.Thread locking on the random number generator as a factor, as promised earlier today. Here are the raw timings: (Debug build) Baseline: 29.4, 36.0, 32.8 (32.73) GCC move: 32.0, 35.3, 31.2 (32.83) Emulated Move: 28.4, 33.8, 28.4 (30.20) Copy-on-write: 27.3, 25.0, 26.9 (26.40) (Release build) Baseline: 10.5, 12.5, 10.6 (11.20) GCC move: 11.3, 13.0, 10.4 (11.57) Emulated move: 10.0, 10.8, 9.7 (10.17) Copy-on-write: 8.5, 8.4, 9.4 ( 8.77) Times are measured in seconds, using two sets of ten 2048-bit integers. The tests consisted of adding each of those pairs of numbers together 10,000 times, multiplying them 10,000 times, and doing a "mulmod" operation on them (with a third randomly-generated 2048-bit modulus argument) 1,000 times. Each test was run three times, under as close to identical situations as I could manage, with the raw results (rounded to the nearest tenth of a second) in the first three columns; the fourth column is the average of the three. The compiler used was GCC 4.4.3, under Ubuntu Linux 10.04. The release build used -O2 optimization; the debug build used none. Otherwise, the settings were left at their defaults, except where noted below. The baseline configuration had neither copy-on-write nor any kind of move semantics enabled. The "emulated move" rows used the baseline configuration plus Boost.Move in C++03 emulation mode, with no copy-on-write; the "GCC move" rows indicate the exact same configuration, except that I used "-std=c++0x" as well (so presumably Boost.Move would switch to compiler-supplied move semantics). The copy-on-write rows used the baseline configuration, but enabled my copy-on-write system. Using the calculation... (baseline_time - time) / baseline_time ... copy-on-write provided a 19.3% and 21.7% speed increase over the baseline settings. Boost.Move emulation provided 7.7% and 9.2%. GCC-provided move semantics were, surprisingly, the worst performers, coming in at 0.3% and 3.3% *worse* than the baseline performance. I'm assuming that that code hasn't been optimized yet, and that it will eventually be a lot faster. Conclusions: * The copy-on-write system is faster than Boost.Move emulation by a respectable amount, and an even greater one than my earlier tests indicated. * The non-thread-safe version is *not* twice the speed of the thread-safe one, as I erroneously indicated before. Much of the difference must have come from the random number locking. It's still markedly faster, as it uses copy-on-write and the thread-safe version can only use Boost.Move, but only by about 12%. Am I missing any statistics? Does anyone want the test code to reproduce this and look for errors in my test setup? It's only a small modification from the code in the sandbox and vault, plus the test function. - -- Chad Nelson Oak Circle Software, Inc. * * * -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkvd5ZwACgkQp9x9jeZ9/wTnnQCfYt1MrUNFGnYKNJImYKuuryDf HfYAoIrXeBgsT25cCwI/oiIAShSyvyh0 =nZxq -----END PGP SIGNATURE-----

7 36

[GSoC] Helping out Phoenix v3
by Joel Falcou 04 May '10

04 May '10

Joel and I pondered about getting a student from GSoC to help us complete the phoenix v3 port to proto. I currently have a few prototypes and ideas to extend it further but a few more hands are most welcome. Considering the schedule, I'll be compeltely free for mentoring this prospective student. Now, is it realistic and on topic for GSoC ?

9 33