- Boost-users - lists.boost.org

[Pyhton] (re)binding class instance in python object
by Tamas.Ruszkai＠leica-geosystems.com 27 Apr '15

27 Apr '15

Hi, I have a plain C++ class which I want to exposed to python. The pyhton object accesses the C++ class via smart pointer. class Sensor : public boost::enable_shared_from_this<Sensor> { public: Sensor(int port); ~Sensor() void Open(); void SendCommand(const std::string& command); void Close(); private: int _port; }; auto sensorClassTypeObject = boost::python::class_<Sensor, boost:: shared_ptr<Sensor>>("Sensor", boost::python::init<int>()) .def("Open", &Sensor::Open) .def("SendCommand", &Sensor::SendCommand) .def("Close", &Sensor::Close); The question is: if I already have one instance of the C++ class (in a dependency injection container) then how can I create in the C++ part an instance of the python wrapper so that it does not create a new instance of Sensor, but uses my existing Sensor instance? Then I would put this instance into one of the python modules (this part would be made in C++) inside the python interpreter to be able to access it via script. Something like that: shared_ptr<Sensor> sensorInstance = DIContainer.Resolve<Sensor>(); boost::object pythonInstance = sensorClassTypeObject(sensorInstance); pythonInterpreterWrapper.AddToModule("__main__", pythonInstance); Best Regards, Tamas

1 0

[msm] Event does not get processed after exiting an interrupt state
by Chrisopher Vogl 27 Apr '15

27 Apr '15

Hi all! I got a state machine with 2 regions. The second region has two states ("Run" and "Interrupt"), one is an interrupt state. The region starts in the non interrupt state, just like in the MSM example "Orthogonal regions, terminate state, event deferring". The event called Ev_Resume leads to a transition from state Interrupt back to state Run. In on_entry() of Run I fire an event which never gets processed. Is at that time the FSM still interrupted, i.e. event processing still blocked? Christopher

2 1

Re: [Boost-users] [boost] [test] boost.test owner unresponsive to persistent problems for multiple years
by Paul A. Bristow 25 Apr '15

25 Apr '15

> -----Original Message----- > From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Richard > Sent: 17 March 2015 17:20 > To: boost(a)lists.boost.org > Subject: Re: [boost] [test] boost.test owner unresponsive to persistent problems for multiple years > > Another quarter has gone by and another Boost release is prepared for beta and I see *no* changes to > Boost.Test listed in the release notes.> > So here we are, waiting another 3 months for *simple* changes to be reflected in this library while the > maintainer insists that the fixes are available, yet they continue not to be deployed into any shipping release. It is indeed really deplorable that we don't have Boost.Test updates in a release. Though in mitigation I note that we are really struggling to get out a GIT-driven release at all, (and some of the new troubles are with asynch-exceptions in Boost.Test. See this thread Re: [boost] Running b2 on develop needs asynch-exceptions=on.) However, Richard's hard work on improved docs have been refined and completed by Raffi Enficiaud. Many bug fixes are in the develop branch (including some very new and prompt bug fixes, for example https://svn.boost.org/trac/boost/ticket/11054) I also understand that the fear of Boost.Test updates causing trouble with other libraries, and worse with users test, is a cause for caution in a release version. So it would be really good if *lots more users could download and use the version in the Boost.Test develop branch* so we can get current user feedback. (My experience is good using this, and the test matrix is also good). You can download just Boost.Test either using GIT or as a zip from https://github.com/boostorg/test/tree/develop and substitute it for the contents of the current release modular-boost/libs/test folder (Don't forget to rebuild the Boost.Test library unless you only use the included version). If nothing else, you will find Raffi's shiny new Boostbook docs finally allow you to find what you want to know without frustration. I'd very much like to see this new docs version in the 1.58 documentation release (despite any new features not being in the code release). Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830

5 5

[log] Possible to explicitly disable AVX2?
by Jason Roehm 25 Apr '15

25 Apr '15

I am building Boost.Log on a relatively new machine whose compiler and CPU both support the AVX2 instruction set. Boost.Log detects this at build time and configures its compiler flags accordingly to use the AVX2 instruction set. I'd like to use the resulting binaries, however, on older systems that do not have AVX2 support. Is it possible to explicitly disable this at build time? I didn't see any mention of it in the documentation, and my attempts to parse the Jamfile's intentions were not successful. Thank you. Jason

1 0

[nowide] Cannot end input using ^Z/^D on Windows
by Yuan Yao 25 Apr '15

25 Apr '15

3 2

boost examples
by Trek 24 Apr '15

24 Apr '15

Is there a central link where all official boost examples are hosted? thanks,

3 2

Boost.Thread Continuation future with executor blocking in destructor
by Konrad Zemek 24 Apr '15

24 Apr '15

Hi, When creating a continuation future with future<>::then(), and the policy is boost::launch::async, the created future's destructor blocks, like a future created by boost::async, and probably for the same reasons (as outlined by the standardization committee in n3679). The same behavior is coded into continuation futures' destructor when using an executor. Why is it needed here? The situation with executor-run continuations is a little different, as even when the future is destroyed, the lifetime of running job is still bound to the executor. My use case: I've coded a network communication stack that returns to the caller a future<NetworkResponse>. I've previously used std::async(std::launch::deferred, ...) to transform the future's content before returning it to the caller (bytes -> protobuf -> internal object), and I consider such manipulation of a future value to be a very powerful feature. I've used std::launch::deferred to reduce the number of running threads, but the downside is that the client can't wait for the future value with a timeout. On the other side of the spectrum is std::launch::async, which would run a new thread - per pending communication - that would do little more than block. boost::future<>::then is a fantastic fit for my use case, as I can use my boost::asio::io_service as an executor and let my communication stack's threads do the work without having them block on future.get() to first retrieve the result. The caller can then call future<>::wait_for() to wait for the reply with a custom timeout. This being network communication, though, a reply message may never arrive - the corresponding promise will eventually be destroyed by the stack, but I can't have users block on the future's destructor until that happens, after they have already decided that the reply is no longer worth waiting for. Please advise if there's a workaround for this behavior that doesn't involve me distributing a custom version of Boost.Thread with my binaries? :) Konrad

5 6

[asio] What are the enhancements for Asio in 1.58
by Aaron Levy 23 Apr '15

23 Apr '15

I am sorry if this has been already asked. Wanted to get a head start on Asio 1.58, having heard that it's a significantly enhanced library. -- Aaron Levy aaron.levy(a)yandex.com

3 2

[multi_index] Announcing preview of ranked indices
by Joaquin M Lopez Munoz 23 Apr '15

23 Apr '15

Hi, It's been 11 years since first proposed, but here it is at last. I'm releasing a prereview of ranked indices for Boost.MultiIndex: struct person { int age; std::string name; }; typedef multi_index_container< person, indexed_by< ranked_non_unique<member<person,int,&person::age> >, ordered_non_unique<member<person,std::string,&person::name>>>> multi_t; multi_t m={{40,"Joe"},{25,"Jill"},{30,"Kurt"},{32,"Sue"}}; auto it=m.emplace(31,"Maggie").first; std::cout<<m.rank(it)<<" persons younger than "<<it->name<<"\n"; auto n=m.size()/2; std::cout<<n<<" persons are less than "<<m.nth(n)->age<<" years old\n"; Ranked indices add a bunch of extra rank-related capabilities to the interface of ordered indices. The rank of an element is its numerical position in the index. nth(i) returns an iterator to the element with rank i, whereas rank(it) is the inverse operation. Both execute in log(n) time. Additionally, the member functions find_rank lower_bound_rank upper_bound_rank equal_range_rank range_rank behave as their "_rank"-less counterparts except they return ranks rather than iterators. One drawback of ranked indices wrt ordered indices (other than their slower perfomance and higher memory consumption) is that deletion of elements is log(n) (in ordered indices it is constant time). Download lib preview: http://tinyurl.com/kemwk8q Tutorial: http://tinyurl.com/q36c9f7 Reference: http://tinyurl.com/pvoulgr For people interested in this, I'd appreciate if you could download the source, copy it on top of Boost 1.58 (1.57 should work as well), play a bit with the new feature and report your results. Also, opinions on naming are welcome. Target version for releasing is Boost 1.59, so we have plenty of time to discuss the design before it is final. Thank you, Joaquín M López Muñoz Telefónica

1 0

Which is the effective way for data transfer for Interprocess shared memory ?
by Kalyan Chakravarthy Gudimella 23 Apr '15

23 Apr '15

Hi, I am currently evaluating boost interprocess library for using shared memory. I found two ways to transfer complex data structures. 1. Creating data structures directly in shared memory. E.g. http://www.boost.org/doc/libs/1_58_0/doc/html/interprocess/allocators_conta… class complex_data{ int id_; char_string char_string_; int_vector_vector int_vector_vector_; public: //Since void_allocator is convertible to any other allocator<T>, we can simplify //the initialization taking just one allocator for all inner containers. complex_data(int id, const char *name, const void_allocator &void_alloc) : id_(id), char_string_(name, void_alloc), int_vector_vector_(void_alloc) {} //Other members...}; 2. Serializing data into bufferstream and deserializing it. E.g.http://www.boost.org/doc/libs/1_58_0/doc/html/interprocess/streams.html My initial trial shows that streaming to bufferstream took 7 times more time than using direct shared structures. Can you please help me to choose the effective way between these two approaches? thanks, Kalyan

1 0