July 2016 - Boost - lists.preview.boost.org

A GUI Library
by jinhao 09 Nov '17

09 Nov '17

Hi, all I am developing a GUI library, it takes aim at easy-to-use and portable library for modern C++ methods. The project at http://stdex.sourceforge.net A git repository at http://nanapro.codeplex.com A brief at http://nanaproject.wordpress.com/2011/12/16/preliminary-study-of-nana-c-lib… Is there any interest in this library? Regards Jinhao

8 8

Re: [boost] Boost CRC maintainer (Daryle Walker) missing in action?
by Olaf van der Spek 19 Jun '17

19 Jun '17

Hi Daryle, Any luck on your new setup? Gr, Olaf On Mon, Nov 28, 2011 at 1:11 AM, Daryle Walker <darylew(a)gmail.com> wrote: > I can look at it once I've finished my new setup. > > I had to reset my computer after a partial crash years ago. I never > got around to recreating my programming setup. My computer had been > at its maximum Operating System level back then, which is now 3 > versions behind. For the past few months, I've had my sister's old > laptop, with Windows Vista, and am trying to add a programming setup > to it now. > > > On Tue, Nov 22, 2011 at 7:18 AM, Beman Dawes <bdawes(a)acm.org> wrote: >> Hi Daryle, >> >> This guy has volunteered to take over maintenance of Boost CRC. Should >> we take him up on his offer? > >> ---------- Forwarded message ---------- >> From: >> Date: Wed, Nov 2, 2011 at 7:51 AM >> Subject: [boost] Boost CRC maintainer (Daryle Walker) missing in action? >> To: boost(a)lists.boost.org >> >> >> Hi, >> >> It looks like the Boost CRC maintainer (Daryle Walker) is missing in action? >> >> No response to tickets from the past 3 years. What's the procedure in this case? >> >> https://svn.boost.org/trac/boost/ticket/2492 >> https://svn.boost.org/trac/boost/query?component=crc&col=id&col=summary&col… > > -- > Daryle Walker > Mac, Internet, and Video Game Junkie > darylew AT gmail DOT com -- Olaf

2 2

[msm] [statechart] unmerged PRs
by András Kucsma 23 May '17

23 May '17

Hi Everyone, There are a couple of PRs for msm and statechart by me and others, which didn't get any attention for many months now. Can the maintainers please take a look at them? https://github.com/boostorg/msm/pulls https://github.com/boostorg/statechart/pulls Thank you, Andras

2 2

[clang] clang-cl expansion of macros
by Edward Diener 29 Apr '17

29 Apr '17

You can get clang-cl ( clang-win ) to show its VC++ emulated expansion of macros somewhat by passing the c++ option '-fmacro-backtrace-limit=0' to the compiler. It is still blessedly difficult to see the what and the why of clang's error messages when expanding macro using clang-cl, but at least it gives you a better chance of understanding where clang's emulation of VC++ has gone wrong. I have posted bug 27380 to the llvm/clang bug tracker at https://llvm.org/bugs/show_bug.cgi?id=27380 showing the main failure in VC++ emulation which I see when testing Boost PP with clang-cl.

3 8

[container] moving a pre-built vector into a flat_set
by Sam Kellett 12 Mar '17

12 Mar '17

a common problem i encounter is that i have two stage's w/r/t to a large collection of data: building and querying. vector is obviously the king of building. flat_set is the king of querying. so what i often tend to do is build up a very large vector, sort it then create a flat_set using the flat_set(ordered_unique_t) constructor. however this still copies the entire vector into the flat_set, right? what i would like to be able to do is move the vector straight into the flat_set, something like: std::vector<T> data; flat_set data_set1(std::move(data)) // move vector in and sort it // or: std::sort(data.begin(), data.end()); // sort vector flat_set data_set2(ordered_unique_t, std::move(data)) // and move it in is this doable (am i just being blind?) or is there plans/interest for this?

8 19

[nowide] Library Updates
by Artyom Beilis 04 Mar '17

04 Mar '17

Hello, Disclaimer: --------------- I recently discovered that virtually all e-mails sent from Yahoo account to any mailing lists go to user's spam due to recent Yahoo's DMARC policy. So I'm sending some important stuff from GMail account that almost certainly was missed: What is Boost.Nowide: -------------------------------- Boost.Nowide is a library that make cross platform Unicode aware programming easier. The library provides an implementation of standard C and C++ library functions, such that their inputs are UTF-8 aware on Windows without requiring to use Wide API. It was inspiration and inspired by http://utf8everywhere.org/ development ideas and policy. Some updates regarding Boost.Nowide ------------------------------- 1. Library moved to github and its format is converted to modular boost layout: https://github.com/artyom-beilis/nowide 2. Fixed unsupported std::ios::ate flag by boost::nowide::fstream 3. Added some C++11 interfaces to boost::nowide::fstream 4. Added integration functionality with boost::filesystem: https://github.com/artyom-beilis/nowide/blob/master/include/boost/nowide/in… Note: that the links to the source code on review schedule aren't relevant, it should be: - Code: https://github.com/artyom-beilis/nowide - Documentation: http://cppcms.com/files/nowide/html/ Also the library is still looking for review manager. Artyom Beilis P.S.: I'm sorry if you are getting this as "duplicate"

2 1

bad include guards
by Steven Watanabe 26 Jan '17

26 Jan '17

AMDG The following pairs of files have identical include guards ./boost/concept_check/general.hpp ./boost/concept/detail/msvc.hpp ./boost/concept_check/msvc.hpp ./boost/concept/detail/msvc.hpp ./boost/filesystem/cerrno.hpp ./boost/cerrno.hpp ./boost/interprocess/containers/tree.hpp ./boost/interprocess/containers/detail/tree.hpp ./boost/mpl/min_max.hpp ./boost/mpl/max.hpp ./boost/mpl/vector/aux_/front.hpp ./boost/mpl/list/aux_/front.hpp ./boost/multi_index/identity_fwd.hpp ./boost/multi_index/identity.hpp ./boost/python/pointee.hpp ./boost/python/detail/pointee.hpp ./boost/spirit/phoenix/closures.hpp ./boost/lambda/closures.hpp ./boost/xpressive/proto/v1_/proto_typeof.hpp ./boost/xpressive/proto/proto_typeof.hpp ./libs/config/test/boost_no_dep_nested_class.ipp ./libs/config/test/boost_has_vc6_mem_templ.ipp ./libs/config/test/boost_no_mem_templates.ipp ./libs/config/test/boost_has_vc6_mem_templ.ipp ./libs/config/test/boost_no_std_allocator.ipp ./libs/config/test/boost_has_vc6_mem_templ.ipp ./libs/conversion/test.hpp ./libs/any/test.hpp ./libs/interprocess/example/print_container.hpp ./libs/interprocess/example/printcontainer.hpp ./libs/interprocess/test/expand_bwd_test_template.hpp ./libs/interprocess/test/allocation_test_template.hpp ./libs/interprocess/test/printcontainer.hpp ./libs/interprocess/example/printcontainer.hpp ./libs/interprocess/test/print_container.hpp ./libs/interprocess/example/printcontainer.hpp ./libs/iostreams/test/detail/utf8_codecvt_facet.hpp ./boost/detail/utf8_codecvt_facet.hpp ./libs/regex/test/regress/test_regex_search.hpp ./libs/regex/test/regress/test_partial_match.hpp ./libs/serialization/test/C.hpp ./libs/serialization/test/A.hpp ./libs/xpressive/perf/regex_comparison.hpp ./libs/regex/performance/regex_comparison.hpp ./tools/inspect/time_string.hpp ./tools/common/time_string.hpp In Christ, Steven Watanabe

5 8

Generating Boost documentation with pandoc
by Vinícius dos Santos Oliveira 18 Jan '17

18 Jan '17

Has anyone tried to generate Boost-styled documentation using pandoc? I never fully liked PDF documentation because I never actually print documentation. However, a few weeks ago I got an ebook reader and I've been fascinated by the ePUB format. I'm using it to read even the IETF's RFCs and it's very pleasant. I'm using ePUB to read files even on my usual laptop. Anyway, I was wondering how nice would be to have an ePUB file containing the whole Boost documentation. pandoc has docbook support as one of its input formats and is capable of generating great ePUB output. -- Vinícius dos Santos Oliveira https://vinipsmaker.github.io/

7 27

[MPL] A Proposal
by Bruno Dutra 16 Nov '16

16 Nov '16

Dear Community, About a year ago today, there was a proliferation of threads [1][2][3] in this mailing list concerning the future of Boost.MPL, or even whether it had a future at all, and opinions diverged widely on the matter. Many have expressed concerns about the fact Boost.MPL was long outdated and proposed major changes to open path for modernization, while some others argued against it, fearing unexpected and disastrous side-effects could propagate throughout the rest of Boost. A few questioned if it was worth it at all to spend any further resources on Boost.MPL given the fact new alternatives were coming up, such as Boost.Hana, which departed entirely from template metaprogramming, yet some argued TMP remained a competitive alternative for type computations in C++14 as it has been demonstrated by Peter Dimov in his impressive articles [4] on modern TMP. Amidst all this, a proposal by Robert Ramey [5] caught my attention and inspired me to develop what I call Metal [6], a template metaprogramming library designed on the same core principles as Boost.MPL, but written from the very beginning to take full advantage of C++11. Metal was not designed to be a strict drop in replacement for Boost.MPL though, it was rather meant to be regarded as a modern version of Boost.MPL's original API, diverging only where it could really benefit from modern C++ and that essentially means gains of several orders of magnitude in performance** and lower memory consumption. At this point Metal is very close to where I originally intended to bring it and I think it's time I gauge interest from the community on a modest proposal I've been maturing along the past year. As a modern approach to the same task that Boost.MPL was meant to address, I don't believe Boost would benefit at all from yet another TMP library that would essentially compete with Boost.MPL and even Boost.Hana in some cases, specially as maintainers of older code that depends on Boost.MPL would have to go through major refactoring efforts in order to benefit from such an addition to Boost. I would like to propose something different instead. My proposal is to make Metal officially into a new revision of Boost.MPL's API, essentially MPL2 as the original proposal by Robert Ramey put it, merging both into one single TMP library. The idea would be to provide a thin proxy for the current Boost.MPL API which would have two backends configurable by preprocessor switches: the original implementation and a another one based on Metal. This way older code using Boost.MPL could see immediate gains on performance by selecting the newer backend on supported compilers, while at the same time legacy code maintained on older compilers could still rely on Boost.MPL's impressive ability to run virtually anywhere. On the other hand, newer projects interested on pure type computations would have the newer API entirely available to them. This proposal also overcomes the problem of dealing with the maintainability of Boost.MPL, since it provides a way for smooth transition from legacy hacks required by ancient compilers into a cleaner and easier to maintain C++11 codebase, besides avoiding any breaking changes within existing code in the process. Furthermore, should this proposal make it into Boost, I would be naturally willing to take responsibility for the maintenance of Boost.MPL, which AFAIK has been maintained by the CMT for quite some time now, often with limited resources. Comparing Metal and Boost.MPL there are a few noteworthy differences. Metafunction Classes have proven themselves entirely unnecessary and have thus been removed altogether in favour of pure Lambdas (in the Boost.MPL sense). Moreover, iterators make little sense in a functional world, so these too have been removed despite the fact they may easily be emulated in the new design. Moreover Metal develops the concept of optionals, that is, its metafunctions only have a nested ::type defined when they may be successfully computed, what may be safely tested using metal::is_just and may also be used to SFINAE out of miscomputations. Finally I'd like to point out that Metal was designed to be portable across as many compilers as possible and three of the most popular ones are continuously tested using Travis and Appveyor: Clang 3.5+, GCC 4.8+ and MSVC 14 (2015). I hope this is a reasonable proposal and I look forward into your opinions about it. ** Even though I haven't published any benchmarks yet, an example follows just to back my claims regarding performance (just tested on my personal laptop running linux): //Generate a list containing 10 thousand instances of std::integral_constant, from 0 to 9999 using l = metal::enumerate_t<metal::integer<10000>>; // GCC 5.3 ~0.4 s // Clang 3.7 ~0.5 s //Transform a list containing 5 thousand numbers by squaring each element using l1 = metal::enumerate_t<metal::number<long long, 5000>>; using l2 = metal::transform_t<metal::pow<metal::_1, metal::integer<2>>, l1>; // GCC 5.3 ~5.6 s // Clang 3.7 ~3.0 s [1]: http://thread.gmane.org/gmane.comp.lib.boost.devel/257680 [2]: http://thread.gmane.org/gmane.comp.lib.boost.devel/257983 [3]: http://thread.gmane.org/gmane.comp.lib.boost.devel/258843 [4]: http://pdimov.com/cpp2/simple_cxx11_metaprogramming.html [5]: http://rrsd.com/blincubator.com/bi_suggestion/mpl-lite-or-mpl2/ [6]: http://brunocodutra.github.io/metal/ Regards, Bruno Dutra

12 48

Fuzzy string search to the Boost String Algortihm
by Зайцев Александр 19 Sep '16

19 Sep '16

Hello. I want to discuss about some proposals. I am working on Levenshtein distance and Damerau-Levenshtein distance algortihms. I hope, that these implementations will be pulled to the Boost String library. But i think that we can add to the Boost String Library some more algorithms for fuzzy searhing. I mean these algortihms: Levenshtein distance Damerau-Levenshtein distance Bitap algorithm with modifications by Wu and Manber Spell-checker method N-gram method Signature hashing method BK-trees What do you think about this idea? If you think that it can be implemented to the Boost String Algo, i will start work on this list immediately. Best regards, Zaitsev Alexander.

2 2

Gmane going away
by Tom Kent 07 Sep '16

07 Sep '16

So it looks like Gmane is under attack and the guy who runs it is thinking about just turning it off (that would be sad). https://lars.ingebrigtsen.no/2016/07/28/the-end-of-gmane/ Anyway, I know a lot of boost users use is as the gnu mailman archive pages are really hard to use. I would like to propose that we (specifically the list owner(s)) mirror the boost mailing lists to the mail-archive.com site. It has good search features and decent thread browse-ability. Thoughts? Tom

8 9

Re: [boost] double_ended - request formal review
by Mathias Gaunard 23 Aug '16

23 Aug '16

On 15 July 2016 at 16:51, Benedek Thaler <thalerbenedek(a)gmail.com> wrote: > Dear Boost, > > I'd like to request the review of the double_ended library. > > Code: https://github.com/erenon/double_ended > Documentation: http://erenon.hu/double_ended > > The library contains two classes. Excerpt from the documentation: > > * `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. Not related to your request per-se, but I think this occasion is as good as any to discuss the library. devector is an interesting variant of vector, but it gives the illusion that is could be used as a queue. However given the implementation, it seems elements removed from either end will never be reclaimed. I suggest documenting that limitation or having a threshold above which memory is actually freed.

4 5

[CallableTraits] Seeking Review Manager
by Barrett Adair 23 Aug '16

23 Aug '16

Boost Developers, CallableTraits is a C++11/14/17 library for the inspection, synthesis, and decomposition of callable types. CallableTraits aims to be the "complete type manipulation facility for function types" mentioned in the final paragraph of C++17 proposal p0172. Library: https://github.com/badair/callable_traits Docs: http://badair.github.io/callable_traits/doc/html/index.html Boost Library Incubator: http://blincubator.com/bi_library/callabletraits-2/?gform_post_id=1574 Current Version: 1.0.1 I've received some great feedback on the mailing list. I consider the current version to be production-ready, which includes excellent cross-platform test coverage and thorough documentation filled with examples. Does anyone wish to be a review manager for this library? It is not a very large codebase, although the implementation is config-heavy and relatively noisy. The Library Submissions page on the Boost website indicates that a library manager should be found before requesting a formal review, but I noticed that there are many "scheduled reviews" that do not have a library manager. May I request a review as well? Thank you, Barrett

3 3

[graph] Sync develop with master?
by Murray Cumming 12 Aug '16

12 Aug '16

Now that Boost 1.61 is out, it would be great if the various fixes in boost graph's develop branch could be merged/cherry-picked/whatever to master, please. There seem to be a couple of years of fixes that have not appeared in a release. -- Murray Cumming murrayc(a)murrayc.com www.murrayc.com

5 21

[boost-process] Beta & Review
by Klemens Morgenstern 07 Aug '16

07 Aug '16

Hi, boost-process is now in beta, you can check it out here: https://github.com/klemens-morgenstern/boost-process and read the doc here: http://klemens-morgenstern.github.io/process/ It will probably be in review in the beginning of November, Antony Polukhin will be the review manager. I really hope I'll get some feedback before that, so I can work on the weak points and also get more detailed in the documentation. Thanks, Klemens

4 10

Review Schedule and Review Manager for PODs Flat Reflection (ex magic_get)
by Antony Polukhin 05 Aug '16

05 Aug '16

Hello, PODs Flat Reflection (or PFR) is a C++14 library that represents POD structures as tuples and provides tuple-like methods for PODs. Library has a set of predefined operators for PODs and useful functions for everyday use. Works with user-defined types without any macro or boilerplate code. Library: https://github.com/apolukhin/magic_get Docs: http://apolukhin.github.io/magic_get/ Boost Library Incubator: http://blincubator.com/bi_library/pfr-pod-flat-reflection/?gform_post_id=16… Could the PODs Flat Reflection library be put on review schedule? Anyone wishing to become a Review Manager for the library? -- Best regards, Antony Polukhin

6 9

[config] RFC PR 82
by Domagoj Saric 01 Aug '16

01 Aug '16

Hi everyone, I am finally getting back to (trying to) contributing some of my personal projects to Boost. For two of those, Err (https://github.com/psiha/err) and especially Functonoid (a C++11 generalization and rewrite of my previous Boost.Function related work) I need some lower level codegen and/or optimiser control functionality (i.e. portable macros wrapping toolset specific attributes and pragmas) that I've added to my personal fork of Boost.Config and which I've now submitted in the subject PR (https://github.com/boostorg/config/pull/82) I don't expect this PR to be accepted as is/'just like that' so I'm opening this thread where we can discuss which of those changes/macros are welcome, which need more work and which, for some reason, should not be part of Boost.Config (and which, in turn then, I have to move to some 'internal implementation headers' in libraries that will need them). To avoid 'spamming' (and save time;) I'll skip the explanation of the individual macros as I expect them to mostly be self-explanatory (if not from their name then from the minimal Boost.Config documentation additions that are part of th PR). ps. I'll be on the (off) road for the next three weeks so I don't know when I'll be able to respond until I get back... -- "What Huxley teaches is that in the age of advanced technology, spiritual devastation is more likely to come from an enemy with a smiling face than from one whose countenance exudes suspicion and hate." Neil Postman

8 31

constexpr, cmath functions and other functions and distributions
by Paul A. Bristow 01 Aug '16

01 Aug '16

After much head scratching (and some head banging) - against a string of "Computer Says No" inscrutable diagnostic messages. I believe that I have now produced a (partial) version of Boost.Math normal_distribution that can be a constexpr using GCC6.1.1. (diagnosis has got to improve if constexprizing existing code is to become popular? ) constexpr normal_distribution<double> n01(0., 1.); producing this code 960 .loc 1 47 0 961 000d 660FEFC0 pxor %xmm0, %xmm0 # tmp89 962 0011 F20F1145 movsd %xmm0, -32(%rbp) # tmp89, n01.m_mean 962 E0 963 0016 F20F1005 movsd .LC1(%rip), %xmm0 #, tmp90 963 80080000 964 001e F20F1145 movsd %xmm0, -24(%rbp) # tmp90, n01.m_sd 964 E8 and more interestingly, a PDF can be calculated at compile-time constexpr double p = pdf(n01, 0.5); 965 .loc 1 56 0 966 0023 F20F1005 movsd .LC2(%rip), %xmm0 #, tmp91 966 88080000 967 002b F20F1145 movsd %xmm0, -8(%rbp) # tmp91, p 967 F8 Perhaps the assembler whizzes can confirm that this looks like a compile-time computation? This relies on lots of C++14 and 17 constexpr features, and Most crucially it relies on being able to use several cmath functions as constexpr. For a couple of trivially simple examples: abs(x) and isfinite(x). constexpr double ax42 = abs(-42.); // Unspecified version of abs. constexpr double ax42g = ::abs(-42.); // C double version? constexpr double ax42b = __builtin_abs(-42.); // builtin GCC only constexpr double ax42s = std::abs(-42.); // std:: version Without most cmath functions it seems to me impossible to write any reasonable (so-called special or not) mathy function or statistical distribution that can be constexpr. At present, only GCC 6.1.1 authors have foreseen this need and provided these so-called built_in_* cmath function versions that are constexpr, see https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html. (Aside on other compilers: · Clang 3.8 has some problem deep inside type_traits that I haven't yet investigated. · VS2015 update 3 still doesn't compile many essential C++17 features from my experiments so far, and doesn't provide any constexpr cmath functions. ) The many potential benefits of compiler-time computations are quite enticing to contemplate :-) * No run-time where possible * Errors caught at compile-time * Improved code readability * Reduce executable footprint and potentially most important * Avoid global initialization order issues * Avoid initialization thread races See · Scott Schurr, C++ Developer, Ripple Labs https://cppnow2015.sched.org/event/2oLK/constexpr-c-at-compile-time · Dietmar Khul Constant Fun https://www.youtube.com/watch?list=PL9hrFapz4dsM1B9bI8VmEE4JJlR0m-dvo <https://www.youtube.com/watch?list=PL9hrFapz4dsM1B9bI8VmEE4JJlR0m-dvo&v=T37…> &v=T37ElKPICvo&app=desktop Is there any support for making std::abs and friends constexpr where possible in future versions of the C++ Standard? Paul PS I can't conceive of any UDT using or providing floating-point without some function like frexp to get and set exponent and significand. I also note that making constexpr frexp and ldexp and other functions passing a pointer to a variable to be updated may be more difficult/impossible, and is very likely to require at least initialization of the to-be-updated variable before calling frexp. I've investigated overcoming this by writing a naïve new constexpr version of frexp returning a std::pair (significand and exponent) but, of course, it can never be a 'drop-in' replacement because it has a different signature, so lots of code changes are inevitable. --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830

5 6

[type_erasure] Do we have a maintainer (minor fix needed)?
by John Maddock 31 Jul '16

31 Jul '16

This trivial PR is open for type_erasure and fixes an issue introduced by changes to Boost.Config (enabling constexpr support for VC14up3). https://github.com/boostorg/type_erasure/pull/11 BTW the failure is not caused by buggy constexpr support, there's some other issue going on once that code path is enabled. Anyhow, since we really should be merging Config to master soon, I'd like to see this collateral-damage fixed if possible. Thanks, John.

1 0

[contract] Template types
by Lorenzo Caminiti 29 Jul '16

29 Jul '16

Hello all, I would like to discuss the extra type requirements that contracts can impose of generic types and how Boost.Contract handles that. I think I mentioned some of this already in different emails to this list, but I wanted to summarize this topic in one email. For example, note that the following code will not compile when the old value template parameter T is not copyable: template<typename T> void swap(T& a, T& b) [[ensures: a == old(b)]] ... In Boost.Contract (approach 1): template<typename T> void swap(T& a, T& b) { boost::contract::old_ptr<T> old_b = BOOST_CONTRACT_OLDOF(b); boost::contract::guard c = boost::contract::function() .postcondition([&] { BOOST_CONTRACT_ASSERT(a == *old_b); }) ; ... } In some cases, that might be what the contract writers want: the generic old value type T is not copyable so postconditions cannot be checked and the program should not compile. However, in some other cases the contract writes might not want to add the extra copyable requirement on T and check the related postconditions only when callers specify a template parameter T that happens to be copyable. That can be done allowing some sort of static-if in contracts: template<typename T> void swap(T& a, T& b) [[ensures: static if(is_copyable<T>::value) a == old(b)]] ... In Boost.Contract (approach 2): template<typename T> void swap(T& a, T& b) { boost::contract::old_ptr_if_copyable<T> old_b = BOOST_CONTRACT_OLDOF(b); boost::contract::guard c = boost::contract::function() .postcondition([&] { if(old_b) BOOST_CONTRACT_ASSERT(a == *old_b); }) ; ... } Both approach 1 and 2 above are valid and should be supported by the framework. The decision between which approach to use for a specific contract should be left up to the programmers. Like old values can introduce the extra copyable type requirement, any contract assertion can in general introduce an number of extra requirements on generic types, namely the type requirements necessary to support the operations used to program the contract assertions. For example, the following code will not compile if T is not equality comparable (which is not a type requirement vector normally imposes on T): template<typename T> class vector { void push_back(T const& value) [[ensures: back() == value]] ... }; In Boost.Contract (approach 1): template<typename T> class vector { void push_back(T const& value) { boost::contract::guard c = boost::contract::public_function(this) .postcondition([&] { BOOST_CONTRACT_ASSERT(back() == value); }) ; ... } }; Again, that might be what contract writes want in some case but in other cases they might want to just skip the assertion when T does not meet all the type requirements needed by the operations used in the assertion: template<typename T> class vector { void push_back(T const& value) [[ensures: static if(has_equal_to<T>::value) back() == value]] ... }; In Boost.Contract (approach 2): template<typename T> class vector { void push_back(T const& value) { boost::contract::guard c = boost::contract::public_function(this) .postcondition([&] { BOOST_CONTRACT_ASSERT( boost::contract::check_if<has_equal_to<T>::value >( boost::bind(equal_to<T>, cref(back()), cref(value)) ) ); }) ; ... } }; --Lorenzo

1 0

Gmane going away
by Tom Kent 29 Jul '16

29 Jul '16

So it looks like Gmane is under attack and the guy who runs it is thinking about just turning it off (that would be sad). https://lars.ingebrigtsen.no/2016/07/28/the-end-of-gmane/ Anyway, I know a lot of boost users use is as the gnu mailman archive pages are really hard to use. I would like to propose that we (specifically the list owner(s)) mirror the boost mailing lists to the mail-archive.com site. It has good search features and decent thread browse-ability. Thoughts? Tom

1 0

Boost Social Event at CppCon 2016
by Jon Kalb 28 Jul '16

28 Jul '16

Boost Developers, Because a lot of Boosters are going to be attending CppCon, we¹d like to arrange a social event for Boosters/C++Now attendees. http://cppcon.org/ If you are planning to attend CppCon or even If you are just going to be in or around Bellevue, Washington between September 17th and 23rd and you¹d like to join us for dinner, please let us know so we can get a count. Please send mail to: social(a)boost.org Once we settle on a date, etc, we¹ll let everyone who responded know when and where, so please let us know, even if you are a ³maybe.² If you are attending, please make your hotel reservations soon. We are likely to sell out of our room block. http://cppcon.org/lodging/ I hope to see you at CppCon. Jon

2 1

Approximate matching to Boost.Algorithm
by Зайцев Александр 27 Jul '16

27 Jul '16

Hello. I want to discuss about some proposals. I am working on Levenshtein distance and Damerau-Levenshtein distance algortihms. I hope, that these implementations will be pulled to the Boost String library. But i think that we can add to the Boost String Library some more algorithms for fuzzy searhing. You can find this list here: https://fuzzystring.codeplex.com/ List: 1)Hamming Distance 2)Jaccard Distance 3)Jaro Distance 4)Jaro-Winkler Distance 5)Levenshtein Distance 6)Longest Common Subsequence 7)Longest Common Substring 8)Overlap Coefficient 9)Ratcliff-Obershelp Similarity 10)Sorensen-Dice Distance 11)Tanimoto Coefficient Maybe something else... What do you think about this idea? If you think that it can be implemented to the Boost String Algo, i will start work on this list immediately. Best regards, Zaitsev Alexander.

2 1

I am working on Aho-Corasik
by Зайцев Александр 27 Jul '16

27 Jul '16

Hello. FYI: Now i am working on Aho-Corasik algorithm. Best regards, Alexander Zaitsev.

1 0

Fast nth-elemnt on the segment
by Зайцев Александр 26 Jul '16

26 Jul '16

Hello. What do you think about algorithm of fast searching nth-elemnt on the segment with O(logN), where N is count of elements. I would implement it to Boost.Algorithm. Best regards, Alexander Zaitsev

1 0

[type_erasure] Conflict with private member called data
by Nigel Pattinson 22 Jul '16

22 Jul '16

Hi I'm running into a problem with the type erasure library when trying to declare a member called 'data', e.g. BOOST_TYPE_ERASURE_MEMBER((has_data), data) using SomeClass = any< vector< copy_constructible<>, typeid_<>, relaxed, has_data<void*()> > >; This conflicts with the private member variable called 'data' in the any class. SomeClass does compile, but attempting to call the data() does not compile due to the conflict, with the error message being 'cannot access private member ... ' . I'm not sure if this is a limitation in the library or a compiler bug - I'm using Visual Studio 2015 Update 1. Using boost 1.57.0 at present, I could use a more recent version if that would help. Does anyone know of a possible workaround ? Thanks Nigel Pattinson

2 2

Update for the Cxx dual library
by Edward Diener 22 Jul '16

22 Jul '16

The Cxx dual library, or CXXD for short, is a C++ macro header-only library which chooses between using a Boost library or its C++ standard equivalent library for a number of different C++ implementations, while using the same code to program either choice. An 'implementation', called a 'dual library', is a Boost library which has a C++ standard library equivalent whose public interfaces are nearly the same in both cases. I have updated the Cxx dual library, for those who prefer to minimize their use of macros in source code, by providing an alternate method to the use of macros for including the appropriate header files and specifying the appropriate namespace for a dual library. In this alternate method including the appropriate header files is done by including an implementation header file, and specifying the appropriate namespace is done by using a C++ namespace alias. The alternate method, called the alias mode, is fully documented. You can get the latest version of the Cxx dual library at https://github.com/eldiener/cxx_dual. Instructions for using the library are in the README.md file. PDF documentation is available in cxx_dual.pdf, HTML doc is availavble online at http://eldiener.github.io/cxx_dual and you can generate local HTML documentation using the doc jam file. Questions, comments, bug reports are always welcome.

1 0

does boost support multimedia framework
by qw 22 Jul '16

22 Jul '16

Hi, Does boost support multimedia framework, just like gstreamer? Thanks! Regards Andrew

2 1

[contract] Class invariants (also for static and volatile/const-volatile public functions)
by Lorenzo Caminiti 21 Jul '16

21 Jul '16

Hello all, I would like to discuss class invariants, but also for static and volatile/const-volatile public member functions, and specifically with respect to how Boost.Contract handles them. Class invariants are important... almost as important as preconditions. For example for a vector container, class invariants specify among other things the equivalence relationship `(size() == 0) == empty()` that could be found useful by static analyzers and optimizes (also discussed in N4160): template<typename T> class vector { [[invariant: (size() == 0) == empty()]] [[invariant: size() <= capacity()]] public: void push_back(T const& value) ... { ... } }; The above contract cannot be programmed using preconditions and postconditions unless: it is repeated (together with all other invariant assertions) in pre- and postconditions of each public member functions, it is asserted with try-catches also when those functions throw, it is repeated in constructor postconditions, in destructor preconditions, and with try-catches also when destructors throw... Even if invariants are programmed in some `bool invariant() const` function to avoid repeating all invariant assertions in each pre- and postcondition, the code will be cluttered by boiler-plate code (try-catch to assert invariants on throw, etc.) and an invariant failure will just report that the invariant() function returned false, but it will not report which specific invariant condition actually failed (plus static analyzers and optimizes will not be able to parse the conditions from the invariant function): template<typename T> class vector { bool invariant() const { // But cannot distinguish which of the two assertions failed... // and cannot be used by static analyzers and optimizers. return (size() == 0) == empty() && size() <= capacity(); } public: void push_back(T const& value) ... [[requires: invariant()]] [[ensures: invariant()]] { try { ... } catch(...) { [[assert: invariant()]]; throw } } }; Class invariants cannot be effectively emulated using pre- and postconditions... they should be added to a contract framework as their own feature. In Boost.Contract: template<typename T> class vector { void invariant() const { BOOST_CONTRACT_ASSERT((size() == 0) == empty()); BOOST_CONTRACT_ASSERT(size() <= capacity()); } public: void push_back(T const& value) { boost::contract::guard c = boost::contract::public_function(*this) ... ; ... } }; Note that the above invariant function `void invariant() const` cannot be declared static or const-volatile because it will need to call queries like size(), empty(), capacity(), etc. that are const and not static or const-volatile. Thus the above invariant function, being const, cannot be called at entry and exit of static and volatile/const-volatile public functions. A contract framework for C++ should support also static and const-volatile class invariants to properly handle static and volatile/const-volatile public functions (even if static and const-volatile class invariants are not mentioned in any C++ contract proposal): * Static public functions check static class invariants at entry, at exit, and if body throws. * Volatile and const-volatile public functions check static and const-volatile class invariants (in that order) at entry, at exit, and if body throws. * Non cv-qualified and const public functions check static, const-volatile, and const class invariants (in that order) at entry, at exit, and if body throws. * Constructors check static class invariants at entry, at exit, and if body throws (because those do not require the object to be constructed). Then constructors check const-volatile and const class invariants (in that order) at exit (if body does not throw, because those require the object to be constructed). * Destructors check static class invariants at entry, at exit, and if body throws (because those do not require a constructed object). Then destructors check const-volatile and const class invariants (in that order) at entry and if body throws (because those require a constructed object). In Boost.Contract: struct a { static void static_invariant() { BOOST_CONTRACT_ASSERT(...); } void invariant() const volatile { BOOST_CONTRACT_ASSERT(...); } void invariant() const { BOOST_CONTRACT_ASSERT(...); } // Following check all static_invariant(), invariant() const volatile, and invariant() const (in that order). a() { boost::contract::guard c= boost::contract::constructor(this); } virtual ~a() { boost::contract::guard c = boost::contract::destructor(this); } void m() /* no cv qualifiers */ { boost::contract::guard c = boost::contract::public_function(*this); } void c() const { boost::contract::guard c = boost::contract::public_function(*this); } // Following check both static_invariant() and invariant() const volatile (in that order). void v() volatile { boost::contract::guard c = boost::contract::public_function(*this); } void cv() const volatile { boost::contract::guard c = boost::contract::public_function(*this); } // Following check only static_invariant(). static void s() { boost::contract::guard c = boost::contract::public_function<a>(); } }; Maybe volatile member functions are rarely used in C++ so const-volatile class invariants will also be used rarely if at all... Nevertheless, if const-volatile class invariants are not supported, it will not be possible to specify invariants for classes with volatile public functions so const-volatile class invariants should be supported for completeness. Static class invariant could instead be useful when programming contracts for the static part of the object state. In particular, Boost.Contract also supports postconditions for destructors (those should be checked by a static function because they should not access the object `this` that has been destroyed after the execution of the destructor body). Destructor postconditions are not mentioned in any contract proposal... but together with constructor and other function pre- and postconditions, and together with static class invariants, they can specify contracts for the static part of the object state. For example, consider the contracts for a class that counts the number of its object instances: struct a : private noncopyable, private nonmovable { static void static_invariant() { BOOST_CONTRACT_ASSERT((instances() != 0) == exists()); } a() { boost::contract::old_ptr<unsigned> old_instances = BOOST_CONTRACT_OLDOF(instances()); boost::contract::guard c = boost::contract::constructor(this) .postcondition([&] { BOOST_CONTRACT_ASSERT(instances() == old_instances + 1); }) ; ++instances_; } virtual ~a() { boost::contract::old_ptr<unsigned> old_instances = BOOST_CONTRACT_OLDOF(instances()); boost::contract::guard c = boost::contract::destructor(this) .postcondition([&] { // Must never use object `this`. BOOST_CONTRACT_ASSERT(instances() == old_instances - 1); }) ; --instances_; } static unsigned instances() { boost::contract::guard c = boost::contract::public_function<a>(); return instances_; } static bool exists() { boost::contract::guard c = boost::contract::public_function<a>(); return instances_ != 0; } private: static unsigned instances_; }; unsigned a::instances_ = 0; --Lorenzo

1 0

double_ended - request formal review
by Benedek Thaler 21 Jul '16

21 Jul '16

Dear Boost, I'd like to request the review of the double_ended library. Code: https://github.com/erenon/double_ended Documentation: http://erenon.hu/double_ended The library contains two classes. Excerpt from the documentation: * `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. I'm also looking for a review manager. Thanks, Benedek

2 1

[contract] Friend functions
by Lorenzo Caminiti 19 Jul '16

19 Jul '16

Hello all, I would like to discuss contracts for friend functions and specifically how they are handled in Boost.Contract. Consider the following example: class a; class b; class data { ... friend bool deep_equal(a*, b*); bool equal(data const&); }; class a { ... friend bool deep_equal(a*, b*); data data_; }; class b { ... friend bool deep_equal(a*, b*); data data_; }; bool deep_equal(a* x, b* y) { return x->data_.equal(y->data_); } Via friendship, deep_equal can be considered to extend a and b public interfaces, but not data's public interface (in fact, deep_equal does not take instance of data as an argument). Therefore, it is reasonable to think that deep_equal should check a and b class invariants (if so... in which order?), but not data's class invariants. As discussed in N4160, that would probably require some new language feature to specify which subset of friend functions also extend a class public interface. Plus such a feature should identify some preferred order in which class invariants should be checked for a friend function that extends public interfaces of multiple classes. That seems rather complicated so I think a language proposal (like N1962) is better off going with the general rule that friends functions do not check class invariants (even if that might not always be ideal in all cases): bool deep_equal(a* x, b* y) [[requires: x && y]] // Does not check a and b (and c) invariants... even if arguably it should. { return x->data_.equal(y->data_); } In Boost.Contract: bool deep_equal(a* x, b* y) { boost::contract::guard c = boost::contract::function() .precondition([&] { BOOST_CONTRACT_ASSERT(x && y); }) ; // Does not check a and b (and c) invariants... even if arguably it should. return x->data_.equal(y->data_); } Maybe programmers could manually check a and b invariants (but then also from the function body when it throws) when those checks are truly essential for friend function: bool deep_equal(a* x, b* x) [[requires: x && y]] // Check a and b invariants in that order (if contract writes decide to), does not check c invariants. [[requires: x->invariant() && y->invariant()] [[ensures: x->invariant() && y->invariant()] { try { return x->data_.equal(y->data_); } catch(...) { [[assert: x->invariant() && y->invariant()]]; throw; } } (That seems somewhat verbose... plus it assumes that class invariants are somehow specified in a `bool invariant() const function (that can be private), or using a set of [[invariant: ...]] attributes that automatically generate such a callable `bool invariant() const` function.) This is possible in Boost.Contract: bool deep_equal(a* x, b* y) { boost::contract::guard c = boost::contract::function() .precondition([&] { BOOST_CONTRACT_ASSERT(x && y); }) ; // Check a and b invariants in that order (if contract writers decide to), does not check c invariants. boost::contract::guard inv_x = boost::contract::public_function(*x); boost::contract::guard inv_y = boost::contract::public_function(*y); return x->data_.equal(y->data_); } Finally, note that in this case preconditions are checked before entry invariants (while usually public functions check preconditions after entry invariants). That is desirable/needed for friend functions because the class object is not *this (which is always well defined and therefore subject to no precondition). For friend functions, the class object can be any computation of the friend function arguments and those arguments must be validated by preconditions before they can be used to access the class object. In the examples above, the arguments are checked to be not null by preconditions so they can be safely dereferenced to get the objects *x and *y (and in general the computations required might be even much more complex than dereferencing pointers). Thank you. --Lorenzo

1 0

[contract] Without the macros
by Lorenzo Caminiti 19 Jul '16

19 Jul '16

Hello all, In the last few years my professional and personal lives changed quite a bit limiting my ability to contribute to Boost. However, in my spare time I slowing continued to revise Boost.Contract hoping to be able to commit it to a Boost release someday (after the library was accepted 3+ years ago... https://groups.google.com/forum/?fromgroups=#!topic/boost-list/jQ7OjAmos_Y) While doing so I realized that leveraging C++11 lambda functions, Boost.Contract could be re-implemented without its crazy macros that alter C++ function declaration syntax. Boost.Contract still remains the only C++ library that implements *all* features of Contract Programming (a.k.a., Design by Contract or DbC): subcontracting, class invariants (also static and volatile), postconditions (with old and return values), preconditions, customizable actions on assertion failure (terminate, throw, etc.), optional assertion compilation, disable assertion checking while already checking other assertions (to avoid infinite recursion), etc. Furthermore, in its new incarnation Boost.Contract no longer uses crazy macros so it is easier to use, faster to compile, and gives readable compiler errors. For example: #include <boost/contract.hpp> int inc(int& x) { int result; boost::contract::old_ptr<int> old_x = BOOST_CONTRACT_OLDOF(x); boost::contract::guard c = boost::contract::function() .precondition([&] { BOOST_CONTRACT_ASSERT(x < std::numeric_limits<int>::max()); }) .postcondition([&] { BOOST_CONTRACT_ASSERT(x == *old_x + 1); BOOST_CONTRACT_ASSERT(result == *old_x); }) ; return result = x++; // Function body. } Or with subcontracting: #include <boost/contract.hpp> #include <vector> template<typename T> class pushable; // Arbitrary base to demo subcontracting. template<typename T> class vector #define BASES public pushable<T> : BASES { public: typedef BOOST_CONTRACT_BASE_TYPES(BASES) base_types; // Subcontracting. #undef BASES void invariant() const { // Checked in AND with base class invariants. BOOST_CONTRACT_ASSERT(size() <= capacity()); // Line 25. } virtual void push_back(T const& value, boost::contract::virtual_* v = 0) /* override */ { boost::contract::old_ptr<unsigned> old_size = BOOST_CONTRACT_OLDOF(v, size()); // Old values. boost::contract::guard c = boost::contract::public_function< override_push_back>(v, &vector::push_back, this, value) .precondition([&] { // Checked in OR with base preconditions. BOOST_CONTRACT_ASSERT(size() < max_size()); // Line 35. }) .postcondition([&] { // Checked in AND with base postconditions. BOOST_CONTRACT_ASSERT(size() == *old_size + 1); // Line 38. }) ; vect_.push_back(value); // Function body. } BOOST_CONTRACT_OVERRIDE(push_back) // For `override_push_back`. // Could program contracts for those as well. unsigned size() const { return vect_.size(); } unsigned max_size() const { return vect_.max_size(); } unsigned capacity() const { return vect_.capacity(); } private: std::vector<T> vect_; }; Full documentation and examples at: https://lcaminiti.github.io/boost-contract What do you think? Thanks, --Lorenzo P.S. The library can also be used without C++11 lambda functions (or any C++11 specific feature) but programmers have to write a fare amount of extra code to program the precondition and postcondition functors (using non-local functions, Boost.LocalFunction, Boost.Funsion, Boost.Lambda, or some other approach) so that might not useful in practice.

6 14

[graph] Compilation error with adjacency_list and C++11
by Sebastien Loriot (GeometryFactory) 18 Jul '16

18 Jul '16

Hello, the program below does not compile at least with g++ 5.3.1 and clang++ 3.5.2-1 when using c++11 standard. If I comment line #1 it compiles. If I change #2 to undirectedS it compiles. Is there anything wrong in my code or is it a problem in boost's? Thanks, Sebastien. #include <boost/graph/adjacency_list.hpp> struct A { A(){} A(const A& ){} // #1 A& operator=(const A&){return *this;} }; typedef boost::adjacency_list<boost::listS, boost::vecS, boost::directedS, //#2 A > Graph; int main() { Graph g; boost::add_vertex(g); return 0; }

2 2

[type_index] Interest in dynamic_cast emulation?
by Chris Glover 17 Jul '16

17 Jul '16

Hi, I reached for Boost.TypeIndex the other day expecting to find a kind of dynamic_cast I could use in the absence of Rtti. I didn't find it, so I wrote something to emulate it using type_index internally. It's working, but before I go too far and clean this up and possibly submit a pull request, I would like to gauge if there's interest in such a thing or if there's some fundamental reason why it doesn't exist. So, thoughts? Thanks, -- chris

5 8

[contract] Strong exception safety guarantees
by Lorenzo Caminiti 15 Jul '16

15 Jul '16

Hello all, I've been considering adding a .except(...) construct to Boost.Contract that will allow to specify conditions to check at function exit but when the function body throws (in contrast to postconditions that are checked at function exit but only when the function body does not throw). I think .except(...) could be used to assert strong exception safety guarantees... (note that class invariants are already checked at exit of public functions and also when the public function bodies throw, but invariants are suited to assert only basic, and not strong, exception safety guarantees). That might help addressing a point made in P0147R0 under the "Contracts and Exceptions" section: ``Some operations make stronger exception safety claims. In particular, they claim that an exception thrown from a member function will leave the state of an object unchanged from its state on function entry. If we invalidate postconditions on exceptions, we appear to have no mechanism to describe strong exception safety.'' For example, the following swap ensures to leave its arguments unchanged when it throws: void swap(std::string& a, std::string& b) { boost::contract::old_ptr<std::string> old_a = BOOST_CONTRACT_OLDOF(a); boost::contract::old_ptr<std::string> old_b = BOOST_CONTRACT_OLDOF(b); boost::contract::guard c = boost::contract::function() .postcondition([&] { // Checked at function exit but only if body does not throw. BOOST_CONTRACT_ASSERT(a == *old_b); BOOST_CONTRACT_ASSERT(b == *old_a); }) .except([&] { // Checked if body throws (strong exception safety guarantees). BOOST_CONTRACT_ASSERT(a == *old_a); BOOST_CONTRACT_ASSERT(b == *old_b); }) ; ... // Body implementation (which might throw). } Would this be beneficial? Thanks, --Lorenzo

2 5

smartptr maintained
by Karolin Varner 15 Jul '16

15 Jul '16

Hi, is smartptr still being maintained? There are four pull requests, one more than a year old. Best, Karolin Varner

2 3

[graph] A* implementation doesn't follow the algorithm
by Nick Lamprianidis 14 Jul '16

14 Jul '16

For the A* algorithm holds that when a new vertex v is reached through a shorter path, then v is added to the open set. But looking at the boost graph's A* implementation, which is based on the BFS algorithm, one can see that a target vertex is added to the priority queue, regardless of whether the relevant edge is being relaxed. This creates the following situation: The execution starts and you get to a point where you know you cannot reach the goal: no vertices with finite cost in the priority queue. Normally, you would expect that the priority queue is empty and thus the execution ends. Instead, the execution continues, since the priority queue is filled with all those vertices (with infinite cost) that got added for no reason. In an application where the state of a target vertex v gets set when an associated edge is being relaxed, a problem arises. In the situation mentioned above, uninitialized vertices reach the visitor's examine_vertex method. Unless you know what's really happening, so you can take care to add a test condition to exit, it leaves you wondering what's going wrong. I propose that you either change the implementation or at least update the documentation (pseudocode). -- Nick Lamprianidis http://paign10.me

3 2

[log][regression] Error with Boost.Lob build jamfile breaks MinGW regression tester in develop
by Ion Gaztañaga 13 Jul '16

13 Jul '16

Hi, My develop branch regression runner fails whereas the master one works fine. The develop runner fails with all Mingw targets (msvc 7.1 works fine), with this error: ************************************ # Starting tests ("c:\boost\develop\boost_bb\src\engine\bin.ntx86\bjam.exe" "-sBOOST_BUILD_PATH=c:\boost\develop;c:\boost\develop\boost_bb\src" "-sBOOST_ROOT=c:\boost\develop\boost_root" "--boost=c:\boost\develop\boost_root" "--boost-root=c:\boost\develop\boost_root" "--boost-build=c:\boost\develop\boost_bb\src" "--debug-configuration" -l300 toolset=gcc-6.1c++14 -d2 preserve-test-targets=off --dump-tests -j3 --abbreviate-paths debug-symbols=off -m64 "--build-dir=c:\boost\develop\results" >>"c:\boost\develop\results\bjam.log" 2>&1)... c:\boost\develop\boost_root\status> "c:\boost\develop\boost_bb\src\engine\bin.ntx86\bjam.exe" "-sBOOST_BUILD_PATH=c:\boost\develop;c:\boost\develop\boost_bb\src" "-sBOOST_ROOT=c:\boost\develop\boost_root" "--boost=c:\boost\develop\boost_root" "--boost-root=c:\boost\develop\boost_root" "--boost-build=c:\boost\develop\boost_bb\src" "--debug-configuration" -l300 toolset=gcc-6.1c++14 -d2 preserve-test-targets=off --dump-tests -j3 --abbreviate-paths debug-symbols=off -m64 "--build-dir=c:\boost\develop\results" 1>>"c:\boost\develop\results\bjam.log" 2>&1 # Running Boost.Build tests Traceback (most recent call last): File "run.py", line 71, in <module> runner(root) File "c:\boost\develop\boost_regression_src\regression.py", line 287, in __init__ self.main() File "c:\boost\develop\boost_regression_src\regression.py", line 624, in main getattr(self,action_m)() File "c:\boost\develop\boost_regression_src\regression.py", line 589, in command_regression self.command_test() File "c:\boost\develop\boost_regression_src\regression.py", line 368, in command_test self.command_test_boost_build() File "c:\boost\develop\boost_regression_src\regression.py", line 410, in command_test_boost_build "boost/bin.v2/libs/any/test/any_test.test")); WindowsError: [Error 3] The system cannot find the path specified: 'c:\\boost\\develop\\results\\boost/bin.v2/libs/any/test/any_test.test/*.*' ************************************ That path ("..libs/any/test/any_test.test/) is hardcoded in regression.py, but it's not generated in my bin.v2 so it's reasonable an error saying that the system can't find the path ;-) It seems that error occurs before boost.build tests, as bjam.log shows: ************************************ C:/boost/develop/boost_bb/src/build\targets.jam:1077: in evaluate-requirements from module targets error: Can not evaluate conditional properties <conditional>@Jamfile<C:\boost\develop\boost_root>%Jamfile<C:\boost\develop\boost_root>.handle-static-runtime <conditional>@Jamfile<C:\boost\develop\boost_root>%boostcpp.deduce-address-model <conditional>@Jamfile<C:\boost\develop\boost_root>%boostcpp.deduce-architecture <conditional>@Jamfile<C:\boost\develop\boost_root\libs\log\build>%Jamfile<C:\boost\develop\boost_root\libs\log\build>.check-instruction-set <conditional>@Jamfile<C:\boost\develop\boost_root\libs\log\build>%Jamfile<C:\boost\develop\boost_root\libs\log\build>.check-message-compiler <conditional>@Jamfile<C:\boost\develop\boost_root\libs\log\build>%Jamfile<C:\boost\develop\boost_root\libs\log\build>.check-pthread-mutex-robust <conditional>@Jamfile<C:\boost\develop\boost_root\libs\log\build>%Jamfile<C:\boost\develop\boost_root\libs\log\build>.check-visibility <conditional>@Jamfile<C:\boost\develop\boost_root\libs\log\build>%Jamfile<C:\boost\develop\boost_root\libs\log\build>.select-arch-specific-sources <conditional>@Jamfile<C:\boost\develop\boost_root\libs\log\build>%Jamfile<C:\boost\develop\boost_root\libs\log\build>.select-platform-specific-sources <conditional>@Jamfile<C:\boost\develop\boost_root\libs\log\build>%Jamfile<C:\boost\develop\boost_root\libs\log\build>.select-regex-backend <link>shared:<define>BOOST_LOG_DLL <target-os>cygwin:<define>BOOST_USE_WINDOWS_H <target-os>cygwin:<define>NOMINMAX <target-os>cygwin:<define>SECURITY_WIN32 <target-os>cygwin:<define>WIN32_LEAN_AND_MEAN <target-os>cygwin:<define>__USE_W32_SOCKETS <target-os>cygwin:<library>/boost/log//advapi32 <target-os>cygwin:<library>/boost/log//mswsock <target-os>cygwin:<library>/boost/log//ws2_32 <target-os>freebsd:<library>/boost/log//rt <target-os>hpux:<define>_XOPEN_SOURCE=600 <target-os>hpux:<library>/boost/log//ipv6 <target-os>linux:<define>_XOPEN_SOURCE=600 <target-os>linux:<library>/boost/log//rt <target-os>qnxnto:<library>/boost/log//socket <target-os>solaris:<define>_XOPEN_SOURCE=500 <target-os>solaris:<define>__EXTENSIONS__ <target-os>solaris:<library>/boost/log//nsl <target-os>solaris:<library>/boost/log//socket <target-os>windows:<define>BOOST_USE_WINDOWS_H <target-os>windows:<define>NOMINMAX <target-os>windows:<define>SECURITY_WIN32 <target-os>windows:<define>WIN32_LEAN_AND_MEAN <target-os>windows:<library>/boost/log//advapi32 <target-os>windows:<library>/boost/log//mswsock <target-os>windows:<library>/boost/log//ws2_32 <threading>multi:<library>/boost/atomic//boost_atomic <threading>multi:<library>/boost/thread//boost_thread <threading>single:<define>BOOST_LOG_NO_THREADS <toolset>clang:<cxxflags>-ftemplate-depth-1024 <toolset>como-linux:<define>_GNU_SOURCE=1 <toolset>como:<link>static <toolset>darwin:<cxxflags>-ftemplate-depth-1024 <toolset>gcc,<target-os>cygwin:<linkflags>-Wl,--enable-auto-import <toolset>gcc,<target-os>windows:<linkflags>-Wl,--enable-auto-import <toolset>gcc:<cxxflags>-fno-strict-aliasing <toolset>gcc:<cxxflags>-ftemplate-depth-1024 <toolset>intel-darwin:<cxxflags>-wd177,780,2196,1782,193,304,981,1418,411,734,279 <toolset>intel-linux:<cxxflags>-wd177,780,2196,1782,193,304,981,1418,411,734,279 <toolset>intel-win:<cxxflags>/Qwd177,780,2196,1782,193,304,981,1418,411,734,279 <toolset>intel-win:<define>_CRT_SECURE_NO_DEPRECATE <toolset>intel-win:<define>_CRT_SECURE_NO_WARNINGS <toolset>intel-win:<define>_SCL_SECURE_NO_DEPRECATE <toolset>intel-win:<define>_SCL_SECURE_NO_WARNINGS <toolset>msvc,<runtime-link>shared:<threading>multi <toolset>msvc:<cxxflags>/bigobj <toolset>msvc:<cxxflags>/wd4003 <toolset>msvc:<cxxflags>/wd4456 <toolset>msvc:<cxxflags>/wd4459 <toolset>msvc:<cxxflags>/wd4503 <toolset>msvc:<define>_CRT_SECURE_NO_DEPRECATE <toolset>msvc:<define>_CRT_SECURE_NO_WARNINGS <toolset>msvc:<define>_SCL_SECURE_NO_DEPRECATE <toolset>msvc:<define>_SCL_SECURE_NO_WARNINGS <toolset>pgi:<library>/boost/log//rt C:/boost/develop/boost_bb/src/build\targets.jam:1112: in common-properties2 from module targets C:/boost/develop/boost_bb/src/build\targets.jam:977: in targets.common-properties from module targets C:/boost/develop/boost_bb/src/build\targets.jam:1303: in class(a)basic-target.generate from module object(typed-target)@1504 C:/boost/develop/boost_bb/src/build\targets.jam:774: in generate-really from module object(main-target)@49045 C:/boost/develop/boost_bb/src/build\targets.jam:746: in class(a)main-target.generate from module object(main-target)@49045 C:/boost/develop/boost_bb/src/build\targets.jam:895: in targets.generate-from-reference from module targets C:/boost/develop/boost_bb/src/build\targets.jam:1266: in generate-dependencies from module object(typed-target)@14269 C:/boost/develop/boost_bb/src/build\targets.jam:1320: in class(a)basic-target.generate from module object(typed-target)@14269 C:/boost/develop/boost_bb/src/build\targets.jam:774: in generate-really from module object(main-target)@49008 C:/boost/develop/boost_bb/src/build\targets.jam:746: in class(a)main-target.generate from module object(main-target)@49008 C:/boost/develop/boost_bb/src/build\targets.jam:895: in targets.generate-from-reference from module targets C:/boost/develop/boost_bb/src/build\targets.jam:1266: in generate-dependencies from module object(alias-target-class)@36618 C:/boost/develop/boost_bb/src/build\targets.jam:1323: in class(a)basic-target.generate from module object(alias-target-class)@36618 C:/boost/develop/boost_bb/src/build\targets.jam:774: in generate-really from module object(main-target)@36634 C:/boost/develop/boost_bb/src/build\targets.jam:746: in class(a)main-target.generate from module object(main-target)@36634 C:/boost/develop/boost_bb/src/build\targets.jam:272: in class(a)project-target.generate from module object(project-target)@2141 c:/boost/develop/boost_bb/src\build-system.jam:714: in load from module build-system C:\boost\develop\boost_bb\src/kernel\modules.jam:295: in import from module modules C:\boost\develop\boost_bb\src/kernel/bootstrap.jam:139: in boost-build from module C:\boost\develop\boost_root\boost-build.jam:17: in module scope from module ************************************ I can't see why this Jamfile from Boost.Log is accepted when MSVC-7.1 is the target but fails when MinGW is the selected target. I could neither t deduce what is the failing piece of the configuration. The same error happens with a wide range of MINGW targets: GCC-3.4, GCC-4.1, GCC-4.2, GCC-4.3, GCC-4.4, GCC-4.5, GCC-4.6, GCC-4.7, GCC-4.8, GCC-4.9, GCC-5.1, GCC-5.2, GCC-5.3 and GCC-6.1. Any clue on what can be happening and how can it be fixed? Attached regression logs for a failed MINGW regression with GCC 6.1. Best, Ion

3 8

[regression][winapi] Tests not being run
by Andrey Semashev 11 Jul '16

11 Jul '16

Hi, I wrote about it before, but now the problem becomes more weird. The problem is that the tests for Boost.WinAPI are not being run for some reason. What's weird is that now there is one test in the matrix (http://www.boost.org/development/tests/develop/developer/winapi.html) that isn't part of the Boost.WinAPI test suite. I assume that entry is part of the formal checks for the library conformance, since it is present for all libraries. Could someone please have a look why the tests for Boost.WinAPI are not being executed? PS: The link for the __boost_check_library__ entry is broken: https://github.com/boostorg/winapi/blob/developstatus/boost_check_library.py I believe, there's a slash missing between develop and status, and also the repository name should be boost rather than winapi.

2 2

[TypeErasure] Merging pull-requests
by Deniz Bahadir 11 Jul '16

11 Jul '16

Hello everyone, Hello Steven, a view weeks ago I reported some bugs of Boost.TypeErasure [1,2] and provided pull-requests [3,4] which fix these. I just wanted to bring these to attention so that they might get merged and find their way into the next Boost release. Thanks, Deniz PS: There is another open pull-request [5] (by John Maddock) which seems to be even more urgent. [1] https://svn.boost.org/trac/boost/ticket/12291 [2] https://svn.boost.org/trac/boost/ticket/12292 [3] https://github.com/boostorg/type_erasure/pull/9 [4] https://github.com/boostorg/type_erasure/pull/10 [5] https://github.com/boostorg/type_erasure/pull/11 -- BENOCS GmbH Dipl.-Inform. Deniz Bahadir Winterfeldtstr. 21 10781 Berlin Germany Phone: +49 - 30 / 577 0004-22 Email: deniz.bahadir(a)benocs.com www.benocs.com Board of Management: Michael Wolz, Dr.-Ing. Oliver Holschke, Dr.-Ing. Ingmar Poese Commercial Register: Amtsgericht Bonn HRB 19378

2 1

[Hana/Fit] about constexpr/noexcept on equivalent functions to std::overload
by Vicente J. Botet Escriba 08 Jul '16

08 Jul '16

Hi, On the C++ standard meating in Oulu, we decided to make the std::overload function constexpr and conditionaly noexcept and ensure that the overloaded functions shall be constexpr if the stored finctions are. I don't find in the reference documentation of Hana and Fit any reference of whether the overloaded functions preserve constexpr or not. There is a reedit post [1] and CWG issue 1581 [2] that are related. Could the authors clarify? What other think? Best, Vicente [1] https://www.reddit.com/r/cpp/comments/35g7f6/c17_progress_update/cr4mvid [2] http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1581

3 6

[config] msvc-14 config changes heads up
by John Maddock 08 Jul '16

08 Jul '16

I've just pushed some changes to develop so that MSVC-14.0 update 3 no longer defines: BOOST_NO_CXX14_VARIABLE_TEMPLATES BOOST_NO_SFINAE_EXPR BOOST_NO_TWO_PHASE_NAME_LOOKUP As far as I can tell, these cause no new regressions in develop, please let me know if I've missed something. I haven't stopped defining BOOST_NO_CXX11_CONSTEXPR as it causes new failures: * Multiprecision, one new failure when using constexpr features, looks harmless. * Metaparse, causes the compiler to run out of resources on a couple of tests - these test non-default values of BOOST_METAPARSE_LIMIT_STRING_SIZE and are probably harmless. * Type_erasure, causes one new runtime failure. * Chrono, nothing much compiles - this one is the showstopper and needs investigating - any takers? Best, John.

7 13

[qvm] help with tests
by Emil Dotchevski 06 Jul '16

06 Jul '16

It appears that the QVM tests are broken somehow but it isn't clear to me what might be wrong. It shows "pass" next to __boost_check_library__, but there are no results for the actual tests. It used to work fine earlier -- this issue might be related somehow to a previous problem, where I had a build directory without realizing that the test framework recognized that name and did things I did not intend; so I renamed the build directory to bld. Can someone help me fix this? Thanks, Emil

3 7

Re: [boost] Boost numeric conversion - unary function deprecated or removed for C++17
by Brandon Kohn 06 Jul '16

06 Jul '16

Sent from Mail for Windows 10 From: Paul A. Bristow Sent: Monday, July 4, 2016 12:48 PM To: boost(a)lists.boost.org Subject: [boost] Boost numeric conversion - unary function deprecated or removed for C++17 >Can anyone help please. I’ve pushed fixes for this. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

3 4

Boost numeric conversion - unary function deprecated or removed for C++17
by Paul A. Bristow 06 Jul '16

06 Jul '16

I need to use C++17 (or MSVC std:c++latest) for other reasons, but I am blocked on MSVC by failure to compile converter.hpp It works OK on GCC 6.1.1 but not on VS2015 update 3 http://stackoverflow.com/questions/33114656/replacement-for-binary-function http://stackoverflow.com/questions/33114656/replacement-for-binary-function I suspect that GCC has not yet removed the deprecated unary_function but that MSVC correctly has removed it? Updating this looks above my pay grade. Can anyone help please. Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830

3 2

[1.61.0][container] Error compiling alloc_lib.c with -std=c++11
by Richard Hadsell 05 Jul '16

05 Jul '16

I am trying to build Boost 1.61.0 with Clang and C++11 features. Other parts of the library warn about using C++11 features, if I do not build with the option -std=c++11. However, this C source file gives an error, and I assume it does not build at all: clang-linux.compile.c.without-pth bin.v2/libs/container/build/clang-linux-3.5.0/release/instruction-set-core2/threading-multi/alloc_lib.o error: invalid argument '-std=c++11' not allowed with 'C/ObjC' "[snip]clang++" -c -x c -O3 -Wno-inline -Wall -std=c++11 -fPIC -gcc-toolchain [snip]gcc/4.8.3 -Wno-[snip] -march=core2 -pthread -fPIC -m64 -DBOOST_ALL_NO_LIB=1 -DBOOST_CONTAINER_DYN_LINK=1 -DNDEBUG -I"." -c -o "bin.v2/libs/container/build/clang-linux-3.5.0/release/instruction-set-core2/threading-multi/alloc_lib.o" "libs/container/src/alloc_lib.c" ...failed clang-linux.compile.c.without-pth bin.v2/libs/container/build/clang-linux-3.5.0/release/instruction-set-core2/threading-multi/alloc_lib.o... These are the options from my user-config: using clang : 3.5.0 : [snip]/clang++ : <compileflags>"-std=c++11 -fPIC -gcc-toolchain [snip]/gcc/4.8.3 -Wno-[snip]" <linkflags>"-fPIC -gcc-toolchain [snip]/gcc/4.8.3" ; I don't see a way to provide C++-only flags or C-only flags. Actually, I thought that all Boost source files would be C++. -- Dick Hadsell 203-992-6320 Fax: 203-992-6001 Reply-to: hadsell(a)blueskystudios.com Blue Sky Studioshttp://www.blueskystudios.com 1 American Lane, Greenwich, CT 06831-2560

2 2

[meta] Hidden libraries.
by Daniel James 04 Jul '16

04 Jul '16

I just noticed that 'detail' and 'winapi' have started turning up in the library lists because they've added metadata files. We've always hidden these libraries in the past, so I'm thinking of adding an extra field to mark them as private/hidden libraries. Probably just something like: { "key": "detail", "name": "Detail", "private": true /* the rest.... */ } Any opinions?

4 4

[release] please add fiber to master
by Oliver Kowalke 03 Jul '16

03 Jul '16

Hello admins, I'd like to ask you to add boost.fiber to the master branch so that it will become part of the next boost release (1.62). thank you in advance, Oliver

3 7

What kind of algorithms/data structures can enter in Boost
by Зайцев Александр 03 Jul '16

03 Jul '16

Hello. I am interested in developing data structures and some algorithms in Boost library. But one of the requierement for library is: "The library should be generally useful". What does it mean? I think, that i can add to the library some more data structures: suffix tree/array/automata, palindromic tree, modifications of stack/queue for getting min/max with O(1), Aho–Corasick(maybe it's algo already exist in Boost Library), maybe something else (kd-tree, for example). And algortihms: Manacker's algo for calculating palindromes number, Longest increasing subsequence, palindromic check. There are many algorithms, which i can implement to the Boost library. Also Boost.Math versus GNU MP library is very simple. In GNU MP there are many useful features. And i don't know? we need to provide these features to the Boost.Math or not. Ok, Who can explain me, what algorithms of those that i mentioned, is generally useful? What is useful for Boost, and what is useless? Thanks. -- Best regards, Zaitsev Alexander

3 4

defect macro for thread_local?
by Oliver Kowalke 02 Jul '16

02 Jul '16

Hi, does boost provide a defect macro for thread_local (like BOOST_NO_CXX11_THREAD_LOCAL)? I couldn't find something similar int the boost macro reference. The macro would be helpful together with the feature-check to exclude compilers, that do not support the keyword thread_local (as gcc-4.7. and apple's compiler), from unit-tests. Oliver

4 7

[1.61.0] building with Clang and c++11
by Richard Hadsell 02 Jul '16

02 Jul '16

I have downloaded 1.61.0 and want to build it with Clang. This is in my user-config: using clang : 3.5.0 : /netDISKS/master/netmt/LINUX_C65/app/clang/3.5.0/bin/clang++ : <compileflags>"-fPIC -gcc-toolchain /netDISKS/master/netmt/LINUX_C65/app/gcc/4.8.3 -Wno-overloaded-virtual -Wno-unused-function -Wno-unused-variable -Wno-c99-extensions -Wno-variadic-macros" <linkflags>"-fPIC -gcc-toolchain /netDISKS/master/netmt/LINUX_C65/app/gcc/4.8.3" ; When I build, I see warnings like these: ./boost/mpl/print.hpp:50:19: warning: in-class initialization of non-static data member is a C++11 extension [-Wc++11-extensions] const int m_x = 1 / (sizeof(T) - sizeof(T)); ^ ./boost/timer/timer.hpp:44:43: warning: 'long long' is a C++11 extension [-Wc++11-long-long] void clear() { wall = user = system = 0LL; } ^ ./boost/regex/v4/instances.hpp:124:34: warning: unknown warning group '-Wkeyword-macro', ignored [-Wunknown-pragmas] #pragma clang diagnostic ignored "-Wkeyword-macro" ^ When I add '-std=c++11' to the <compileflags> and <linkflags>, I get errors and warnings like these: clang-linux.compile.c.without-pth bin.v2/libs/container/build/clang-linux-3.5.0/release/instruction-set-core2/link-static/threading-multi/alloc_lib.o error: invalid argument '-std=c++11' not allowed with 'C/ObjC' "/netDISKS/master/netmt/LINUX_C65/app/clang/3.5.0/bin/clang++" -c -x c -O3 -Wno-inline -Wall -std=c++11 -fPIC -gcc-toolchain /netDISKS/master/netmt/LINUX_C65/app/gcc/4.8.3 -Wno-overloaded-virtual -Wno-unused-function -Wno-unused-variable -Wno-c99-extensions -Wno-variadic-macros -march=core2 -pthread -m64 -DBOOST_ALL_NO_LIB=1 -DBOOST_CONTAINER_STATIC_LINK=1 -DNDEBUG -I"." -c -o "bin.v2/libs/container/build/clang-linux-3.5.0/release/instruction-set-core2/link-static/threading-multi/alloc_lib.o" "libs/container/src/alloc_lib.c" libs/locale/src/shared/localization_backend.cpp:54:22: warning: 'auto_ptr' is deprecated [-Wdeprecated-declarations] std::auto_ptr<localization_backend> res(new actual_backend(backends,default_backends_)); ^ ./boost/regex/v4/instances.hpp:124:34: warning: unknown warning group '-Wkeyword-macro', ignored [-Wunknown-pragmas] #pragma clang diagnostic ignored "-Wkeyword-macro" ^ What options do I need to add or remove to build and use boost with no errors and as few warnings as possible? -- Dick Hadsell 203-992-6320 Fax: 203-992-6001 Reply-to: hadsell(a)blueskystudios.com Blue Sky Studios http://www.blueskystudios.com 1 American Lane, Greenwich, CT 06831-2560

5 6

New library? CallableTraits
by Barrett Adair 01 Jul '16

01 Jul '16

I posted about this a month ago, but I did not receive much response. Since then, I added an extended example use case, and I added a documentation section [1] that compares CallableTraits and Boost.FunctionTypes. I received some positive feedback this week in Aspen, and r/cpp also seemed to respond well [2], so I thought I'd give this another shot. Here are my questions for you: 1. Is there any interest in reviewing a future version of this for inclusion in Boost? 2. If so, does this belong in its own library, or should it be incorporated into Boost.TypeTraits or something similar? 3. What you like to see added, removed, renamed, or redesigned? I'd say CallableTraits is about 85% finished. Here's what's left: * Add INVOKE semantics to a couple of things for consistency (arity, etc) * Remove unused/undocumented code * Account for transaction_safe and C++17 noexcept * Finish/test the calling convention features * Finish/update the reference documentation * Write even more tests Cheers, Barrett [1] http://badair.github.io/callable_traits/doc/html/index.html#callable_traits… [2] https://www.reddit.com/r/cpp/comments/4ffmfs/callabletraits_never_write_ano… GitHub: https://github.com/badair/callable_traits Documentation from the top: http://badair.github.io/callable_traits/doc/html/index.html (reference section under construction)

5 11