February 2016 - Boost - lists.boost.org

GSOC-2016
by Abhimanyu Shekhawat 27 Feb '16

27 Feb '16

Hi there ! I am Abhimanyu Shekhawat, a sophomore perusing B.E(Hons)Computer Science, Birla Institute of Technology & Science, Pilani - Goa,India. I would like to take part in GSOC Programme 2016 with Boost Community. Actually I am very excited about contributing to open source projects and I already have experiences with some of the college based projects till now.I feel that being able to work in open source community will not only expose me to new learning avenues but will also give me a chance to contribute to the a much larger community. As far as my background is concerned,I have taken a course on Discreet Mathematics and currently perusing a rigorous Algorithm and Data structure course. Also I have got an intermediate level of skill set in C++,C,Java,Android and Mysql while a basic understanding of python. I hope that my skills and enthusiasm will prove an asset to the community.So I will be grateful if you can get me started Thank you :D

3 2

[hana] missing .gitattributes
by Steven Watanabe 26 Feb '16

26 Feb '16

AMDG I just noticed that all the files for hana had \n line endings in my working copy. To fix this I had to copy .gitattributes from the superproject. (Or am I just using git wrong) In Christ, Steven Watanabe

3 5

[log][thread][teeks][igaztanaga] Log & Thread tests failing on MSVC & MinGW
by Andrey Semashev 26 Feb '16

26 Feb '16

Hi, I can see lots of Boost.Log tests are failing on igaztanaga and teeks99-08 testers [1], while the error logs are non-descriptive (show a successful compilation). For some tests the links in the table refer to successful compilation of Boost.Thread, which I can see is failing on the same testers the same way [2]. What's interesting, teeks99-09 testers are green for both libraries. Is there a known problem with Boost.Thread on Windows? Or with these particular testers? If not, is it possible to see the actual failure logs? PS: Disregard the MSVC-7.1 and gcc 3.4 columns. These old compilers I don't expect to work. [1] http://www.boost.org/development/tests/develop/developer/log.html [2] http://www.boost.org/development/tests/develop/developer/thread.html

1 0

toml parser for boost::property_tree
by Auer, Jens 26 Feb '16

26 Feb '16

Hi, is somebody working (or has been) on a property_tree parser for toml (https://github.com/toml-lang/toml)? if not I would give it a try. It looks like a project with reasonable for a single person, but complex enough to involve some interesting components, e.g. boost::spirit. Cheers, Jens -- Jens Auer | CGI | Software-Engineer CGI (Germany) GmbH & Co. KG Rheinstraße 95 | 64295 Darmstadt | Germany T: +49 6151 36860 154 jens.auer(a)cgi.com<mailto:jens.auer@cgi.com> Unsere Pflichtangaben gemäß § 35a GmbHG / §§ 161, 125a HGB finden Sie unter de.cgi.com/pflichtangaben<http://de.cgi.com/pflichtangaben>. CONFIDENTIALITY NOTICE: Proprietary/Confidential information belonging to CGI Group Inc. and its affiliates may be contained in this message. If you are not a recipient indicated or intended in this message (or responsible for delivery of this message to such person), or you think for any reason that this message may have been addressed to you in error, you may not use or copy or deliver this message to anyone else. In such case, you should destroy this message and are asked to notify the sender by reply e-mail.

1 0

[interval] rounded_arith_opp doesn't work in Release configuration under msvc 14
by Peter Azmanov 25 Feb '16

25 Feb '16

Hello, Interval calculations with rounded_arith_opp in Release configuration under msvc 14 result in zero-size intervals. For example consider following: #include <iostream> #include <boost/numeric/interval.hpp> int main(int argc, char * argv[]) { unsigned int ctrl = _control87(0, 0); _control87(_EM_INEXACT | _RC_UP, _MCW_EM | _MCW_RC); using namespace boost::numeric::interval_lib; typedef typename unprotect< boost::numeric::interval<double> >::type interval_t; interval_t test = interval_t(1.) / interval_t(3.); std::cout << "test.lower() != test.upper(): " << std::boolalpha << (test.lower() != test.upper()) << std::endl; return 0; } This test unexpectedly prints: test.lower() != test.upper(): false Tested on x64 platform with /fp:strict and /fp:precise under MS Visual Studio Community 2015 Version 14.0.24720.00 Update 1, Boost 1.60. I've already reported this to https://svn.boost.org/trac/boost/ticket/12018 There you can find some details of what I think is going wrong and proposed workaround patch. I didn't create pull request because I'm not sure if my patch is a correct workaround. Maybe someone will propose more appropriate solution. Best regards, Peter Azmanov.

1 0

Re: [boost] Removal of boost::basic_string_ref (in favor of basic_string_view)
by Bjorn Reese 25 Feb '16

25 Feb '16

On 02/17/2016 08:52 PM, Marshall Clow wrote: > I have just removed boost::basic_string_ref from the develop branch, and > updated the specializations to use basic_string_view. I am against this decision. I am using basic_string_ref<> quite heavily in several projects that have work with Boost 1.55 and newer.

4 4

[spirit] develop test problems
by Robert Ramey 24 Feb '16

24 Feb '16

For some time now, the serialization library fails to compile on the develop branch. The test matrix for some platforms indicates syntax error in some spirit file. On other platforms, the library build is reported to "succeed" but the it still seems that library build fails. This error also shows up in the spirit library tests. see http://www.boost.org/development/tests/develop/developer/output/teeks99-09e… Is there any time frame for addressing this? It's currently creating test failures on library which depend directly or indirectly on spirit/classic. Robert Ramey

3 3

[geometry][pool][ptr_container][typeof][auto_index][quickbook] Merge to master planned for release?
by Rene Rivera 24 Feb '16

24 Feb '16

There are some changes I did to the cited libraries and tools to deal with some release build infrastructure. I need to know if the maintainers of them are going to merge their respective develop branches to master? I need to know so that I can move forward as quickly as possible to generating CI release packages for the upcoming 1.61 release. Note: If I don't hear soon I might need to do some merging myself on your libraries/tools and end up messing something up ;-) So I would prefer if the maintainers do it. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

4 9

Regression impacting chrono
by Raffi Enficiaud 23 Feb '16

23 Feb '16

Dear all, There is a regression between 180bee and 372c53 on VS, and apparently boost.chrono (and indirectly boost.test...) is impacted: See http://www.boost.org/development/tests/develop/developer/output/teeks99-08e… trace below: ================= cl /Zm800 -nologo @"D:\t08\run\results\boost\bin.v2\libs\chrono\build\msvc-12.0\dbg\adrs-mdl-64\lnk-sttc\thrd-mlt\process_cpu_clocks.obj.rsp" process_cpu_clocks.cpp D:\t08\run\boost_root\boost/system/error_code.hpp(431) : error C2872: 'detail' : ambiguous symbol could be 'boost::detail' or 'boost::operators_impl::detail' ================= Between those 2 revisions, there were updates on - context - dll - system - utility - winapi Thanks, Raffi

2 2

[utility] Re: Massive test failures due to ambiguous namespace
by Rene Rivera 23 Feb '16

23 Feb '16

On Tue, Feb 23, 2016 at 1:31 PM, Markus Trippelsdorf <markus(a)trippelsdorf.de > wrote: > http://www.boost.org/development/tests/develop/developer/summary.html > show many "fails" due to: > > In file included from ../libs/chrono/src/process_cpu_clocks.cpp:17: > In file included from > ../boost/chrono/detail/inlined/process_cpu_clocks.hpp:19: > In file included from ../boost/chrono/process_cpu_clocks.hpp:22: > In file included from ../boost/chrono/detail/system.hpp:12: > ../boost/system/error_code.hpp:431:15: error: 'detail' is not a class, > namespace, or scoped enumeration > { return *detail::throws(); } > ^ > ../boost/system/error_code.hpp:431:15: error: reference to 'detail' is > ambiguous > { return *detail::throws(); } > ^ > ../boost/system/error_code.hpp:421:13: note: candidate found by name > lookup is 'boost::detail' > namespace detail { inline system::error_code * throws() { return 0; } } > ^ > ../boost/operators.hpp:658:11: note: candidate found by name lookup is > 'boost::operators_impl::detail' > namespace detail > ^ > 2 errors generated. > Also.. This is affecting general building of release packages. First time it showed up was with this superproject update < https://travis-ci.org/boostorg/boost/jobs/111041426>. Please fix ASAP! -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

2 2

Massive test failures due to ambiguous namespace
by Markus Trippelsdorf 23 Feb '16

23 Feb '16

http://www.boost.org/development/tests/develop/developer/summary.html show many "fails" due to: In file included from ../libs/chrono/src/process_cpu_clocks.cpp:17: In file included from ../boost/chrono/detail/inlined/process_cpu_clocks.hpp:19: In file included from ../boost/chrono/process_cpu_clocks.hpp:22: In file included from ../boost/chrono/detail/system.hpp:12: ../boost/system/error_code.hpp:431:15: error: 'detail' is not a class, namespace, or scoped enumeration { return *detail::throws(); } ^ ../boost/system/error_code.hpp:431:15: error: reference to 'detail' is ambiguous { return *detail::throws(); } ^ ../boost/system/error_code.hpp:421:13: note: candidate found by name lookup is 'boost::detail' namespace detail { inline system::error_code * throws() { return 0; } } ^ ../boost/operators.hpp:658:11: note: candidate found by name lookup is 'boost::operators_impl::detail' namespace detail ^ 2 errors generated. -- Markus

1 0

boost::container::set insert range bug
by Han Wang 23 Feb '16

23 Feb '16

Hi, Let's say we have some simple code here. boost::container::set<int> s; boost::container::set<int> const sp; s.insert(boost::begin(sp), boost::end(sp)); This insert call will cause "ambiguous call to overloaded function". Best regards, Han

2 1

GSoC Project Proposal - Boost Document Library Extensions
by Anurag Ghosh 23 Feb '16

23 Feb '16

Hello everyone! I wished to propose continue working on the Boost Document Library as a part of the Google Summer of Code 2016, and would like to work on the following things this summer on the library which was started last summer - 1. Integrating Basic Chart Support. 2. Writing comparators for the cells. (Cells are heterogeneous in nature, similar to Boost.Variant) 3. Making cell class have the behavior of a reference to the document's cell. 4. Basic formatting options for cell contents. Kindly make appropriate suggestions to my proposal. The aim of the proposal is to make it a Boost-Ready library. I would remind everyone that the library in its current state has basic spreadsheet functionality like opening, closing and exporting documents, sheet operations and cell,row,column (iterators) operations for Linux and Windows through wrappers over LibreOffice and Microsoft Office API's. ( https://github.com/BoostGSoC15/boost-document) I have been inactive for sometime, but I hope to improve test coverage before March and fix some other issues. Thanks Anurag Ghosh researchweb.iiit.ac.in/~anurag.ghosh

1 0

[Core] BOOST_TRY/BOOST_CATCH
by Chris Glover 22 Feb '16

22 Feb '16

Hi, I ran into a problem when trying to use BOOST_TRY/BOOST_CATCH to add no-exception support to property tree. Here's an example of the original code; try { write_ini(stream, pt, flags); } catch (ini_parser_error &e) { BOOST_PROPERTY_TREE_THROW(ini_parser_error( e.message(), filename, e.line())); } I converted this code to use the macros from core/no_exception_support.hpp *BOOST_TRY *{ write_ini(stream, pt, flags); } *BOOST_CATCH *(ini_parser_error &e) { BOOST_PROPERTY_TREE_THROW(ini_parser_error( e.message(), filename, e.line())); } *BOOST_CATCH_END* The issue is that now the exception, ini_parser_error& e, is not defined when I compile with exceptions off. I solved this by adding a local instance of ini_parser_error above the try block *ini_parser_error e("", "", 0);* BOOST_TRY { write_ini(stream, pt, flags); } BOOST_CATCH (ini_parser_error &e) { BOOST_PROPERTY_TREE_THROW(ini_parser_error( e.message(), filename, e.line())); } BOOST_CATCH_END This is a little gross, but it's not too bad and I was expecting the variable to be optimized away. But it isn't -- instantiating that exception on the stack is very clearly generating instructions on VS2015 and GCC 5.3. While this is not a huge deal, I don't like it so one way I can think to fix this is to conditionally compile out the catch block, but that defeats the purpose of the macros in the first place. BOOST_TRY { write_ini(stream, pt, flags); } BOOST_CATCH (ini_parser_error &e) { *#ifdef BOOST_NO_EXCEPTIONS* BOOST_PROPERTY_TREE_THROW(ini_parser_error( e.message(), filename, e.line())); *#endif* } BOOST_CATCH_END Then I thought maybe I can declval a fake 'e' in the else block by redefining the macros as follows; #ifndef BOOST_NO_EXCEPTIONS #define BOOST_TRY { try { #define BOOST_CATCH(type, var) } catch(type var) { #define BOOST_CATCH_END } } #else #define BOOST_TRY { if(true) { #define BOOST_CATCH(type, var) } else if(false) { type var = boost::declval<type>(); #define BOOST_CATCH_END } } #endif This is working, but is possibly undefined behaviour. Does anyone have thoughts on that? It also requires splitting up the type from the variable name. The next step to this would be to add a third parameter for some constructor args so we can just create an exception object directly. Something like: #define BOOST_CATCH(exception_type, var, args) } else if(false) { boost::decay<exception_type>::type var args; So now the original code would look like this: BOOST_TRY { write_ini(stream, pt, flags); } BOOST_CATCH (ini_parser_error&, e, ("", "", 0)) { BOOST_PROPERTY_TREE_THROW(ini_parser_error( e.message(), filename, e.line())); } BOOST_CATCH_END This is starting to look a little nasty to me so I'm wondering if anyone has any thoughts on this? Should I stop worrying about it and just use the #ifdef? The reality is that I work in an environment without exceptions and we hit these things from time to time so I'd like to fix up as many as possible. Thanks, -- chris

2 2

media file error
by Rainer Deyke 21 Feb '16

21 Feb '16

In "CDs/Presumed Guilty Compilation": "Beyond Dwan - Need.mp3" -> "Beyond Dawn - Need.mp3" -- Rainer Deyke (rainerd(a)eldwood.com)

1 0

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