- Boost - lists.preview.boost.org

[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

[gsoc16] [Boost.GIL] gsoc idea - further development on Boost.GIL
by Christopher Harpum 18 Feb '16

18 Feb '16

Dear Boost, Pre-warning, this is my first time actively engaging in the mailing list - I primarily stick to the archives - so excuse me for anything non-conformat. I'm a student looking to forward a proposal regarding further development of Boost.GIL. Namely: - Cleaning up some bugs / oversights within the current review branch (lack of colour-conversion profiles for certain formats, uninitialized values resulting in UB for BMP palette alpha channels, etc.) - Fulfilling additional features and clean-up, as requested during the formal review (2010) http://lists.boost.org/boost-announce/2011/01/0281.php - Looking into further development of the io_factory proposal for run-time file format detection (http://stlab.adobe.com/wiki/index.php/GIL_File_Format_Import/Export_Factory ,POC implementation https://github.com/stlab/adobe_platform_libraries/tree/master/adobe/gil/exte nsion/asl_io) I use Boost.GIL extensively within my projects, so I've had a reasonable amount of time to get accustomed to the code-base and believe this will help me achieve these goals. I understand that the project has been undergoing a period of inactivity, so I'm not sure whether this proposal would find a suitable mentor, or if it will be of interest for a GSOC project. I hope to further discussion of this proposal prior to submitting anything formal, though I'm not fully aware of the procedures for independent submissions. Regards, Chris

2 1

[MSM] Is there any interest in C++14 Boost.MSM-eUML like library which compiles up to 60x quicker whilst being a slightly faster too?
by Krzysztof Jusiak 18 Feb '16

18 Feb '16

Dear Boosters, I have recently released 1.0.0 version of experimental C++14 Boost.MSM-lite. Your scalable C++14 header only eUML-like meta state machine library with no dependencies, which outperform Boost.MSM - eUML in: - faster compilation times - up to 60x times faster! - smaller executable size - up to 15x smaller - slightly better performance - smaller memory usage - short error messages Check it out yourself online! http://boost-experimental.github.io/msm-lite/examples/index.html#hello-world Performance Results: http://boost-experimental.github.io/msm-lite/overview/index.html#performance Source code: https://github.com/boost-experimental/msm-lite Documentation: http://boost-experimental.github.io/msm-lite Any feedback is more than welcome! Cheers, Kris

7 58

GSOC 2016
by Boldy Happy 18 Feb '16

18 Feb '16

Hello!I would like to know if Boost is participating in GSOC 2016.Please excuse if me if I made a mistake by sending this kind of email as I am just a beginner. Thanks in advance!

1 0

Interest in double ended containers
by Benedek Thaler 18 Feb '16

18 Feb '16

Dear Boost, I'd like to draw attention to my double_ended library, founded by GSoC 2015. It provides two containers, briefly described below. Given there's interest, I'd like to propose this library later. Documentation: http://erenon.hu/double_ended/ Source: https://github.com/erenon/double_ended Short overview: `devector` is a hybrid of the standard vector and deque containers, as well as the `small_vector` of Boost.Container. It offers cheap (amortized constant time) insertion at both the front and back ends, while also providing the regular features of `std::vector`, in particular the contiguous underlying memory. In contrast to the standard vector, however, `devector` offers greater control over its internals. Like `small_vector`, it can store elements internally without dynamically allocating memory. `batch_deque` is very similar to the standard `deque`, with a slight twist. It lets you specify its segment size: The size of the contiguous memory segments it uses to store its elements. This provides a consistent layout across platforms, and lets you iterate over the segments with batch operations. Thanks, Benedek

4 4

[block_ptr] Use case bug
by Phil Bouchard 18 Feb '16

18 Feb '16

In trying to anticipate all possible use cases, I think I have found a bug. Please let me try to fix it, but this is not so simple so it'll take some time.

1 1

[githelp]
by Rene Rivera 17 Feb '16

17 Feb '16

How can I find out what changes are not merged from develop to master, for all subrepos, but only changes I've made? -- -- 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

Removal of boost::basic_string_ref (in favor of basic_string_view)
by Marshall Clow 17 Feb '16

17 Feb '16

I have just removed boost::basic_string_ref from the develop branch, and updated the specializations to use basic_string_view. Code that uses boost::string_ref (and wstring_ref) should continue to work as before. The basic_string_view class better matches what the standards committee is doing and has WAY more constexpr support. I'll be watching the testbots for results, but I believe that the only part of boost that was using basic_string_ref was Boost.Log, and that was switched over to basic_string_view in December. -- Marshall

2 1

Boost.Operators issue: polluting namespace of caller through argument-dependent lookup
by John M. Dlugosz 17 Feb '16

17 Feb '16

Here's the problem I ran into http://stackoverflow.com/questions/34449254/how-is-argument-dependent-looku… |usingstd::tr1::shared_ptr; ||usingstd::tr1::make_shared;| |shared_ptr<Dog>Gamma::knockout (constHotel&target){Eggsoftboiled (target.ID);softboiled.sequence ^=0x40000000;returnmake_shared<Dog>(softboiled,target.kin,Frank::myself());} | The arguments to the constructor passed through make_shared are of types |Able::Bravo::Charlie::Egg&,constuint32_t&,constFrank&| The use of make_shared is finding boost::make_shared as well as std::make_shared. The program doesn't use boost::shared_ptr and shouldn't need to know about it. It turns out that Frank is derived privately from boost::totally_ordered1 (and and Egg from boost::totally ordered). Some Boost header that's being used in this translation unit just happens to pull in Boost's shared_ptr stuff. It ends up effectively polluting the namespace of possible calls involving these types, thanks to argument-dependent lookup. Furthermore, which Boost headers include which will change from version to version. I have this problem show up much more in Boost 1.60 than I have in Boost 1.59. There is no easy way around it beyond qualifying the call make_shared, and I specifically want to avoid that so I don't litter the program with tr1's (this varies by compiler and version as to whether tr1 is required, prohibited, or optional, so I want it in one place.) I believe the proper thing to do, which is a very simple fix actually, is to define the mix-in classes like totally_ordered (and other things from Boost.Operators in particular) in a unique inner namespace, and then make aliases in the boost namespace where they are published as being found. namespace boost { *namespace inner_name_1 { * template<typename T, Typename U> partially_ordered { ⋯ }; // the entire guts of Boost.Operators can go here, I think. *} // end of inner isolating namespace** ** ** using inner_name_1::partially_ordered;* // etc. } This inner isolation technique should be SOP for any classes that are meant to be inherited from by user (non-Boost library) code. It would not hurt to also isolate classes that match the names of std library code, in general! This would, in general, prevent the libraries from interfering with each other and surprises popping up when using std components and pulling in Boost headers. —John ||

4 12