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

Boost.Interprocess containers question
by Davidson, Josh 02 Mar '12

02 Mar '12

I have an object that I'm storing in shared memory that contains a map data member whose values are lists. The processes that interact with this object don't have direct access to the map data structure. Instead, the object is accessed and modified through its public interface. The issue I am running into is how to handle new key, value insertions. I would prefer to leave the fact that the object is in shared memory an implementation detail, but in order to construct a new list to insert in the map, the list needs to be initialized with an allocator using the segment manger. Unless I pass that segment manager into every method that might add a new list to the map, I'm struggling how to get it working. I can't simply store a pointer to the managed shared memory or segment manager within the class since the address would only be valid in the process that constructed it. The only possible implementations I can think of would be to require passing in the segment manager into all of the methods and then create a simple wrapper class that contains a pointer to this object along with a pointer to the segment manager. The wrapper class would essentially "duplicate" each of the methods in the wrapped class but drop the segement manager parameter since it has it as a member. Processes that "find" this object in shared memory would then be responsible for wrapping it in an object of the wrapper class. The other possible implementation would be to always open the shared memory segment by name before modifying the map. Josh

3 3

Re: [Boost-users] Interprocess container segmentation fault (example provided)
by Davidson, Josh 02 Mar '12

02 Mar '12

> Ion, > Terribly sorry, but I goofed when I cobbled that code together. My actual application constructs "TestStore" from the segment, and not on the stack like what I pasted in before. I'm including the full test code again, although only the main function changed. Since the map itself a member of TestStore and TestStore is being constructed from the segment, I would think that should be roughly equivalent to just creating the map by itself from the segment. However, as you'll see if you run it, it still seg faults when accessing the list iterator. Ok, I had to re-read your message again before it sunk in. While allocating the TestStore on the stack was an obvious issue, I understand now why it still blew up when iterating the list. Also, it looks like I was further complicating things. It appears from my testing that I can store allocator instances in the shared memory segment (e.g. a ListAllocator in TestStore from earlier example) and just use that in addMessage rather than creating a new allocator each time I insert into the map. Thanks, Josh

1 0

[interprocess::offset_ptr] operator>> error in boost_1_46_1
by 乔志强 02 Mar '12

02 Mar '12

#include <boost/interprocess/offset_ptr.hpp> I use boost_1_46_1, boost::interprocess::offset_ptr<int> p; std::cin >> p; // error!! offset_ptr.hpp std::ptrdiff_t get_offset() const { return internal.m_offset; } //!operator>> //!for offset ptr template<class E, class T, class Y> inline std::basic_istream<E, T> & operator>> (std::basic_istream<E, T> & is, offset_ptr<Y> & p) { return is >> p.get_offset(); }

1 0

Is there a self contained vector-like container?
by Frank Birbacher 01 Mar '12

01 Mar '12

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi! Is there in Boost a container that is statically "max sized" and contains its own storage like a std::array, but manages a size and can construct and destruct elements. I guess it would look something like: template<typedef T, size_t N> struct self_contained_vector { size_t max_size() const { return N; } size_t size() const { return size_; } private: size_t size_; aligned_storage<T> data_[N]; //...implement random access container... }; Frank -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: keyserver x-hkp://pool.sks-keyservers.net iEYEARECAAYFAk9P2GcACgkQhAOUmAZhnmqtdACfa6D7j8THF2UtGvTSSHERbffe i6UAn2d+bW1jREGupp1wPMVafXiKQpOm =mwRW -----END PGP SIGNATURE-----

4 7

Iterating over the output of a member function in std::for_each
by Andrew Hundt 01 Mar '12

01 Mar '12

I have a class with an accessor member function that I want to call and apply the result to a functor using std::for_each. I have a working version below that uses a for loop and for_each, but the for_each version is cryptic and cumbersome. Is there a way I can make the for_each version more concise? #if 0 // for loop version: for(value_vector_type::iterator it = values.begin(); it!=values.end(); it++){ avg(it->getValue()); // I want to put this in a for_each loop } #else // bind version: std::for_each(values.begin(), values.end(), // iterate over all values boost::bind( boost::mem_fn(&average_type::operator()), // attach the averaging functor to the output of the getvalue call &avg, boost::bind( boost::mem_fn(&value_wrapper_type::getValue), // bind the getValue call to each element in values _1 ) ) ); #endif I also have the question posted in stack overflow, with a full implementation: http://stackoverflow.com/questions/9507830/iterating-over-the-output-of-a-m… Cheers! Andrew Hundt

2 3

Graph: writing graph properties to graphml file
by Juerg Tschirren 01 Mar '12

01 Mar '12

I wrote the code below to construct a directed graph with internal properties (for vertices, edges, and the graph itself) and write everything to a graphml file. The code compiles and works as it is, but my two questions are: 1. What dynamic property do I have to add to write the graph properties out to the graphml file as well? So far I could only figure out how to write vertex and edge properties. 2. Does everything else look good? Specifically, is it O.K. to define the properties the way I did in the first typedef line (without using boost::property<>), and is it O.K. to access the properties the way I do it? Juerg //--- start of example code typedef boost::adjacency_list<boost::listS, boost::vecS, boost::directedS, std::string, std::string, std::string> Graph; typedef boost::graph_traits<Graph>::vertex_descriptor vertex_t; typedef boost::graph_traits<Graph>::edge_descriptor edge_t; Graph g; vertex_t u = boost::add_vertex(g); vertex_t v = boost::add_vertex(g); edge_t e; bool b; boost::tie(e,b) = boost::add_edge(u,v,g); g[u] = "a_vertex_name"; g[v] = "an_other_vertex_name"; g[e] = "an_edge_name"; boost::get_property(g) = "the_graph"; boost::dynamic_properties dp; dp.property("vertex_data", boost::get(boost::vertex_bundle, g)); dp.property("edge_data", boost::get(boost::edge_bundle, g)); std::ofstream graphmlOutFile("graph.xml"); boost::write_graphml(graphmlOutFile, g, dp, true); graphmlOutFile.close();

2 1

Interprocess container segmentation fault (example provided)
by Davidson, Josh 01 Mar '12

01 Mar '12

I'm running into issues with using interprocess containers have other containers added to them during runtime. A very high level description is I have a set of data structures in shared memory that can be accessed and modified by more than one process. I'm creating the data structures in the first process and storing the name of the segment within the data structure. Methods that modify the data by adding another container first lookup the segment using its name, build the new container, and then insert it into the existing container. In the example I'm providing below, I have a map of lists. For some reason, when I add a new list, if I open the segment by name, and allocate the list using the segment manager returned via the lookup, the list isn't initialized correctly and accessing the list (via printData here) results in a segfault. However, if I bypass the segment lookup and just cache the raw pointer to the segment, it works. It's probably easiest just to look at the code below. In addMessage, you can see how I'm trying to initialize the list in a manner that will work across multiple processes. This breaks. Commented out directly below it is a hack that will work. I can't see any reason why one works and the other doesn't. The "managed_shared_memory" object returned from the lookup appears to be valid and exactly the same as the pointer I'm caching with the data structure in this example. I am currently using 1.49 final, but I've observed similar behavior in other 1.4x releases. =================================BEGIN CODE==================================================== #include <stdint.h> #include <cstddef> #include <string> #include <functional> #include <iostream> #include <utility> using std::cerr; using std::endl; using std::pair; #include <boost/interprocess/managed_shared_memory.hpp> #include <boost/interprocess/allocators/allocator.hpp> #include <boost/interprocess/offset_ptr.hpp> #include <boost/interprocess/containers/string.hpp> #include <boost/interprocess/containers/list.hpp> #include <boost/interprocess/containers/map.hpp> #include <boost/ref.hpp> using namespace boost::interprocess; class SharedMemoryDeleter { public: SharedMemoryDeleter(const std::string& name) : mName(name) { shared_memory_object::remove(mName.c_str()); } ~SharedMemoryDeleter() { shared_memory_object::remove(mName.c_str()); } protected: std::string mName; }; class TestStore { public: struct TestData { uint16_t commandStatus; size_t wordCount; uint16_t data[32]; }; ///Allocates characters in shared memory typedef allocator<char, managed_shared_memory::segment_manager> CharAllocator; ///String in shared memory typedef basic_string<char, std::char_traits<char>, CharAllocator> SharedMemoryString; ///Allocates list in shared memory typedef allocator<TestData, managed_shared_memory::segment_manager> ListAllocator; ///List of TestData items in shared memory typedef list<TestData, ListAllocator> SharedMemoryList; ///Key/Value pair for the map (SA, Data List) typedef pair<const unsigned, SharedMemoryList> data_map_value_t; ///Allocates maps in shared memory typedef allocator<data_map_value_t, managed_shared_memory::segment_manager> MapAllocator; ///Maps lists to SAs in shared memory typedef map<unsigned, SharedMemoryList, std::less<unsigned>, MapAllocator> SharedMemoryMap; TestStore(managed_shared_memory& segment, const std::string& name) : mSegment(&segment), mSegmentName(name.c_str(), CharAllocator(mSegment->get_segment_manager())), mData(std::less<unsigned>(), MapAllocator(mSegment->get_segment_manager())){ } /////////////////////////////////////////////////////////////////////////// /// Destructor /////////////////////////////////////////////////////////////////////////// virtual ~TestStore() { } void printData() { TestStore::SharedMemoryMap::iterator it = mData.begin(); while(it != mData.end()) { TestStore::SharedMemoryList::iterator lIt = it->second.begin(); cerr << "SA: " << it->first << endl; cerr << it->second.size() << endl; while (lIt != it->second.end()) { cerr << "\titerating..." << endl; cerr << "wc: " << lIt->wordCount << endl; cerr << "cs: " << lIt->commandStatus << endl; cerr << "\t" << lIt->commandStatus << ", WC: " << lIt->wordCount << endl; ++lIt; } ++it; } cerr << endl; } bool addMessage(unsigned key, const TestData& data) { TestStore::SharedMemoryMap::iterator it = mData.find(key); cerr << "Adding word count " << data.wordCount << endl; if(it != mData.end()) { it->second.push_back(data); } else { cerr << "Looking for " << mSegmentName.c_str() << endl; managed_shared_memory m(open_only, mSegmentName.c_str()); cerr << "found it" << endl; cerr << m.check_sanity() << " - " << m.get_free_memory() << "/" << m.get_size() << endl; cerr << mSegment->check_sanity() << " * " << mSegment->get_free_memory() << "/" << mSegment->get_size() << endl; ///!!!!!!!!!!!!!!!BROKE!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! TestStore::SharedMemoryList sList(TestStore::ListAllocator( m.get_segment_manager())); //==========This Works (obviously only for current process)=========== // TestStore::SharedMemoryList sList(TestStore::ListAllocator( // mSegment->get_segment_manager())); sList.push_back(data); cerr << "pushed" << endl; cerr << sList.front().wordCount << endl; mData.insert(TestStore::SharedMemoryMap::value_type(key, sList)); cerr << "added list" << endl; } cerr << "====================Data post add===================" << endl; printData(); return true; } private: ///Segment housing this class. Only valid in the constructing process managed_shared_memory* mSegment; ///Name of the segment SharedMemoryString mSegmentName; SharedMemoryMap mData; }; int main() { std::string name = "MemHere"; int num_bytes = 645360; SharedMemoryDeleter deleter(name); managed_shared_memory shm(open_or_create, name.c_str(), num_bytes); TestStore store(shm, name); TestStore::TestData data; data.commandStatus = 10; data.wordCount = 14; store.addMessage(3, data); return 0; }

2 1

variant iterator, operators and enable_if
by MM 01 Mar '12

01 Mar '12

Hi, I have a variant iterator, ie an iterator that is associated with a variant, this variant is over a list of different iterators types. The variant object holds at any time 1 of the possible iterators. The variant iterator class attempts to implement the Iterator concept of c++1x. I am trying to declare and then define the various possible versions of operator== for instance. I have declared: bool operator==( const variant_iterator& lhs, const variant_iterator& rhs ); so far so good. I also want to allow == between the variant_iterator and any of the iterator types the variant type contains. So I am writing a: template <typename contained_iter_t> bool operator==(const variant_iterator& lhs, const contained_iter_t& rhs ); 1. Will the non templated version of operator== always take precedence over the templated one when in the same namespace/scope? 2. Do I need to disable the templated version when contained_iter_t happens to be variant_iterator ? 3. I want to allow comparison with both the straight and reverse versions of the iterator types in the variant. I have set a mpl container of iterators, made a variant off that container, then I use enable_if to check if the "contained_iterator" is part of the mpl container for Iterators, in which case I implement == with a == between the bound type and the iterator, otherwise between the bounded type and the base of the reverse iterator. all the enable_if are used as the return type for the operator== there are 4 versions: lhs==rhs and rhs==lhs for Iterator and reverse_iterator Comments and suggestions on the idea are appreciated, MM

1 0

XML Output
by Jake 01 Mar '12

01 Mar '12

Hey I'm pretty new to boost, but have successfully implemented it into a large program. I currently have the tests being run and having them output to a detailed xml file. I'm then parsing this file with python and am going to make a simple GUI interface for it. However, I just realized that the XML doesn't include the failure if there is one, and it instead prints it to command prompt. Is there a way to include it in the XML? All I want to see is the assertion that failed and what the result is. Is there another program I could have used this whole time that does this same thing? Thank you! p.s. I was trying to make it similar to nunit

1 0

zip_iterator.hpp / boost::tuple requires a using namespace std!
by mark pashley 01 Mar '12

01 Mar '12

Hi, I have been using zip iterators with a BOOST::Test to check that maps contain expected values. After moving some templated code to a header file I found that the code would not compie unless I place a *'using namespace std;' * declaration within one of functions. The compiler is gcc 4.6.2 and 4.4.2. The version of boost is 1.47 and 1.49 The minimum code snippet is as follows: * using namespace std; // without this the next line does not compile!* The error from gcc is: -- View this message in context: http://boost.2283326.n4.nabble.com/zip-iterator-hpp-boost-tuple-requires-a-… Sent from the Boost - Users mailing list archive at Nabble.com.

4 7