April 2009 - Boost-users - lists.preview.boost.org

[Asio] Version correspondence?
by Rush Manbert 01 Apr '09

01 Apr '09

I'm trying to figure out which standalone Asio library versions correspond to the Boost library versions for: 1.35.0 1.36.0 1.37.0 1.38.0 Is it possible to discover this from the header files? Is there some other way? I'm adding Asio-based classes to an existing library. I think I want to try and implement them using the version that was in Boost 1.35.0, but I would like to give library users the option to use the Boost Asio or the corresponding stand-alone Asio. I expect some users would appreciate that. That's why I need to know what standalone Asio version to get. - Rush

1 0

[Graph] Checking if a vertex_descriptor is valid
by Florian.PONROY＠fr.thalesgroup.com 01 Apr '09

01 Apr '09

Hi, I want to check if a vertex_descriptor is valid before using it. As I saw on this list, I perform the following test : Graph_t graph(10); vertexDescriptor srcVertex = boost::vertex(424242, graph); if (Graph_t::null_vertex() == boost::vertex(424242, graph)) { return; } Obviously, vertex indice 424242 does not exist, but test fails, and function does not return, leading the a crash of the following algorithm (BFS or Dijkstra). What did I do wrong? Thanks for your help. -- Florian PONROY Thales Land & Joint France Tel. : +33(0)1 41 304 363 Fax : +33(0)1 41 303 560 Email : florian.ponroy(a)fr.thalesgroup.com

3 2

[interprocess] access dynamically accessed shared region in another process
by Stephan Menzel 01 Apr '09

01 Apr '09

Hi there, I'm trying to do IPC via boost.interprocess and use a dynamic buffer. This is on windows, debug mt, boost 1.38. To do this, I first create a shared segment and then a dynamic area in it. like this: struct transfer_buffer { void *buf; size_t bufsize; boost::interprocess::interprocess_mutex mutex; size_t dmember; } typedef boost::interprocess::managed_windows_shared_memory shared_segment; ... using namespace boost::interprocess; shared_memory_object::remove(bufname); struct transfer_buffer *ret = 0; shared_segment_ptr seg;// I use a ptr to store the object away so it won't get lost seg.reset(new shared_segment(create_only, bufname, begin_size)); // and our maintanance struct in it ret = seg->construct<struct transfer_buffer>(unique_instance)(); ret->dmember = 42; const std::size_t Alignment = 128; ret->bufsize = 1982781; ret->buf = seg->allocate_aligned(ret->bufsize, Alignment); Then, process A writes into the dynamic buffer, which seems to work OK. In the other process however, I try to open it and read the data. Like this: seg.reset(new shared_segment(open_only, bufname)); ret = seg->find<struct transfer_buffer>(unique_instance).first; Now I can access everything fine in ret (the struct itself), including the mutex and data members. But I cannot access the dynamically allocated buffer. As soon as I access it (read it, memcpy, anything) the app crashes with what would appear to be a rather broken callstack. When I look at the transfer_buffer struct before the crash it looks as if the dynamic pointer points to some inaccessable area. Not what I wrote in it anyway. Do I have to do anything else (other than creating the segment and find() the unique transfer_buffer struct) in the other process to access the dynamic area? Or is this a bug? Any help appreciated... Stephan

3 5

boost::array < pair<>... > iterator adaptor
by Hicham Mouline 01 Apr '09

01 Apr '09

Hello, I have a boost::array< pair<type1, type2>, maxsize > object, and I wish to iterate over the list of type1 elements, and the list of type2 elements... I gather I then need an iterator adaptor based on array's iterator and const_iterators... How may I write such a thing? I then can pass around iterators to type1 and type2 separately. regards,

2 1

move() aware containers?
by Noah Roberts 01 Apr '09

01 Apr '09

I'm reading a pre-release of a book on C++0x threading. I'm using the boost::thread library since it's supposed to be pretty close. Now they're using std::vector<> though and I know it's not move ready. Is there a boost container I can mimic this with?

2 2

boost exception tutorial
by Robert Ramey 01 Apr '09

01 Apr '09

I'm investigating boost exception to see if it is helpful in a particular instance. I start by looking at the first Tutorial. I can't see how this is better than struc my_error : public std::exception { int m_ errno; my_error(int errno) : m_errno(errno) {} }; ... throw my_error(errno) try { ... } catch(my_error e){ cerr << e; } What am I missing here? This first example is two compilicated in that it requires that I delve into a bunch of other stuff (operator << for exception data?) and it doesn't provide any motivation. I think it would be more useful if it "spoon fed" the reader (me in this case) a little more. Something like: Traditional simple example like that above. explanation of why the example isn't "good enough" simple example reformulated using boost exception explanation of how this addresses the short comings of the original version. I think this would motivate more users to transition to the library. Robert Ramey

5 7

Re: [Boost-users] [statechart] state behaviour
by Andreas Huber 01 Apr '09

01 Apr '09

> So, if I post an event and then execute "template< class > DestinationState > result transit();" in custom reaction this > destination state will be given posted event. Am I right? Yep. Regards, -- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.

1 0

Re: [Boost-users] statechart comparison
by Andreas Huber 01 Apr '09

01 Apr '09

Hi Brent > Is it still the case that boost statecharts require allocation and > destruction of a state object when entering and exiting that state? More precisely, the library issues "new State" upon state entry & and "delete State" upon state exit. So state construction & destruction *are* required but calls to global operator new and delete are not. The latter can be avoided by replacing operator new for your states or, on a more general level by passing a custom allocator to the state machine. Boost.Statechart was designed for reactive systems, where state machines are often serviced by dedicated threads. In such a scenario, the inter-thread communication usually introduces a much higher overhead than state construction & destruction. Regards, -- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.

1 0

Re: [Boost-users] boost.statechart - a data driven state machine
by Andreas Huber 01 Apr '09

01 Apr '09

[snip] > I'd like this state machine to be completely data driven because it will > massively simplify testing and experimenting with different behaviours (ie. > I won't have to re-compile and produce new executables to try out a simple change). > > Instead of hard-coding all the states, events, transitions, etc., I would like > to read all those in from a config file (text, csv, xml, whatever). Boost.Statechart deliberately does not support dynamic configurability. The rationale can be found here: <http://www.boost.org/doc/libs/1_38_0/libs/statechart/doc/rationale.html#Dyn…> Regards, -- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.

1 0

mpl::for_each state
by Skelly, Luke 01 Apr '09

01 Apr '09

Please ignore my last message. I somehow accidentally sent it while still editing! I am trying to create a std::map from an mpl::map. I've been trying to figure out how to use mpl::for_each to accomplish this. The problem I have is that the runtime function is passed to for_each by value and returns void. All the examples I've seen for mpl::for_each involve printing and not creating any new objects. Here is the attempt I've made: // creates std::map<size_t,size_t> from mpl::map<size_t,size_t> template<typename TypeMap> struct MapMaker { typedef std::map<size_t, size_t> map_type; map_type func_map; MapMaker() { boost::mpl::for_each<TypeMap>(*this); } template<typename U> void operator()(U x) { func_map[U::first::value]=U::second::value; } func_type operator[](size_t i) { return func_map[i]; } }; typedef boost::mpl::map< boost::mpl::pair<boost::mpl::size_t<1>, boost::mpl::size_t<2> >, boost::mpl::pair<boost::mpl::size_t<2>, boost::mpl::size_t<24> >, > myMap; int main() { MapMaker<myMap> m; size_t result = m[1]; } Of course this is a simplified version of what I'm really trying to do, which is create a map to function pointers. The problem is in the call to mpl::for_each in the MapMaker constructor. The std::map is created, but never returned. I've considered making func_map static, but that complicates things quite a bit, especially since MapMaker it is a class template. Luke Skelly

2 2