- Boost - lists.preview.boost.org

[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

[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

remove cached feature checks
by Oliver Kowalke 17 Feb '16

17 Feb '16

Hi, how is it possible to remove the cached feature checks? Boost.Config Feature Check: cxx11_constexpr : no (cached) b2 -a toolset=clang cxxflags="-std=c++11" does not re-check the features. Oliver

4 4