- Boost - lists.boost.org

DTLS support in boost
by Indtiny S 22 Oct '14

22 Oct '14

Hi, Currently I am using boost for one of my cpp application ... now my application needs DTLS security support ... I currently have written using openssl APIs .. I want nowb...does boost asio has any APIs for DTLS handshake ? Rgds Indhra

1 0

[thread] linux.hpp, BOOST_HAS_PTHREAD_YIELD, BOOST_HAS_SCHED_YIELD
by Rob Conde 22 Oct '14

22 Oct '14

Reposting this here since I got no response on "users" but this list seems more appropriate: Using boost 1.55, Ubuntu 12.04, gcc 4.6 I'm building boost on linux using the lsb sdk (4.1.8) . I was getting the failure (paraphrased): pthread_yield not declared in libs/thread/src/thread.cpp 513 The documentation for pthread_yield (http://man7.org/linux/man-pages/man3/pthread_yield.3.html) says: This call is nonstandard, but present on several other systems. Use the standardized sched_yield(2)<http://man7.org/linux/man-pages/man2/sched_yield.2.html> instead. If I change boost/config/platform/linux.hpp to define BOOST_HAS_SCHED_YIELD instead of BOOST_HAS_PTHREAD_YIELD Then sched_yield is used instead and the build finishes properly. I'm posting this for two reasons: 1. To help others running into the same issue 2. To question whether linux.hpp should be updated officially as I did above 3. If not, why Thanks, Rob Conde

2 3

Help with boost spirit
by Theodore Papadopoulo 22 Oct '14

22 Oct '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Sorry, this is probably a beginner question, but I'm stuck on it for quite some time. I'm trying to write a small string like parser in which the size of the string is first given. Some thing like: int_ >> repeat(_1)[ char_ ] But I cannot figure out the right way of doing this. The natural: const bool result = boost::spirit::qi::parse(it,str.end(),int_ >> repeat(_1)[ char_ ]); fails to compile (and I tried many variations of val, etc) with no success. If I replace _1 by 10, everything works fine. Another question is that of the associated attribute. From the documentation, I would have expected it to be: typedef std::pair<int,std::vector<unsigned char>> Attribute; but that does not work. I have managed to work around this using a second rule, using an attribute std::vector<char>(int) but then again I do not know how to pass the parameter. 10 works but _1 does not. Any help will be appreciated. Some test code is attached, compile with: g++ -g -std=c++11 -dboost_spirit_use_phoenix_v3 Test.C. Variants are in comment. Thank's in advance for any help. Theo. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlQ9GqgACgkQEr8WrU8nPV0b2gCeNFzQXwm1Uux4Eua2+jq8LcZk DW0AoKBKY9KN5kGxYoPbnxwncwFSyH3M =L0bR -----END PGP SIGNATURE-----

2 2

[1.57.0] Release Notes
by Daniel James 22 Oct '14

22 Oct '14

Hi, Sorry this is late, but if you haven't written your release notes, you should do so soon. You can create a pull request on github by clicking on the pencil icon on the toolbar on this page while logged in: https://github.com/boostorg/website/blob/master/feed/history/boost_1_57_0.q… Or if you prefer you can email me, and I'll add it for you. thanks, Daniel

3 2

Non-allocating future-promise
by Niall Douglas 21 Oct '14

21 Oct '14

Dear Boost, I have been working on non-allocating future-promise which when combined with proposed expected<T, E> (i.e. basic_promise<expected<T, E>>) will provide a close substitute to std::future/promise, except that it doesn't use an allocator and can reduce to pure constexpr when possible e.g. this code: __attribute__((noinline)) int test1() { promise<int> p; auto f(p.get_future()); p.set_value(5); return f.get(); } ... reduces to exactly: _Z5test1v: # @_Z5test1v .cfi_startproc # BB#0: # %_ZN7promiseIiJEED2Ev.exit2 movl $5, %eax ret The non-allocating future-promise is intended to be compatible with the Concurrency TS extensions (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4123.html) where futures can have continuations scheduled against them via a future.then(callable). However, this involves an unavoidable memory allocation, which while fine for dynamically assigned continuations is overkill for statically assigned continuations. There is no reason why one could not also have a method of statically adding continuations which uses type extension to store the additions. Let us say we have a template<class T, class... Continuations> class promise and that this promise also provides a .then(callable) like this: template<class F> promise<T, Continuations..., F> then(F &&c) { return promise<T, Continuations..., F>(std::move(*this), std::forward<F>(c)); } ... and therefore to statically add continuations to the future promise, one simply iterates .then(callable) on the promise like this: auto p=promise<int>().then([]).then([]) ...; auto f=p.get_future(); p.set_value(5); // executes all the continuations My first question to the Boost community is this: is there some less ugly way? I'm thinking maybe the promise's constructor could take a set of continuations, and then a make_promise(callable, callable, ...) could construct a statically continued future-promise? My second question to the Boost community is this: should static continuations be able to see the value being set? Or indeed, to modify it before it gets sent to future.get()? My thanks in advance. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

3 6

The master branch is now open for merging
by Marshall Clow 20 Oct '14

20 Oct '14

Please limit to changes that have been implemented in develop and whose tests have cycled. We will be closing the master branch again sometime next week (for the final release two weeks from today). The following problems were noted with the RC (and, I believe, have fixes ready): * Interprocess is broken for MinGW * Visual C++ 14 CTP 4 without BOOST_MSVC_ENABLE_2014_JUN_CTP * For MSVC14, TypeTraits 9de6a49 is missing in master * Thread fixes from Vicente Still needed to do: * Can someone take a look at http://lists.boost.org/Archives/boost/2014/10/217257.php, please? * MSVC 8.0 compilation failures * range/detail/any_iterator.hpp is broken because it expects postfix_increment_proxy and writable_postfix_increment_proxy to be in namespace boost::detail, but they are in boost::iterators::detail now. * There’s a few old Random fixes that need to be looked at. (and anything else we find) Thanks to everyone who tried out the RC, and please encourage people to try the beta! — Marshall

1 0

Re: [boost] [Boost-users] 1.57.0 beta 1 release candidates available for testing
by Marshall Clow 20 Oct '14

20 Oct '14

On Oct 20, 2014, at 7:06 AM, Marcel Raad <raad(a)teamviewer.com> wrote: > Marshall Clow <mclow.lists <at> gmail.com> writes: > >> Release candidate files for 1.57.0 beta 1 are available [...] >> 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. > > range/detail/any_iterator.hpp is broken because it expects > postfix_increment_proxy and writable_postfix_increment_proxy to be in > namespace boost::detail, but they are in boost::iterators::detail now. > > Those errors are also visible in all of the type_erased_* regression tests > of range. I made an executive decision to push the beta out with this problem (and the MSVC 8.0 bugs, too), because I wanted to get a wider audience looking at the beta. Thanks for reporting this, and now let’s fix them. — Marshall

1 0

[intrusive] More features for treap?
by Phil Endecott 20 Oct '14

20 Oct '14

Dear All, I've been looking at Boost.Intrusive's treap, and finding that it doesn't quite do what I need. Here's an example: say I have data about earthquakes in the form (date, magnitude, description). I can store that in a treap with date as the key and magnitude as the priority. Now I'd like to be able to do operations like: - Find the strongest earthquake between dates A and B. - Iterate over all the earthquakes with magnitude > X in date order. - For each year (or month, or decade etc) find the strongest quake. The first two are straightforward in a treap, but the current Boost.Intrusive API doesn't (AFAICT) let me do it. (The third one is less obvious.) I have been wondering how the API could most easily be extended to support this sort of thing, and I'm coming to the conclusion that it is probably best to expose the actual tree structure so that the algorithms for these operations can be implemented explicitly by the user code. I have had similar thoughts in the past about other trees i.e. augmented trees to implement interval trees; the choice is either (a) implement these things inside Boost.Intrusive; (b) don't use Boost.Intrusive at all; (c) extend the intrusive API to expose the actual tree structure. In cases like these extensions to treap, the new operations are simple compared to the complexities of inserting and erasing elements; being able to use the existing implementations of those operations while adding other (non-mutating?) features would save a lot of work. Any thoughts anyone? (Is anyone else using treap?) Regards, Phil.

2 3

[random] Any news?
by Marco Guazzone 20 Oct '14

20 Oct '14

Hello, Do you have any news on lib mainteners? I and other have pull requests But all seems muted.

4 4

Re: [boost] [Boost-users] 1.57.0 beta 1 release candidates available for testing
by Marshall Clow 20 Oct '14

20 Oct '14

On Oct 20, 2014, at 3:52 AM, John Maddock <boost.regex(a)virgin.net> wrote: >>> For Boost.Config: >>> >>> a mostly minor update. >> >> Great, thanks! According to the feature table, auto return types >> (BOOST_NO_CXX14_RETURN_TYPE_DEDUCTION) are also supported. > > Confirmed - it passes our test case anyway, feature enabled. > >>> For TypeTraits: >>> >>> I suspect you're not going to like the latter as it basically disables >>> working versions of is_nothrow* for msvc-14. The reason is that is >>> appears that Boost.Log ends up using noexcept(non_compiling_expression) >>> which requires SFINAE expression support. >> >> I also think it's the best solution. You can also delete >> the "!::boost::is_const<T>::value" with it now. > > Done. > > Marshall - is it OK to merge these fixes after the beta is out? Absolutely. — Marshall

1 0