October 2014 - Boost - lists.preview.boost.org

[Lockfree] has_trivial_destructor and has_trivial_assign restrictions
by Dan Dillon 28 Oct '14

28 Oct '14

I've been doing some thinking about this, and to my untrained eye these restrictions do not seem to be a requirement of the lock-free structure. That is to say, they need not be atomic anyhow, so why does it matter if they are trivial or not? The question goes to making the data structures more globally useful. The more structures they can be used with, the better they are (at least in my opinion). Thanks, Dan

2 1

Custom logging backend difficulty
by Kenneth Adam Miller 28 Oct '14

28 Oct '14

So, I need malleable logging facilities, and so far I've identified boost's logging facilities as useful. I've read the docs on logging, and right now I'm having difficulty achieving what I want-basically, I have a custom backend, in order that when logging is done, it gets routed to an alternative destination - over the network namely. I extended from text_ostream_backend, and basically I'm having the following trouble: I don't understand the record_view visitation API. I'd like the ability to set formatters and what not to remain untouched, but have the final formatted result sent off else where. I can change this by sending the string received in the consume function that has to be overrode, but the values are lost in the record_view. void consume (const record_view & rec, std::string s); where I do { send(s); } for the body. What I think is necessary is just to retain the default behavior of accepting whatever formatter was specified... What is the best way to go about achieving what I want?

3 8

1.57.0 beta 1 is in a new location
by Marshall Clow 27 Oct '14

27 Oct '14

Tom Kent pointed out that I put the beta 1 files in a folder that we traditionally use for Windows binaries, so I have moved the beta files to https://sourceforge.net/projects/boost/files/boost/1.57.0.beta.1/ These are the same files as last Monday - merely in a new location. If you have already downloaded and tested the beta, thanks! - no need to do it again. — Marshall

1 0

Re: [boost] Non-allocating constexpr functional continuations-based future-promise
by Bjorn Reese 26 Oct '14

26 Oct '14

On 10/23/2014 11:00 PM, Niall Douglas wrote: > Given Hartmut's feedback from my previous attempt at a non-allocating > future-promise implementation, I now have a second, much more generic > demonstration prototype which is based on heterogenous sequences of > constexpr functional calls. I think this design may have huge potential. This is a very nice evolution of your previous promise-future framework. > template<class T> struct then_continuation > { > std::vector<std::function<void(T)>> _conts; > template<class U> auto then(U &&c) > { > typedef decltype(c(std::declval<T>())) result_type; > promise<result_type> p; > future<result_type> ret(p.get_future()); > // Unfortunately libstdc++'s std::function currently always tries to > copy lambda types > //_conts.emplace_back([p=std::move(p), c=std::forward(c)](T > v){p.set_value(c(v));}); > _conts.push_back([p = > std::make_shared<promise<result_type>>(std::move(p)), > c=std::forward(c)](T v){p->set_value(c(v));}); > return ret; > } > BOOST_CONSTEXPR T operator()(T v) const > { > for(auto &i : _conts) > i(v); > return v; > } > }; > > All this continuation does is provide a .then(callable) which stores those > callables into a std::vector and its operator() executes the previously > stored callables. Previously you defined callables as composed functions, but here you execute them sequentially. That is, then(f1).then(f2) gets executed as f1(v),f2(v) instead of f2(f1(v)). Or am I missing something?

2 1

[boost.lockfree] spsc_queue preallocated memory block
by Philip Bennefall 25 Oct '14

25 Oct '14

Hi all, I have a feature request for Boost.lockfree (spsc_queue in particular). When using the runtime sized version, could there possibly be a constructor that takes max_size as well as a T* that is then used as the memory buffer? This would remove the need for a specialized allocator if I want to quickly initialize the buffer with memory that does not come from the default std allocator. Kind regards, Philip Bennefall

2 2

Re: [boost] Applying Boost Phoenix to infinite sequence
by Aaron Levy 25 Oct '14

25 Oct '14

25.10.2014, 00:54, "Aaron Levy" <aaron.levy(a)yandex.com>: > Is there a way to use Boost Phoenix to define an infinite sequence and evaluate specific terms of it, compute partial sums, etc? I am looking for pointers to specific libraries or examples. > Indeed, what would are some examples of common programming problems that can be succinctly solved using Phoenix? Aaron.

2 1

Why is iterator_traits<unordered_map<K, M>>::pointer a detail::ptr_node type rather than value_type *?
by Alex Mohr 24 Oct '14

24 Oct '14

The iterator type looks like: template <typename NodePointer, typename Value> struct iterator : public boost::iterator< std::forward_iterator_tag, Value, std::ptrdiff_t, NodePointer, Value&> The NodePointer argument here (which is boost::unordered::detail::ptr_node<...>) becomes the iterator_traits<>::pointer type. But iterator's operator->() returns Value *: Value* operator->() const { return &node_->value(); } Why shouldn't iterator_traits<>::pointer be Value* here? This detail::ptr_node<> type seems intended to be completely internal. Thanks, Alex

3 2

Non-allocating constexpr functional continuations-based future-promise
by Niall Douglas 23 Oct '14

23 Oct '14

>

1 0

Non-allocating constexpr functional continuations-based future-promise
by Niall Douglas 23 Oct '14

23 Oct '14

Dear Boost, Given Hartmut's feedback from my previous attempt at a non-allocating future-promise implementation, I now have a second, much more generic demonstration prototype which is based on heterogenous sequences of constexpr functional calls. I think this design may have huge potential. Consider some heterogenous sequence of callables C { f1, f2, f3, f4, ... } such that fN(... f4(f3(f2(f1(Args...))))) -> R i.e. if you call the heterogenous sequence with arguments Args..., f1(args...) will be called and fed to f2() which then is fed to f3() up to fN() whose return type is R. If I understand proposed Boost.Hana correctly, these potentially constexpr sequences of heterogeneous callables are the main bridge between pure compile-time heterogeneous type sequences and doing something with them in real code as they can decay on demand into actual code when needed. And for proposed Boost.Expected, its monadic programming sequences bind(), map() and then() all functionally operate on some expected<T, E>, consuming an instance and returning new instances, so these monadic sequences are also potentially constexpr sequences of heterogenous callables. Now, what new basic_future-basic_promise will do is to allow you to insert a suspend-resume of execution into some functional sequence C, so essentially: split<idx>(C) => [ basic_promise<X>, basic_future<Y> ] ... where X is some split front part of C and Y is some back part of C. You can now execute the first part of C via the call operator: basic_promise<X>(Args...) Execution of the C0...Cn making up X occurs, but instead of continuing into Y it stores the result of Cn and makes that available to the corresponding basic_future. At some later point you can resume the execution of C: basic_future<Y>() -> R ... and thus complete the execution of the functional sequence C, returning the same value R as invoking the original functional sequence C with the same input parameters. For those who prefer to understand theory via code, here is some example C++ 14 code: // Let this be an arbitrarily long sequence of functional callables auto ct=make_continuations([](auto x){return 5+x;}, [](auto x){ return x+6;}); { // Make a future promise pair for if we called c(int) auto fp=ct.suspend_resume<1, int>(); // Execute promise fp.first(1); // Execute future b=std::move(fp.second)(); } { // Make a future promise pair for if we called c(double) auto fp=ct.suspend_resume<1, double>(); // Execute promise fp.first(1.0); // Execute future d=std::move(fp.second)(); } // b=12, d=12.0 There are a multitude of uses for this very fundamental pattern. Let us try implementing something closely resembling the Concurrency TS's dynamic continuations support .then(launch, callable). Let us define this functional continuation: template<class T> struct then_continuation { std::vector<std::function<void(T)>> _conts; template<class U> auto then(U &&c) { typedef decltype(c(std::declval<T>())) result_type; promise<result_type> p; future<result_type> ret(p.get_future()); // Unfortunately libstdc++'s std::function currently always tries to copy lambda types //_conts.emplace_back([p=std::move(p), c=std::forward(c)](T v){p.set_value(c(v));}); _conts.push_back([p = std::make_shared<promise<result_type>>(std::move(p)), c=std::forward(c)](T v){p->set_value(c(v));}); return ret; } BOOST_CONSTEXPR T operator()(T v) const { for(auto &i : _conts) i(v); return v; } }; All this continuation does is provide a .then(callable) which stores those callables into a std::vector and its operator() executes the previously stored callables. Now let us define a std::promise lookalike, with its main deficiencies being a total lack of exception_ptr support (one would use expected<T, E> as the transport type for that) and of course any thread safety: template<class T> class promise : public basic_promise<detail::then_continuation<T>, T, detail::then_continuation<T>> ... basic_promise takes three template parameters, the type of the front split of the continuations, the transported type between the two halves of continuations, and the type of the back split of the continuations. Here, we are defining promise as transporting a type T, and two then_continuation continuations exist before and after the transport of the type T. To our future<T> lookalike we now add this: template<class U> auto then(launch policy, U &&c) { if(policy==launch::deferred) return Base::_after.then(std::forward(c)); else if(Base::_other) return Base::_other->_before.then(std::forward(c)); } So, if the .then() dynamic continuation is deferred, push it into the latter then_continuation, else push it into the former. And voila, you can now do this very similar to Concurrency TS code: promise<int> p; future<int> f(p.get_future()); future<double> f2(f.then(launch(), [](int a){return a+1.0;})); p.set_value(5); return f2.get(); And you get back 6.0, as expected. However here is where things get neato. How many instructions do you think GCC 4.9 generates for this sequence? promise<int> p; future<int> f(p.get_future()); p.set_value(5); return f.get(); In traditional future-promise, that is an operation perhaps consuming thousands of CPU cycles and at least one memory allocation and deallocation. Well, this is the assembler produced by the above by GCC 4.9: _Z19test_futurepromise4v: movq $0, -88(%rsp) movq $0, -80(%rsp) movl $5, %eax movq $0, -72(%rsp) movq $0, -48(%rsp) movq $0, -40(%rsp) movq $0, -32(%rsp) movl $5, -56(%rsp) movq $0, -64(%rsp) movq $0, -24(%rsp) ret Believe it or not, this is actually bad output - there is a bug in GCC's optimiser and it should in fact be outputting a single instruction rather than writing zeros into the stack for no purpose - it seems to get confused by the double declation of a std::vector which is never used, because having just one std::vector produces the ideal output but having two produces the above. However clang 3.4's optimiser does far worse, and a bug there with how non-immediately defined types are treated causes complete expansion of code in its entirety, even if you remove all std::vector's (supplying any type not immediately declared in the same function breaks the optimiser for some unknown reason. I haven't tried clang 3.5 yet, it may be fixed). Other very interesting policy continuations which can be statically mixed into custom future promise types include calling some application specific callback without needing to indirect via a pointer to a function. This lets you combine future promise with invoking callbacks, useful for legacy code. The idea behind this suite of future-promise fundamental parts is that they can be mixed at will into bespoke future-ish promise-ish application specific future promise types. Because they all share the same foundations, a when_any() or when_all() can accept heterogenous future types - and I don't mean future<int> with future<double>, rather I mean afio::future<> with qt::future<int>, that sort of heterogenity. Another very interesting idea is combining these with signals and slots, so via custom continuations you can keep slots and fire signals in sync with future promises. This design I think shows a lot of potential. Anyway, I feel very happy with this design, and something along these lines is where I shall proceed next. The eventual intention is for these future promises to become the default Boost.Thread future promises when C++11 is available, though this will be up to a year from now. I won't be able to support future-promise custom allocators, but I certainly should be able to completely avoid memory allocation and sometimes the generation of any code at all with this design. The demonstration prototype code is at https://github.com/ned14/boost.spinlock/blob/expected_future/test_constexpr_ future_promise2.cpp for anyone interested. It needs a C++ 14 compiler, so a minimum of libstdc++ 4.9 and either GCC 4.9 or clang 3.4 or better. Comments are welcome. Niall

1 0

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