May 2010 - Boost - lists.boost.org

Web site problems
by Beman Dawes 06 May '10

06 May '10

In a private email, Chris Ahlstrom reported: >On quite a few pages, when I enter the URL, a blank page comes up. > >Here's one example: > > http://www.boost.org/doc/tools/build/index.html It is actually weirder than that. The URL should be: http://www.boost.org/tools/build/index.html which should forward to: http://www.boost.org/doc/tools/build/v2/index.html but instead http://www.boost.org/doc/tools/build/index.html appears, and as a blank page. Any ideas? --Beman

2 5

1.43.0 range_ex
by Neal Becker 06 May '10

06 May '10

Before 1.43.0, range_ex had boost::make_reversed_range. In 1.43.0, it seems to have been renamed to boost::adaptors::reverse. This is unfortunate, as there is also a boost::reverse function that means something different.

5 7

[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