June 2010 - Boost - lists.boost.org

Maintaining boost.org
by Dean Michael Berris 03 Jun '10

03 Jun '10

Good day everyone! If you were at the BoostCon 2010 panel session, I suggested that maintaining boost.org can be a less painful process and that I was willing to help out in transitioning the current site from the way it is currently set up to maybe use Wordpress to host the site. There are other options that I would like to explore only after looking at many different tools and the current process of maintaining it. I tried sending mail to the Boost-docs list but I haven't gotten any responses yet so I chose to send another email to the developers mailing list. There are a couple of questions I would like to ask and would really appreciated getting an answer about: 1. Is there currently a boost.org web team? If so, who are in the team? 2. What is the current process of building the boost.org site? What is the toolchain used and how are changes managed? Before I go into the detail of a proposal of making boost.org a little more "interactive" and "inclusive" I would first like to know the state of the system and whether there are any low hanging fruit that can be taken care of before I even suggest changing it. FWIW, I volunteer to help manage boost.org to make it more inviting to the community and more dynamic than it currently is. Although the boost.org website does host the web-based library documentation, I would like to be able to see more information on it about the community, the process, and news on what's going on. Pending a "full" proposal I would definitely appreciate thoughts about the matter too. -- Dean Michael Berris deanberris.com

12 40

Re: [boost] [msm] Passing constructor arguments to submachine
by Christophe Henry 03 Jun '10

03 Jun '10

>> > Is it also possible to pass constructor arguments to submachines of a msm >> > state machine? >> >> Unfortunately, not yet. There was a proposal made during the review to >> allow states (including submachines) to be cloned from an existing >> one, but it is not implemented yet. > > The Parameter library can sometimes be used to make this sort of thing > work nicely. See Boost.Accumulators, for example. I didn't think about Parameter and I like the idea (I also see somewhere else where it could be useful) but I : (a) don't have any parameter name to give to BOOST_PARAMETER_NAME (parameters being simply forwarded with BOOST_PP_ENUM_PARAMS) (b) don't know at preprocessor time in BOOST_PARAMETER_CONSTRUCTOR how many parameters the user will pass through the back-end to the front-end constructor or how many submachines/substates will be default-constructed by user's choice. Concretely, the user can now do something like: player p(/* for the front-end*/ 3, "a"); And adding states for copy-construction could look like: player p(/* for the front-end*/ 3, "a", /* some states copy-constructed*/ Paused("something") , Playing("more data") ); Of course I could provide some default names and create more constructor overloads with BOOST_PP_ENUM_PARAMS. I was actually thinking of using a proto expression like: player p( (/* data for front-end*/params_ << 3 << "a" ), (/* some states copy-constructed*/ states_ << Paused("something") << Playing("more data") )); But I admit having not spent enough thinking time yet so I will look into it again. Thanks for the idea, Dave. It will in any case be pretty cool to use Parameter to make back-end policies nicer. Christophe

2 1

[boost::endian] Request for comments/interest
by Tomas Puverle 02 Jun '10

02 Jun '10

I wrote an endian library on the flight back from boostcon but it has taken a little time to clear the submission with the firm. I realize that Beman's endian swapper library is already in the review queue but I hope my approach is different and interesting enough to warrant consideration. It's located here in the vault (Utilities/endian-puverle.zip): http://www.boostpro.com/vault/index.php?action=downloadfile&filename=endian… The highlights of the library are the following: - Very simple interface: swap<machine_to_little/big>(), swap_in_place<machine_to_little/big>() - Support for built-in and user-defined data types and ranges thereof. E.g. you can swap ranges of structs containing/deriving from other structs - endian::iterator, which will iterate across a range swapping values as necessary. It works with any swappable type. The library is described/documented/tested in the file main.cpp at the root of the zip archive. Unfinished items: - Right now, the library only includes the "vanilla" swapper, meaning it doesn't take advantage of special instructions on architectures which natively support endian conversion. I didn't include this in order to prevent cluttering the code with #ifdefs. This functionality would, however, be part of the final library. - Ideally, the metafunction is_mutable_range<> should be moved out of endian::detail and become part of Boost.Range of Boost.TypeTraits. I have donned by bulletproof vest and I'm ready for any feedback you may have. :) Tom

15 55

[gil] how does dereference_iterator_adaptor defines it's iterator category?
by Christian Henning 02 Jun '10

02 Jun '10

Hi all, I'm still investigating compilation errors with my gil extension while compiling on MSVC10. I have exchanged boost::random_access_traversal_tag with std::random_access_iterator_tag with all gil iterator types. This solved some of my problems. Some still remain. Here is what I have discovered. When using a boost::gil::kth_channel_view_type with bit_aligned image types I'm running into the same problem I had with just using bit_aligned image types. Now kth_channel_view_type uses a boost::gil::dereference_iterator_adaptor for iteration purposes. This adaptor defines it's iterator category as boost::detail::iterator_category_with_traversal<std::input_iterator_tag,boost::random_access_traversal_tag> which is wrong. I have been trying to figure out where this definition is coming from. But I'm not able to. All occurrences of random_access_traversal_tag have been removed from gil code. Which leads me to believe it's coming from boost itself somewhere. Here is some code displaying the problem. #include <vector> #include <algorithm> #include <boost/gil/gil_all.hpp> using namespace std; using namespace boost; using namespace boost::gil; int main(int argc, char* argv[]) { typedef bit_aligned_image1_type< 1, gray_layout_t >::type image_t; typedef image_t::view_t view_t; typedef view_t::x_iterator view_it_t; typedef view_it_t::iterator_category view_cat_t; // it's std::random_access_iterator_tag view_cat_t view_cat; typedef kth_channel_view_type< 0, view_t >::type plane_t; typedef plane_t::x_iterator plane_it_t; typedef plane_it_t::iterator_category plane_cat_t; // it's boost::detail::iterator_category_with_traversal<std::input_iterator_tag,boost::random_access_traversal_tag> plane_cat_t plane_cat; return 0; } Regards, Christian

2 3

Re: [boost] [msm] Passing constructor arguments to submachine
by Christophe Henry 01 Jun '10

01 Jun '10

Hi Michael, > As already explained in another thread, it is possible to pass constructor > arguments to msm state machines (to the front end). > > Is it also possible to pass constructor arguments to submachines of a msm > state machine? Unfortunately, not yet. There was a proposal made during the review to allow states (including submachines) to be cloned from an existing one, but it is not implemented yet. > Or is there an other way in order to configure the inner submachine by > calling some member methods from the outer state machine or therelike? You can call get_state<my_submachine&>() on the outer fsm (at best in the entry behavior). For example: struct Playing_ : public msm::front::state_machine_def<Playing_> { template <class Event,class Fsm> void on_entry(Event const&,Fsm& fsm) { fsm.get_state<my_submachine&>() .foo(); } ... }; HTH, Christophe

2 1

boost.log
by Dirk Griffioen 01 Jun '10

01 Jun '10

Thanks! It now works fine with filters. Best, Dirk

1 0

[gil] Is bit_aligned_pixel_iterator a standard conformant random access iterator?
by Christian Henning 01 Jun '10

01 Jun '10

Hi there, I'm having an interesting discussion over at the MSDN forums regarding compiler errors with MSVC10 that show up when using standard algorithms and bit_aligned images. Basically the question is why MSVC10 doesn't understand that bit_aligned_pixel_iterator is a random access iterator. For some reasons it thinks it's an input iterator and though std::copy, in this case, cannot find the correct copy implementation. One of the folks over at MSDN thinks that bit_aligned_pixel_iterator isn't implemented correctly with the interator_facade. He/She also thinks that iterator isn't fully standard compliant since it doesn't give a real reference but a proxy object instead when deferencing. I'm not sure if that's correct. Anyone knows if that's true or not. Here is the full text: http://social.msdn.microsoft.com/Forums/en-US/vcgeneral/thread/3c9eac4f-86e… In any event it seems I need to do some adjustment in the the gil code to have it working with my gil io extension and MSVC10. Right now I have the compiler errors all over my test suite. Regards, Christian

4 8

[msm] Passing constructor arguments to submachine
by Michael.Herchel＠rohde-schwarz.com 01 Jun '10

01 Jun '10

Hi, As already explained in another thread, it is possible to pass constructor arguments to msm state machines (to the front end). Is it also possible to pass constructor arguments to submachines of a msm state machine? Or is there an other way in order to configure the inner submachine by calling some member methods from the outer state machine or therelike? Thanks, mikee

1 0