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

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 23 Apr '15

23 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 22 Apr '15

22 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 22 Apr '15

22 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 22 Apr '15

22 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

[MPL][Config] Can no longer pre-generate headers for MPL-containers with more than 50 elements.
by Deniz Bahadir 22 Apr '15

22 Apr '15

Hello everyone, While playing around with the current Boost release-candidate (1.58.0-RC3) I noticed that pre-generating MPL-headers for MPL-containers with more than 50 Elements seems no longer possible. Up till at least Boost 1.55.0 I was able to pre-generate these MPL-headers using the python-scripts from Boost-source ([1]) with the help of a bash-script which I already described here [2]. Internally, these python-scripts seem to use GCC to generate these MPL-headers. They also seem to partially circumvent Boost.Config by using custom user.hpp files located in subdirectories of [3] and defining BOOST_NO_CONFIG and some other macros therein. However, this does not seem to please Boost.Config so that compiler-errors ([4]) occur. Defining the macro BOOST_CONFIG_ALLOW_DEPRECATED as [4] suggests seems not to help. It just silences the warnings but does not generate proper files. (It actually erases the content of almost all header-files in subdirectories of [5].) Does anyone know how to workaround or better fix this? Or does anyone know who to talk to, to get these problems fixed? Also, I would suggest, that documentation for these python-scripts are added to the documentation of Boost.MPL. Best regards, Deniz References: [1] ${BOOST_SOURCE}/libs/mpl/preprocessed/ [2] http://stackoverflow.com/a/20660264/3115457 [3] ${BOOST_SOURCE}/libs/mpl/preprocessed/include/ [4] #error "You are using a compiler which lacks features which are now a minimum requirement in order to use Boost, define BOOST_CONFIG_ALLOW_DEPRECATED if you want to continue at your own risk!!!" [5] ${BOOST_SOURCE}/boost/mpl/aux_/preprocessed/

3 5

[SPAM] from: giridhar
by giridhar 22 Apr '15

22 Apr '15

Greetings boost http://findislamicservices.com/reduce.php?silver=aswydt7xv2r0enm3 giridhar Sent from my iPhone

1 0

sliding window containing n seconds of data
by Lane 22 Apr '15

22 Apr '15

I'm looking for a way to examine an array of object structures for an adjustable window of n seconds. My application reads objects at a high rate (which I'll have to throttle), and I'd then like to put them onto an array. My thinking is to assign a timer on each object that is initialized to n seconds and once the timer expires, the object is removed from the array, but while it's on the array, I'll iterate over the objects looking for the info I need. I put this out on the boost list as I suspect boost has the mechanisms to handle this and someone could suggest a good way of going about it. Any help much appreciated.

5 5

1.58.0 rc3 is now available
by Marshall Clow 22 Apr '15

22 Apr '15

Release candidate files for 1.58.0 are available at: http://boost.cowic.de/rc/ * Since rc1, the changes that were causing the serialization libraries to fail to build on MSVC have been reverted. * Since rc2, the documentation for bind, and mem_fun. No code changes. As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. This helps ensure the candidates build OK before we push them out to SourceForge. The files (and associated md5s) are: MD5 (boost_1_58_0_rc3.7z) = f7255aeb692c1c38fe761c32fb0d3ecd MD5 (boost_1_58_0_rc3.tar.bz2) = b8839650e61e9c1c0a89f371dd475546 MD5 (boost_1_58_0_rc3.tar.gz) = 5a5d5614d9a07672e1ab2a250b5defc5 MD5 (boost_1_58_0_rc3.zip) = b0605a9323f1e960f7434dbbd95a7a5c Thanks! -- The release managers P.S. Release notes are here: http://www.boost.org/users/history/version_1_58_0.html

5 7

Re: [Boost-users] [IPC Named Mutex]
by Lorenzo Trivelli 21 Apr '15

21 Apr '15

Hi Tom, I tried your solution and it worked, and I'm stil wondering about the rationale behind the bootup time usage ;-) I also submitted a bug ticket, #11194, but track took a very long time to create it and add the test case, and in the end I found that: 1) a bug with ticket !11195 was also created 2) the test case was attached four times :-( can anyone please clean it up as is is a quite ugly ? ;-) regards Lorenzo

1 0