February 2016 - Boost - lists.boost.org

What's wrong with this benchmark
by Benedek Thaler 20 Feb '16

20 Feb '16

Dear Boost, In a previous mail, I introduced a container library, `double_ended`. This library has benchmarks [0]. However, the benchmarks show unexpected results. This is what I do [1]: - compile program using G++ 5.3, -O2 - remove CPU0 from kernel scheduler pool (isolcpu=0 boot flag) - disable CPU scaling - pin benchmark thread to CPU0 - in the test, create a vector - reserve memory for 1M unsigned - write a byte to each page reserved, to warm up the page table - get TSC value (machine has constant_tsc flag) - insert 1M unsigned value - get TSC value again, subtract previous value - repeat test 25 times, average results I do this with 3 containers: std::vector, boost::container::vector and double_ended::devector. While the latter two produces almost equivalent results, std::vector seriously falls behind. - No reallocation happens between the TSC sampling - Test order doesn't matter: every order produces the same results - Container size or sample count doesn't matter, same results. - The deviations of individual measures of each container is small, the performance is consistent. - I compared the produced ASM of std::vector and double_ended::devector, they are very similar, almost the same instructions in different order [2]. What do I miss here? Thanks, Benedek [0]: http://erenon.hu/double_ended/double_ended/benchmarks.html [1]: https://github.com/erenon/double_ended/blob/master/benchmark/push_back.cpp [2]: http://pastebin.com/tUL54i9f

3 11

[RFC] C++ apparently lacks a mechanism for locking ranges of a shared resource
by Raphael S Carvalho 20 Feb '16

20 Feb '16

I am very sorry if this topic is unrelated to the topics covered by this mailing list. While developing a small project which consists of exporting a blockv device via network (if you are curious: https://github.com/raphaelsc/blockv) there was the need to lock a range of a shared resource, such as a file. I searched for resources coming from C++ standard library and boost library, but I wasn't able to find anything that would fit my needs. Am I missing something? Anyway, I ended up implementing my own range locking mechanism. The implementation is quite simple, feel free to look it at: https://github.com/raphaelsc/byte-range-lock-cpp/blob/master/range_lock.hh (I made my best effort to document it well) Is there any chance that something like range_lock will be made available in the next versions of boost library? Thank you very much for reading this, Raphael Carvalho

1 0

Re: [boost] [optional] optional(Expr&&) is insufficiently constrained
by Andrzej Krzemienski 19 Feb '16

19 Feb '16

2016-02-18 23:03 GMT+01:00 Stephan T. Lavavej <stl(a)exchange.microsoft.com>: > Hi, > > A user reported a bug (VSO#191303/Connect#2351203, see [1]) using > Boost.Optional with MSVC 2015 Update 2. The original test case involved a > minor bug in VC's tuple, which I'll look into fixing in the future > (specifically, N-tuples recursively construct (N - 1)-tuples, in a way > that's visible to overload resolution). However, there is also a bug in > boost::optional. > Hi, I have created a ticket abut this problem: https://svn.boost.org/trac/boost/ticket/12002 Frankly, I do not know how to implement it in a portable way (considering older compilers) without type trait boost::is_constructible. I am currently blocked on it: https://svn.boost.org/trac/boost/ticket/12003. As an aside, the "prevent_binding" stuff should probably be expressed as a > SFINAE constraint, not a static_assert. > About this remark, I am not sure. I understand that you want the constructors to be SFINAE-friendly, but at the same time I would loose the opportunity to convey a text message to the user-programmers, as to what the problem is. Now I do it with the static_assert. I wish I had the feature "delete for a reason" Optional::Optional(R&&r) = delete("because it would cause..."); Regards, &rzej

4 5

[iterator] function_output_iterator constructed from a lambda function is not assignable
by Mikhail Matrosov 19 Feb '16

19 Feb '16

Consider the following code snippet: auto f = [](int x) { std::cout << x; };auto it = boost::make_function_output_iterator(f);decltype(it) it2 = it; // Ok, copied it2 = it; // Does not compile, cannot assign! The problem is, function_output_iterator constructed in this way is not assignable, and thus does not satisfy the Iterator <http://en.cppreference.com/w/cpp/concept/Iterator> concept, which requires type to be CopyAssignable <http://en.cppreference.com/w/cpp/concept/CopyAssignable>. This is not a bug, since boost Function Output Iterator documentation <http://www.boost.org/doc/libs/1_60_0/libs/iterator/doc/function_output_iter…> clearly says <http://www.boost.org/doc/libs/1_60_0/libs/iterator/doc/function_output_iter…> : UnaryFunction must be Assignable and Copy Constructible. While assignment operator of a lambda function <http://en.cppreference.com/w/cpp/language/lambda> is deleted: ClosureType& operator=(const ClosureType&) = delete; So this behaviour is technically correct, but for me is somewhat unexpected. I think it is a perfectly reasonable desire to construct function_output_iterator given a closure produced by lambda function. It seems inconvenient to me why this use case causes a problem. Can you suggest a workaround for this situation? Or maybe a way of improving function_output_iterator to overcome this issue? Personally, I came up with a trick to fix this in a situation, when I'm sure iterator and its copies won't outlive the closure object. In this case we may wrap closure with std::ref: auto it = boost::make_function_output_iterator(std::ref(f)); This works quite fine, but obviously is not always possible. Another options is to store closure in std::function: std::function<void(int)> f = [](int x) { std::cout << x; }; This also works fine and is possible in most contexts, but causes related overheads. See also: http://stackoverflow.com/q/35392919/261217 ----- Best regards, Mikhail Matrosov

5 11

[type_traits] A partial implementation of boost::is_constructible
by Andrzej Krzemienski 19 Feb '16

19 Feb '16

I filed a ticket about a potential improvement of type trait boost::is_constructible: https://svn.boost.org/trac/boost/ticket/12003 I am solving the following problem. I have a one-argument perfect forwarding explicit constructor and want to constrain it only to the cases when T is constructible from U: ``` template <typename T> struct optional { template <typename U> explicit optional(U&& v, ENABLE_IF(is_constructible<T, U&&>)) {...} }; ``` I cannot afford to use the "fallback" implementation of boost::is_constructible (the one that forwards to is_convertible) because I would be constraint my constructor too much: I would rather leave it under-constrained. I do not need the full implementation of is_constructible (that would need variadic templates) because I am only using the two-argument version (and I suppose my problem is not isolated). I would like a partial implementation of is_constructible that works correctly for two arguments only; and a macro that allows me to test if it is available. I suspect that this is the common case that you use only the two-argument version, and implementing only this would handle a quite a big number of all the use cases. Is it something that fits into the library scope, or do is it something I would have to implement myself? Regards, &rzej

2 1

[range] range/concepts.hpp errors..
by Rene Rivera 19 Feb '16

19 Feb '16

I'm trying to build the auto_index tool using msvc-14 and I'm getting this error: compile-c-c++ ..\..\..\bin.v2\tools\auto_index\build\msvc-14.0\release\link-static\threading-multi\file_scanning.obj file_scanning.cpp ..\..\..\boost/range/concepts.hpp(184): error C2143: syntax error: missing ';' before '<' ..\..\..\boost/range/concepts.hpp(209): note: see reference to class template instantiation 'boost::range_detail::ForwardIteratorConcept<Iterator>' being compiled ..\..\..\boost/range/concepts.hpp(184): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int ..\..\..\boost/range/concepts.hpp(184): error C2238: unexpected token(s) preceding ';' Any ideas? -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

3 3

[STL + allocators] Bug?
by Phil Bouchard 19 Feb '16

19 Feb '16

This is about STL containers and allocators. It looks like a mistake in the STL containers but I don't think there is any possible workarounds if the Boost library is based on it. When I look at the code of GCC's std::list: template<typename _Tp, typename _Alloc> void _List_base<_Tp, _Alloc>:: _M_clear() { typedef _List_node<_Tp> _Node; _Node* __cur = static_cast<_Node*>(_M_impl._M_node._M_next); while (__cur != &_M_impl._M_node) { _Node* __tmp = __cur; __cur = static_cast<_Node*>(__cur->_M_next); #if __cplusplus >= 201103L _M_get_Node_allocator().destroy(__tmp); #else _M_get_Tp_allocator().destroy(std::__addressof(__tmp->_M_data)); #endif _M_put_node(__tmp); } } I think it should make use of the allocator's specific pointer as such: template<typename _Tp, typename _Alloc> void _List_base<_Tp, _Alloc>:: _M_clear() { typedef _List_node<_Tp> _Node; typedef typename _Alloc::rebind<_Node>::other::pointer _NodePtr; _NodePtr __cur = static_cast<_NodePtr>(_M_impl._M_node._M_next); while (__cur != &_M_impl._M_node) { _NodePtr __tmp = __cur; __cur = static_cast<_NodePtr>(__cur->_M_next); #if __cplusplus >= 201103L _M_get_Node_allocator().destroy(__tmp); #else _M_get_Tp_allocator().destroy(std::__addressof(__tmp->_M_data)); #endif _M_put_node(__tmp); } } Meanwhile I don't think there is any workaround possible for this for use of an allocator with specific pointer in Boost?

3 4

flyweight - gsoc idea - multikey-value flyweight
by Vicente J. Botet Escriba 19 Feb '16

19 Feb '16

Hi Joaquin, I have a use case where I have several keys to the same flyweight. I was trying to associate a multi-index as factory, but I don't see how it could be done. I believe that I would need something like a multikey_value<Value, KeyExtractor1, KeyExtractor2> where KeyK should be deduced from KeyExtractorK. Have you found this use case already? Do you think this could be a good GSoC project? Best, Vicente

3 9

[optional] optional(Expr&&) is insufficiently constrained
by Stephan T. Lavavej 18 Feb '16

18 Feb '16

Hi, A user reported a bug (VSO#191303/Connect#2351203, see [1]) using Boost.Optional with MSVC 2015 Update 2. The original test case involved a minor bug in VC's tuple, which I'll look into fixing in the future (specifically, N-tuples recursively construct (N - 1)-tuples, in a way that's visible to overload resolution). However, there is also a bug in boost::optional. Here's a reduced test case, which contains the relevant parts of boost::optional, and doesn't involve that bug in VC's tuple: C:\Temp>type meow.cpp #include <tuple> #include <type_traits> #include <utility> using namespace std; struct none_t { }; template <typename T> struct optional { T thing; optional(none_t) : thing() { } template <typename Expr, typename = typename enable_if< !is_same<typename decay<Expr>::type, none_t>::value #ifdef FIX && is_constructible<T, Expr>::value #endif >::type> explicit optional(Expr&& expr) : thing(forward<Expr>(expr)) { } }; int main() { tuple<none_t> one{}; tuple<optional<double>> two(one); } C:\Temp>cl /EHsc /nologo /W4 meow.cpp meow.cpp meow.cpp(22): error C2440: 'initializing': cannot convert from 'std::tuple<none_t>' to 'double' [...context...] C:\Temp>cl /EHsc /nologo /W4 /DFIX meow.cpp meow.cpp C:\Temp> This is happening because I implemented N4387 (see [2]) and the Proposed Resolution for LWG 2549 (see [3]). The PR is required to implement N4387 safely. The direct-init of two from one is attempting to select tuple's converting copy ctor (which N4387 marks as implicit, because optional's constructor from none_t is implicit). However, LWG 2549 additionally constrains the converting copy ctor. In English, when the source is tuple<A> and the destination is tuple, LWG 2549 determines whether A is constructible from tuple. If it IS, then the converting copy ctor vanishes, so that tuple's perfect forwarding ctor (tuple(UTypes&&...)) can construct A from tuple. Alternatively, if A ISN'T constructible from tuple, then the perfect forwarding ctor SFINAEs away while the converting copy ctor is permitted to participate, so A is constructed from the B within the tuple. The boost::optional bug is that optional(Expr&&) isn't sufficiently constrained, so it appears to be constructible (via is_constructible) from tuple<none_t>, even though the definition will explode. So LWG 2549 makes tuple's converting copy ctor vanish, and we end up attempting to construct optional<double> from tuple<none_t> which is doomed. This is NOT a problem with LWG 2549's Proposed Resolution, NOR is it a problem in VC 2015 Update 2's tuple (which has correctly implemented this, at least for the 1-tuple case, as previously mentioned). The fix that should be applied to boost::optional is to constrain optional(Expr&&) based on whether its definition will compile. (This is inherently safe, because it just makes is_constructible report accurate answers, and doesn't affect code that previously compiled.) WG21 has (gradually) taught pair/tuple to do this (constructors are now constrained on is_constructible for elements, and additionally is_convertible when they care about implicitness; previously they didn't ask is_constructible). The relevant code in optional.hpp is: template<class Expr> explicit optional ( Expr&& expr, BOOST_DEDUCED_TYPENAME boost::disable_if_c< (boost::is_base_of<optional_detail::optional_tag, BOOST_DEDUCED_TYPENAME boost::decay<Expr>::type>::value) || boost::is_same<BOOST_DEDUCED_TYPENAME boost::decay<Expr>::type, none_t>::value >::type* = 0 ) : base(boost::forward<Expr>(expr),boost::addressof(expr)) {optional_detail::prevent_binding_rvalue_ref_to_optional_lvalue_ref<T, Expr&&>();} Unlike my reduced repro (where is_constructible<T, Expr> is the constraint corresponding to thing(forward<Expr>(expr))), I can't suggest an exact fix without knowing what optional_base's constructor is going to do with the provided arguments. As an aside, the "prevent_binding" stuff should probably be expressed as a SFINAE constraint, not a static_assert. Thanks, STL [1] https://connect.microsoft.com/VisualStudio/feedback/details/2351203/vc14-2-… [2] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4387.html [3] http://cplusplus.github.io/LWG/lwg-active.html#2549

1 0

[Boost.Geometry] Extend spatial predicates to 1D segments?
by Lukas Barth 18 Feb '16

18 Feb '16

Hi, I'm using the rtree in Boost.Geometry to store one-dimensional intervals (as segments of one-dimensional points). There may be better suited libraries out there for this task, but I had Boost.Geometry in my project for some 2D-Rtree anyways, and since it is generic, it should be up to the task. I needed to query the 1D segments in the rtree for overlaps and got a nasty looking "not implemented" error when trying to compile. Basically, this is what I tried to do: typedef bgm::point<double, 1, coordinate_system_type> Point1D; typedef bgm::segment<Point1D> Interval; typedef bgi::rtree<Interval, bgi::quadratic<3>> Tree; mytree.query(bgi::intersects(make_interval(from,to))); (where "make_interval" is a helper that returns an interval from two doubles) Digging through the Boost.Geometry code (and I won't claim I fully understood the template magic), I found in /usr/include/boost/geometry/algorithms/detail/disjoint/linear_linear.hpp the following piece: template <typename Segment1, typename Segment2> struct disjoint<Segment1, Segment2, 2, segment_tag, segment_tag, false> : detail::disjoint::disjoint_segment<Segment1, Segment2> {}; And, more importantly, I did not find a similar piece of code with a "1" as third template parameter. Thus, I assume that the 'disjoint' predicate is just not implemented for one-dimensional segments. I added that predicate for my project, and now I'm wondering whether a full set of spatial predicates would be desirable for one-dimensional segments. In other words: If I came up with a patch adding those predicates, would it be considered? Regards, Lukas

3 2