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

lockfree::spsc_queue & move semantics
by Thomas Danckaert 10 Nov '14

10 Nov '14

I'd like to use a spsc_queue of unique_ptr's to bigger objects, to transfer ownership between threads. That way, I can create/allocate an object in a non-realtime thread, then transfer ownership to a realtime thread using a lockfree queue, and, using another queue, pass on the unique_ptr to another thread that takes care of cleanup when the realtime thread no longer needs the it. For example: boost::lockfree::spsc_queue<unique_ptr<string>, boost::lockfree::capacity<10> > cb; Unfortunately, spsc_queue does not use move semantics (methods to push onto the queue take parameters as const reference and construct a copy in the queues internal storage), so i can not cb.push() a unique_ptr<string> onto my queue. Is it reasonable to want to add this, and if so, what would be the best place to submit a request? (I managed to get a simple example working by adding rvalue reference overrides of the queue's push() methods, and using std::move in the pop() method) bool push(T && t) { }; Also, I noticed that the destructor for the spsc_queue (with size fixed at compile-time) does not run destructors for it's contents. What could be the reason for this? Thomas

2 1

[scope_exit] 1.57 MSVC C4003 warning
by Filip Konvička 10 Nov '14

10 Nov '14

Hi, Any use of BOOST_SCOPE_EXIT in 1.57 seems to emit warning C4003 on MSVC 2012 and 2013: warning C4003: not enough actual parameters for macro 'BOOST_PP_EXPAND_I' Uncomment either line to suppress the warning. Is BOOST_PP_VARIADICS enabled by mistake for MSVC (especially 2013)? Should I explicitly set BOOST_PP_VARIADICS=0 for MSVC? Despite the warning, the code appears to work fine (i.e., the block of code gets properly called). Thanks, Filip #include <boost/version.hpp> #if defined(_MSC_VER) && BOOST_VERSION==105700 //#pragma warning(disable:4003) //#define BOOST_PP_VARIADICS 0 #endif #include <boost/scope_exit.hpp> #include <iostream> int main(int argc, char* argv[]) { int x=0; BOOST_SCOPE_EXIT((x)) { std::cout << "here " << x << std::endl; } BOOST_SCOPE_EXIT_END return 0; }

3 5

boost property tree for recursive structures
by Maurizio Vitale 10 Nov '14

10 Nov '14

Hello everybody, I'm trying to use the boost property tree library to represent recursive data structures, but although I can get the dumped json to look reasonable, I cannot traverse the ptree in any ways I've tried. The code below, compiles and run, except for the call to Dump in DumpAssign. Is there a way to traverse arbitrary trees where values can be themselves ptrees? I'm about to throw the towel and go with boost::seriaization, but I did like the traversal mechanisms property trees offer. Any suggestion? Thanks, Maurizio #include <boost/any.hpp> #include <boost/assign/list_of.hpp> #include <boost/foreach.hpp> #include <boost/property_tree/json_parser.hpp> #include <boost/property_tree/ptree.hpp> #include <boost/property_tree/xml_parser.hpp> #include <iostream> #include <string> #include <vector> #include <map> using boost::property_tree::ptree; using boost::assign::list_of; using boost::assign::map_list_of; using namespace std; ptree Op(string type, ptree a1, ptree a2) { ptree pt; // pt.put_value(type); pt.put("type", type); ptree args; args.push_back(make_pair("", a1)); args.push_back(make_pair("", a2)); pt.add_child("args", args); return pt; } ptree Net(string name) { ptree pt; pt.put("type", "net"); pt.put("name", name); return pt; } ptree Assign(ptree lhs, ptree rhs) { ptree pt; pt.put("type", "assign"); pt.add_child("lhs", lhs); pt.add_child("rhs", rhs); return pt; } string Dump(ptree::value_type e); string DumpConcat(ptree::value_type e) { string result = "{"; bool first = true; BOOST_FOREACH(const ptree::value_type& child, e.second.get_child("args")) { if (not first) { result += ", "; first = false; } result += Dump(child); } return result + "}"; } string DumpNet(ptree::value_type e) { return e.second.get<std::string>("name"); } string DumpAssign(ptree::value_type e) { string result = "assign "; // HOW TO HAVE A RECURSIVE CALL TO Dump(lhs) HERE? result += Dump(?); return result; } string DumpNop(ptree::value_type) {return "NOP";} string Dump(ptree::value_type e) { static std::map<string, string(*)(ptree::value_type)> dump = map_list_of ("net", DumpNet) ("concat", DumpConcat) ("assign", DumpAssign) ("nop", DumpNop) ; string type = e.second.get<string>("type", "nop"); return dump[type](e); } int main(int, char**) { ptree pt; ptree a1; a1.push_back(make_pair("", Assign( Op("concat", Op("concat", Net("a1"), Net("a1")), Net("w")), Net("a2")))); pt.add_child("operators", a1); cout << "=============\n"; write_json(std::cout, pt); cout << "=============\n"; BOOST_FOREACH(const ptree::value_type& e, pt.get_child("operators")) { cout << "> " << Dump(e); } }

1 0

Boost.Python shared_ptr bug?
by Christoff Kok 10 Nov '14

10 Nov '14

Hi, I found an issue when accessing a shared_ptr C++ object in Python using Boost.Python. When I try to access an attribute of the shared_ptr object read from an C++ object, I get an error telling me that the attribute does not exist. When I use raw pointers instead of shared_ptr, then there is no issue. Also, when using raw pointers, accessing an item in a list of base class objects returns the object in as the derived most class. This is wanted. When I use shared_ptrs however, the derived most object is of the base class type. This is not wanted. I am sure the Boost.Python developers should be aware of these two issues by now. If so, is there any plans to fix this? If so, when? Below is a test showing this issue: *Raw pointers:* #include<memory> #include<vector> struct Vehicle{ virtual ~Vehicle(){} int testAttribute; }; struct Boat: public Vehicle { virtual ~Boat(){} int testBoatAttribute; }; struct Garage { std::vector<Vehicle*>& vehicleList() { return m_VehicleList; } std::vector<Vehicle*> m_VehicleList; }; #include <boost/python.hpp> #include <boost/python/suite/indexing/vector_indexing_suite.hpp> BOOST_PYTHON_MODULE(garage_ext) { using namespace boost::python; class_<Garage>("Garage") .def("vehicleList", &Garage::vehicleList, return_internal_reference<1>()); class_<Vehicle,Vehicle*,boost::noncopyable>("Vehicle", no_init) .def_readwrite("testAttribute", &Vehicle::testAttribute); class_<Boat,Boat*,bases<Vehicle>>("Boat") .def_readwrite("testBoatAttribute", &Boat::testBoatAttribute); implicitly_convertible<Boat*, Vehicle*>(); class_<std::vector<Vehicle*> >("stl_vector_Vehicle_ptr") .def(vector_indexing_suite<std::vector<Vehicle*>>()); } *Shared pointers:* #include<memory> #include<vector> #include <boost/shared_ptr.hpp> struct Vehicle{ virtual ~Vehicle(){} friend bool operator==(const Vehicle& lhs, const Vehicle& rhs) { return true; } int testAttribute; }; struct Boat: public Vehicle { virtual ~Boat(){} friend bool operator==(const Boat& lhs, const Boat& rhs) { return true; } int testBoatAttribute; }; struct Garage { friend bool operator==(const Garage& lhs, const Garage& rhs) { return true; } std::vector<boost::shared_ptr<Vehicle>>& vehicleList() { return m_VehicleList; } std::vector<boost::shared_ptr<Vehicle>> m_VehicleList; }; #include <boost/python.hpp> #include <boost/python/suite/indexing/vector_indexing_suite.hpp> BOOST_PYTHON_MODULE(garage_ext){ using namespace boost::python; class_<Garage>("Garage") .def("vehicleList", &Garage::vehicleList, return_internal_reference<1>()); class_<Vehicle,boost::shared_ptr<Vehicle>,boost::noncopyable>("Vehicle", no_init) .def_readwrite("testAttribute", &Vehicle::testAttribute); class_<Boat,boost::shared_ptr<Boat>, bases<Vehicle>>("Boat") .def_readwrite("testBoatAttribute", &Boat::testBoatAttribute); implicitly_convertible<boost::shared_ptr<Boat>, boost::shared_ptr<Vehicle>>(); class_<std::vector<boost::shared_ptr<Vehicle>> >("stl_vector_Vehicle_ptr") .def(vector_indexing_suite<std::vector<boost::shared_ptr<Vehicle>>>()); } *Python test:* from garage_ext import * g = Garage() l = g.vehicleList() newboat = Boat() newboat.testAttribute = 3 newboat.testBoatAttribute = 5 l.append(newboat) print(type(l[0])) print(str(hasattr(l[0],"testAttribute"))) print(str(l[0].testAttribute)) b = l[0] print(type(b)) print(str(b.testBoatAttribute)) print("Done.") *Raw pointer result:* <class 'garage_ext.Boat'> True 3 <class 'garage_ext.Boat'> 5 Done. *Shared pointer result:* <class 'garage_ext.*Vehicle*'> *// Expected it to be Boat as with Raw pointers* Traceback (most recent call last): File "test_garage.py", line 9, in <module> print(str(hasattr(l[0],"testAttribute"))) *// Expected attribute to exist as with Raw pointers. Note: dir(l[0]) shows that it has the attribute. Accessing the attribute however throws an error.* Boost.Python.ArgumentError: Python argument types in None.None(Vehicle) did not match C++ signature: None(Vehicle {lvalue}) Kind Regards, Christoff

1 0

MSM library: documentation graphics
by Ricardo Cruz 09 Nov '14

09 Nov '14

Dear all, I am considering adopting boost MSM library for the statecharts in my project. It looks awesome. The documentation has several graphical representations of the state machines: http://www.boost.org/doc/libs/1_57_0/libs/msm/doc/HTML/index.html They look automatically generated. Are they? If so, what tool was used? I did not find that information anywhere in the documentation. Sorry if I miss it. Best wishes, Ricardo Cruz

2 1

Bidirectional breadth first search?
by Amanda Robson 08 Nov '14

08 Nov '14

Hi Does anyone know if Boost already supports bidirectional breadth first search? If not, how feasible would it be to extend boost’s bfs implementation to become bidirectional? Thanks. Amanda

1 0

iterator adaptor not inheriting pointer typedef
by Matei David 08 Nov '14

08 Nov '14

Hi, I have some questions about the Boost Iterator library. I've recently discovered the "hard way", meaning through impenetrable TMP error messages :), that when using boost::iterator_adaptor, the derived iterator type does not (always??) inherit the pointer typedef of the base iterator type. I mean, the iterator_adaptor glue class does not have this typedef. So, for example, I have a Base_Iterator type with: Base_Iterator::pointer != Base_Iterator::value_type* If I do: class Derived_Iterator : public boost::iterator_adaptor< Derived_Iterator, Base_Iterator > {...} then, strangely I find: Derived_Iterator::value_type == Base_Iterator::value_type (OK) Derived_Iterator::pointer == Base_Iterator::value_type* != Base_Iterator::pointer (not OK) I looked at the documentation, and I did find a mention of this, but only for iterator_facade, here: http://www.boost.org/doc/libs/develop/libs/iterator/doc/iterator_facade.html The corresponding page for iterator_adaptor does not mention the pointer typedef at all. While for facade using a plain pointer seems ok (no other reasonable default), I would argue that for adaptor this is not ok. Is this expected behaviour or a bug? Within the same setting, and in what could be a related issue, I also found that the intermediate boost::iterator_adaptor<> class does not seem to contain the default/common sense definition: Base_Iterator operator->() const { return this->base(); } I didn't look inside the source code of boost::iterator_adaptor, but I found a situation where I have to put this definition explicitly inside Derived_Iterator for my code to compile (without it, it doesn't). Does this sound like expected behaviour? Thanks M

2 2

Flyweight: constexpr user defined literals
by Akim Demaille 07 Nov '14

07 Nov '14

Hi all, Hi Joaquin, I'm using flyweights of strings (aka symbols) for my "format" arguments: a key that specifies the kind of output that should be produced by the printing routines. Sometimes, I have code that roughly resembles to: print_entry_(src, dst, o, dot2tex_ ? symbol("latex") : symbol("text")); My question is: do we have constexpr constructors with Flyweight in such a way that I could have something like: print_entry_(src, dst, o, dot2tex_ ? "latex"sym : "text"sym); and have a single construction of these guys not matter how many times I go throw this piece of code, or should I build them once for all in say a member? print_entry_(src, dst, o, dot2tex_ ? sym_latex : sym_text); I've seen nothing about "constexpr" in the doc.

2 1

Re: [Boost-users] iterator_facade Boost 1.57
by Matei David 07 Nov '14

07 Nov '14

On Tue, 04 Nov 2014 14:07:09 +0000 (UTC) gast128 wrote: > Dear all, > > Just trying out 1.57, since we are already 5 releases behind due to > all kinds of compilation errors with Boost and our software. Below > simplified code doesn't compile on vs2010: > > template <typename DerivedType> > struct IteratorFacade : public boost::iterator_facade<DerivedType, > int, std::random_access_iterator_tag> > { > typedef boost::iterator_facade<DerivedType, int, > std::random_access_iterator_tag> base; > > IteratorFacade (); > virtual ~IteratorFacade (); > > friend class boost::iterator_core_access; > > reference dereference () const; > }; > > struct MyIteratorFacade : IteratorFacade<MyIteratorFacade> > { > }; > > What do I wrong? Hi, I'm gcc 4.9.1 on Ubuntu 14.04. The reason this doesn't compile is that the "reference" typedef is contained in the glue class boost::iterator_facade, which is a base class of IteratorFacade<MyIteratorFacade>. When you write "reference" inside the later, the name is not being looked up in the base class. So you should write: typename base::reference dereference() const; If you want to use "reference" in many places in IteratorFacade<>, pull the typedef from its base with: typedef typename base::reference reference; or, if using C++11: using typename base::reference; Note: whether you pull it up or not, you can always get the typedef as IteratorFacade<...>::reference, or MyIteratorFacade::reference in your case. (See the example below, where I'm not pulling it up, but I can still find it.) I would also add the observation that your construct creates an unusual derivation. Usually, the iterator class you want to define has boost::iterator_facade as its direct base. In your case, boost::iterator_facade is the base of the base of your iterator class (so, 2 levels down): MyIteratorFacade : IteratorFacade<MyIteratorFacade> : boost::iterator_facade<MyIteratorFacade, ...> I'm not sure this would cause any problems, just be on the lookout for missing constructors. For example, this compiles just fine for me: #include <type_traits> #include <boost/iterator/iterator_facade.hpp> struct MyIteratorFacade : public boost::iterator_facade<MyIteratorFacade, int, std::random_access_iterator_tag> { typedef boost::iterator_facade<MyIteratorFacade, int, std::random_access_iterator_tag> base; MyIteratorFacade (); virtual ~MyIteratorFacade (); friend class boost::iterator_core_access; typename base::reference dereference() const; }; static_assert(std::is_same< MyIteratorFacade::value_type, int >::value, "MyIteratorFacade::value_type != int"); static_assert(std::is_same< MyIteratorFacade::reference, int& >::value, "MyIteratorFacade::reference != int&"); static_assert(std::is_same< MyIteratorFacade::pointer, int* >::value, "MyIteratorFacade::pointer != int*"); static_assert(std::is_same< std::iterator_traits<MyIteratorFacade>::value_type, int >::value, "iterator_traits<MyIteratorFacade>::value_type != int"); static_assert(std::is_same< std::iterator_traits<MyIteratorFacade>::reference, int& >::value, "iterator_traits<MyIteratorFacade>::reference != int&"); static_assert(std::is_same< std::iterator_traits<MyIteratorFacade>::pointer, int* >::value, "iterator_traits<MyIteratorFacade>::pointer != int*"); I compile with: g++ -Wall -Wextra -pedantic -std=c++11 -I${BOOST_INCLUDE_1_57} -c (I'm only using c++11 for static_assert.) M

1 0

Boost.Python C++ pointer object to python: Attribute does not exist.
by Christoff Kok 07 Nov '14

07 Nov '14

Hi, I'm struggling with the following issue in a boost.python implementation: I have a list of std::shared_ptr in C++, I am accessing this list from Python. - When I access an element in the list, the elements does not have any attributes apparently. I get an error trying to access an attribute, hasattr returns false on the attribute, but dir informs me that it exist. - When I change the C++ implementation from shared_ptr to raw ptr's everything works as expected. - I want to use shared_ptrs for what I feel: obvious reasons. Below is the C++ code and the Python code. ################### ### garage_ext.cpp ### ################### #include<memory> #include<vector> namespace boost { template<class T> T* get_pointer(std::shared_ptr<T>& p){ return p.get(); }} struct Vehicle{ virtual ~Vehicle(){} friend bool operator==(const Vehicle& lhs, const Vehicle& rhs) { return true; } int testAttribute; }; struct Boat: public Vehicle { virtual ~Boat(){} friend bool operator==(const Boat& lhs, const Boat& rhs) { return true; } int testBoatAttribute; }; struct Garage { friend bool operator==(const Garage& lhs, const Garage& rhs) { return true; } std::vector<std::shared_ptr<Vehicle>>& vehicleList() { return m_VehicleList; } std::vector<std::shared_ptr<Boat>>& boatList() { return m_BoatList; } std::vector<std::shared_ptr<Vehicle>> m_VehicleList; std::vector<std::shared_ptr<Boat>> m_BoatList; }; #include <boost/python.hpp> #include <boost/python/suite/indexing/vector_indexing_suite.hpp> class BoatWrap : public Boat, public boost::python::wrapper<Boat> { public: static std::shared_ptr<Boat> cast(std::shared_ptr<Vehicle> const& v) { return std::dynamic_pointer_cast<Boat>(v); } }; BOOST_PYTHON_MODULE(garage_ext) { using namespace boost::python; class_<Garage>("Garage") .def("vehicleList", &Garage::vehicleList, return_internal_reference<1>()) .def("boatList", &Garage::boatList, return_internal_reference<1>()) ; class_<Vehicle, std::shared_ptr<Vehicle>,boost::noncopyable>("Vehicle", no_init) .def_readwrite("testAttribute", &Vehicle::testAttribute) ; class_<BoatWrap,std::shared_ptr<Boat>,bases<Vehicle>>("Boat") .def("cast", &BoatWrap::cast) .staticmethod("cast") .def_readwrite("testBoatAttribute", &Boat::testBoatAttribute) ; implicitly_convertible<std::shared_ptr<Boat>,std::shared_ptr<Vehicle>>(); class_<std::vector<std::shared_ptr<Vehicle>> >("stl_vector_Vehicle_ptr") .def(vector_indexing_suite<std::vector<std::shared_ptr<Vehicle>> >()); class_<std::vector<std::shared_ptr<Boat>> >("stl_vector_Boat_ptr") .def(vector_indexing_suite<std::vector<std::shared_ptr<Boat>> >()); } ##################### ### Python test code ### ##################### g = Garage() l = g.boatList() newboat = Boat() l.append(newboat) boatFromList = l[0] print(type(boatFromList)) print(str(hasattr(newboat,"testBoatAttribute"))) dir(boatFromList) # The following line throws the error. print(str(hasattr(boatFromList,"testBoatAttribute"))) I created a cast method for boat. If I cast l[0] to Boat using: boatFromList = Boat.cast(l[0]) print(str(hasattr(boatFromList,"testBoatAttribute"))) works. This is all very strange to me. It feels very buggy. Could someone please help me clarify the reason for this behavious? Regards, Christoff

1 0