March 2012 - Boost-users - lists.boost.org

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

embedding
by Andreas Fabri 01 Mar '12

01 Mar '12

Hello I am wondering if there is ongoing work around the notion of embeddings of the Boost Graph Library. In the CGAL project which deals with geometric data structures we have written specializations of the graph_traits for the polyhedral surface, the halfedge datastructure, 2D triangulations, and arrangements. This allows to run BGL algorithms directly on CGAL data structures. http://www.cgal.org/Pkg/BGL. As these graphs are always embedded, that is as there is a circular order of edges we introduced a HalfedgeGraph concept http://www.cgal.org/Manual/latest/doc_html/cgal_manual/BGL_ref/Concept_Half… where one has global functions in order to walk along the border of a face, and go from an outgoing edge via the opposite incoming edge to a neighbor face. Would any of these ideas be interesting for the maintainers of the BGL. best regards, andreas -- Andreas Fabri, PhD Chief Officer, GeometryFactory Editor, The CGAL Project phone: +33.492.954.912 skype: andreas.fabri

3 2

Type deduction
by Robert Jones 01 Mar '12

01 Mar '12

Is there anything in Boost to help with the type deduction of simple arithmetic expressions? Essentially a C++03 version of template <typename T, typename U> struct deduce { typedef decltype( T / U ) type; }; (I know that wasn't valid code, it's just for exposition) Thx, - Rob.

1 1