- Boost - lists.boost.org

[MSM] passing constructor arguments to frontend as reference.
by Richard Szabo 06 May '10

06 May '10

Hi, All we might found a problem when passing constructor arguments to the front end in case constructor arguments are passed by reference. In that case you do not pass the argument as reference in the first place rather copy construct a new object and pass that object as reference to the front end. We looked into the preprocessor code which we believe verified our assumption: (code snippet only contains the first part with one constructor argument!) template < class ARG0> state_machine<Derived,HistoryPolicy,CompilePolicy >( ARG0 t0 ) :Derived( t0) ,m_events_queue() ,m_deferred_events_queue() ,m_history() ,m_event_processing(false) ,m_is_included(false) ,m_visitors() ,m_substate_list() { ::boost::mpl::for_each< seq_initial_states, ::boost::msm::wrap<mpl::placeholders::_1> > (init_states(m_states)); m_history.set_initial_states(m_states); fill_states(this); } In our case, if we want to pass a reference, ARG0 has to be declared as follows: template < class ARG0> state_machine<Derived,HistoryPolicy,CompilePolicy >( ARG0& t0 ) :Derived( t0) .... The "Derived" class looks like as follows: class "Derived" { public: Derived(SomeClass& cl_) {} } Do you have any idea how to solve this? Thanks in advance. Richie & Michi

1 0

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