- Boost - lists.boost.org

Status of Boost.Atomic?
by Sean Chittenden 03 Jun '10

03 Jun '10

What's the status of Boost.Atomic? http://www.chaoticmind.net/~hcb/projects/boost.atomic/ This looks like some very interesting code that would be of interest to a number of boost users (besides, it would be nice to stop abusing boost/interprocess/detail/atomic.hpp). Thanks in advance for any light that can be shed on this. -sc -- Sean Chittenden sean(a)chittenden.org

1 0

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

03 Jun '10

>> 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. > > Please take a close look at Boost.Accumulator; it has to solve > essentially the same problem IIUC, and it does so quite nicely. You > can't use the high-level macros like BOOST_PARAMETER_CONSTRUCTOR in > the template that has to do the forwarding, though. I think it might > even improve readability to do make your life easy and accept a single > argument pack (backend_args in the example below) for forwarding to > submachines > > player p(/* for the front-end*/ 3, "a", > backend_args = ( > init1=Paused("something"), > init2=Playing("more data")) > ); > > or something like that. I like this syntax too. Ok then I will give it a try and have a closer look at Accumulator. Thanks!

1 0

Re: [boost] [boost::endian] Request for comments/interest
by Dave Handley 03 Jun '10

03 Jun '10

I wanted to throw a few things into the discussion: 1) Typed vs untyped. We have had various discussions about whether the network endian object should be a different type to the machine endian. I have a pretty strong opinion on this, and I think you should work with the same type. There are 2 core reasons for this: a. Performance when network endian is the same as machine endian - I'll discuss more on this later. b. When you are reading a complex packet of data off the network, a common use case would be to reinterpret_cast a block of data into a struct. When you are using different types for network and machine endian you end up having 2 structs - one to read the data off the network, and one to copy the data into. This could turn into a pretty severe maintenance burden. c. Given that you tend to convert to machine endian at the boundaries, you can treat the untyped interface in a very similar way to a boost::shared_ptr style interface. You call swap_in_place on the return value from the function that creates the initial struct - and therefore you never have access to the network endian version in anything except your most basic read function. As such, I think the type safety of network endian data is a bit of a red herring. It is no different from creating a raw pointer, then half a dozen lines of code later constructing a boost::shared_ptr from it. It is against the principle of the interface, and would create some evil bugs, but hasn't been formally prohibited by the interface. d. Finally, I would definitely want an endian interface that operated at a high level of abstraction - ie at the struct or container level, not at the built-in type level. 2) To copy or not to copy. I have a very big issue with any interface that enforces a copy. If I'm writing something to live on a memory limited embedded device, I absolutely want to be able to endian swap in place. Secondly, we should definitely not accept an interface that copies just on the grounds that the most common operation is from a big endian network to a little endian machine that does always require mutation. The platforms that boost runs on includes plenty of big-endian machine types; and I have come across numerous cases where (for performance reasons on a largely little endian machine environment) data has been left little-endian on the network. Having a do nothing (not even copy) case for when machine and network endianness match is very important. If you are reading a big stream of data from the network, not copying anything is a very important case, and key for writing high performance production code. 3) A final thought is that I am much more keen to use template arguments to decide on which endian swap to use than explicitly coding them in function template names. It makes endian swapping code in a big code base easier to spot, and makes the interface of the endian swapper itself more logical. When I change from big to little endian, I am tweaking a parameter of the endian swapper, not calling a wholly different function. I think from a design perspective, a template parameter makes most sense. Overall, I like Tom's interface, but I have been using it for quite a while (as a disclaimer). Dave

10 57

Mutexes claim a Windows event handle
by Peters, Richard 03 Jun '10

03 Jun '10

Hi! I have a problem with boost::recursive_mutex "sometimes" keeping a handle to a Windows Event. My application uses a lot of objects, each containing a recursive_mutex. The objects are accessed from different threads using a scoped_lock (see code below). In Boost 1.34 there was no problem, but after we switched to 1.39 it seems that the process collects more and more handles to Windows Events. Only when the objects that contain the recursive_mutex are destroyed, the handles are released again. The problem is that I must support 100,000 objects containg multiple mutexes, so if each mutex can cost one handle the total number of handles in use may become huge. I tried the latest Boost version (1.43) but that makes no difference. The strange thing is that not every object keeps a handle, i.e.: the number of handles collected is less than the number of objects created. When increasing the nrActions the number of handles collected comes closer to the number of objects. I could understand if a recursive_mutex costs a handle, except that in boost 1.34 they didn't so I wonder if this was an accident or a deliberate change. And most important: Is there a way to get the same behavior as in 1.34 where a mutex did not cost me one handle each? Thanks for your advice! Code example: #include <list> #include <boost/bind.hpp> #include <boost/thread.hpp> #include <boost/thread/recursive_mutex.hpp> #include <boost/enable_shared_from_this.hpp> class ActiveObject : public boost::enable_shared_from_this<ActiveObject> { private: boost::recursive_mutex mActionLock; void action() { boost::recursive_mutex::scoped_lock asyncLock(mActionLock); } public: void startAction() { boost::recursive_mutex::scoped_lock syncLock(mActionLock); boost::thread th(boost::bind(&ActiveObject::action, shared_from_this())); } }; int main() { { std::list< boost::shared_ptr<ActiveObject> > jobList; for (int nrObjects = 0; nrObjects < 1000; ++nrObjects) { boost::shared_ptr<ActiveObject> pActiveObject( new ActiveObject() ); jobList.push_back(pActiveObject); for (int nrActions = 0; nrActions < 3; ++nrActions) { pActiveObject->startAction(); } } // At this point, a lot of handles are in use. } // Here, the handles are released again. exit(0); } This message and attachment(s) are intended solely for use by the addressee and may contain information that is privileged, confidential or otherwise exempt from disclosure under applicable law. If you are not the intended recipient or agent thereof responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by telephone and with a 'reply' message. Thank you for your co-operation.

5 9

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 02 Jun '10

02 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 01 Jun '10

01 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 01 Jun '10

01 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