- Boost - lists.preview.boost.org

CI errors in [serialization] windows cygwin, mingw builds
by Jeff Garland 11 Jul '20

11 Jul '20

I've been seeing a bunch of CI errors related to serialization that seem to be new. Not seeing this so much on the test dashboard however. https://ci.appveyor.com/project/jeking3/date-time-1evbf/builds/33988388 gcc.compile.c++ bin.v2\libs\serialization\build\gcc-mngw6\rls\cxstd-11-iso\thrd-mlt\vsblt-hdn\xml_iarchive.o gcc.compile.c++ bin.v2\libs\serialization\build\gcc-mngw6\rls\cxstd-11-iso\thrd-mlt\vsblt-hdn\xml_oarchive.o In file included from ./boost/archive/iterators/mb_from_wchar.hpp:31, from ./boost/archive/impl/xml_oarchive_impl.ipp:28, from libs\serialization\src\xml_oarchive.cpp:23: ./boost/archive/detail/utf8_codecvt_facet.hpp:20: warning: "BOOST_ARCHIVE_DECL" redefined 20 | #define BOOST_ARCHIVE_DECL | In file included from ./boost/archive/detail/auto_link_archive.hpp:26, from ./boost/archive/xml_oarchive.hpp:29, from libs\serialization\src\xml_oarchive.cpp:17: ./boost/archive/detail/decl.hpp:28: note: this is the location of the previous definition 28 | #define BOOST_ARCHIVE_DECL BOOST_SYMBOL_EXPORT | gcc.compile.c++ bin.v2\libs\serialization\build\gcc-mngw6\rls\cxstd-11-iso\thrd-mlt\vsblt-hdn\xml_archive_exception.o gcc.compile.c++ bin.v2\libs\serialization\build\gcc-mngw6\rls\cxs

3 7

Build Errors for ASIO on msvc-10.0 and -11.0
by Tom Kent 10 Jul '20

10 Jul '20

After seeing the announcement that library freeze is coming, I just tried building the master snapshot with the build scripts I use for building the windows releases. I encountered failures in msvc-10.0 and msvc-11.0 for ASIO. .\boost/asio/execution/any_executor.hpp(940) : error C2668: 'boost::asio::execution::detail::any_executor_base::query_fn_impl' : ambiguous call to overloaded function .\boost/asio/execution/any_executor.hpp(915): could be 'void boost::asio::execution::detail::any_executor_base::query_fn_impl<Ex,Prop>(void *,const void *,const void *,boost::type *)' with [ Ex=void, Prop=boost::asio::execution::context_as_t<boost::asio::execution_context &> ] .\boost/asio/execution/any_executor.hpp(902): or 'void boost::asio::execution::detail::any_executor_base::query_fn_impl<Ex,Prop>(void *,const void *,const void *,boost::type *)' with [ Ex=void, Prop=boost::asio::execution::context_as_t<boost::asio::execution_context &> ] .\boost/asio/execution/any_executor.hpp(887): or 'void boost::asio::execution::detail::any_executor_base::query_fn_impl<Ex,Prop>(void *,const void *,const void *,boost::type *)' with [ Ex=void, Prop=boost::asio::execution::context_as_t<boost::asio::execution_context &> ] .\boost/asio/execution/any_executor.hpp(875): or 'void boost::asio::execution::detail::any_executor_base::query_fn_impl<Ex,Prop>(void *,const void *,const void *,boost::type *)' with [ Ex=void, Prop=boost::asio::execution::context_as_t<boost::asio::execution_context &> ] .\boost/asio/execution/any_executor.hpp(859): or 'void boost::asio::execution::detail::any_executor_base::query_fn_impl<Ex,Prop>(void *,const void *,const void *,boost::type *)' with [ Ex=void, Prop=boost::asio::execution::context_as_t<boost::asio::execution_context &> ] .\boost/asio/execution/any_executor.hpp(849): or 'void boost::asio::execution::detail::any_executor_base::query_fn_impl<Ex,Prop>(void *,const void *,const void *,boost::type *)' with [ Ex=void, Prop=boost::asio::execution::context_as_t<boost::asio::execution_context &> ] .\boost/asio/execution/any_executor.hpp(837): or 'void boost::asio::execution::detail::any_executor_base::query_fn_impl<Ex,Prop>(void *,const void *,const void *,boost::type *)' with [ Ex=void, Prop=boost::asio::execution::context_as_t<boost::asio::execution_context &> ] .\boost/asio/execution/any_executor.hpp(827): or 'void boost::asio::execution::detail::any_executor_base::query_fn_impl<Ex,Prop>(void *,const void *,const void *,void *)' with [ Ex=void, Prop=boost::asio::execution::context_as_t<boost::asio::execution_context &> ] while trying to match the argument list '(void *, const void *, const void *, int)' .\boost/asio/execution/any_executor.hpp(1782) : see reference to function template instantiation 'void boost::asio::execution::detail::any_executor_base::query_fn<Ex,T1>(void *,const void *,const void *)' being compiled with [ Ex=void, T1=boost::asio::execution::context_as_t<boost::asio::execution_context &> ] .\boost/asio/execution/any_executor.hpp(1782) : see reference to function template instantiation 'const boost::asio::execution::detail::any_executor_base::prop_fns<Poly> *boost::asio::execution::any_executor<<unnamed-symbol>,boost::asio::execution::detail::blocking::never_t<I>,boost::asio::execution::prefer_only<InnerProperty>,boost::asio::execution::prefer_only<boost::asio::execution::detail::outstanding_work::tracked_t<0>>,boost::asio::execution::prefer_only<boost::asio::execution::detail::outstanding_work::untracked_t<0>>,boost::asio::execution::prefer_only<boost::asio::execution::detail::relationship::fork_t<0>>,boost::asio::execution::prefer_only<boost::asio::execution::detail::relationship::continuation_t<0>>>::prop_fns_table<void>(void)' being compiled with [ Poly=boost::asio::execution::any_executor<boost::asio::execution::context_as_t<boost::asio::execution_context &>,boost::asio::execution::detail::blocking::never_t<0>,boost::asio::execution::prefer_only<boost::asio::execution::detail::blocking::possibly_t<0>>,boost::asio::execution::prefer_only<boost::asio::execution::detail::outstanding_work::tracked_t<0>>,boost::asio::execution::prefer_only<boost::asio::execution::detail::outstanding_work::untracked_t<0>>,boost::asio::execution::prefer_only<boost::asio::execution::detail::relationship::fork_t<0>>,boost::asio::execution::prefer_only<boost::asio::execution::detail::relationship::continuation_t<0>>>, <unnamed-symbol>=boost::asio::execution::context_as_t<boost::asio::execution_context &>, I=0, InnerProperty=boost::asio::execution::detail::blocking::possibly_t<0> ] .\boost/asio/execution/any_executor.hpp(1782) : while compiling class template member function 'boost::asio::execution::any_executor<<unnamed-symbol>,boost::asio::execution::detail::blocking::never_t<I>,boost::asio::execution::prefer_only<InnerProperty>,boost::asio::execution::prefer_only<boost::asio::execution::detail::outstanding_work::tracked_t<0>>,boost::asio::execution::prefer_only<boost::asio::execution::detail::outstanding_work::untracked_t<0>>,boost::asio::execution::prefer_only<boost::asio::execution::detail::relationship::fork_t<0>>,boost::asio::execution::prefer_only<boost::asio::execution::detail::relationship::continuation_t<0>>>::any_executor(void)' with [ <unnamed-symbol>=boost::asio::execution::context_as_t<boost::asio::execution_context &>, I=0, InnerProperty=boost::asio::execution::detail::blocking::possibly_t<0> ] .\boost/asio/detail/io_object_impl.hpp(168) : see reference to class template instantiation 'boost::asio::execution::any_executor<<unnamed-symbol>,boost::asio::execution::detail::blocking::never_t<I>,boost::asio::execution::prefer_only<InnerProperty>,boost::asio::execution::prefer_only<boost::asio::execution::detail::outstanding_work::tracked_t<0>>,boost::asio::execution::prefer_only<boost::asio::execution::detail::outstanding_work::untracked_t<0>>,boost::asio::execution::prefer_only<boost::asio::execution::detail::relationship::fork_t<0>>,boost::asio::execution::prefer_only<boost::asio::execution::detail::relationship::continuation_t<0>>>' being compiled with [ <unnamed-symbol>=boost::asio::execution::context_as_t<boost::asio::execution_context &>, I=0, InnerProperty=boost::asio::execution::detail::blocking::possibly_t<0> ] .\boost/asio/basic_socket.hpp(1804) : see reference to class template instantiation 'boost::asio::detail::io_object_impl<IoObjectService,Executor>' being compiled with [ IoObjectService=boost::asio::detail::win_iocp_socket_service<boost::asio::ip::udp>, Executor=boost::asio::any_io_executor ] .\boost/asio/basic_datagram_socket.hpp(53) : see reference to class template instantiation 'boost::asio::basic_socket<Protocol,Executor>' being compiled with [ Protocol=boost::asio::ip::udp, Executor=boost::asio::any_io_executor ] libs\log\src\syslog_backend.cpp(315) : see reference to class template instantiation 'boost::asio::basic_datagram_socket<Protocol>' being compiled with [ Protocol=boost::asio::ip::udp ] Hopefully this can be cleared up before the beta. Thanks, Tom

3 3

[stl_interfaces] Ok to merge small fix to C++20-mode builds before release?
by Zach Laine 09 Jul '20

09 Jul '20

I have just committed a fix to develop that addresses compilation errors in C++20 builds. Is it too late to merge this to master? The change is here: https://github.com/boostorg/stl_interfaces/commit/6d31433af0b7cb8c7f9140ce4… Zach

2 2

[Boost][Outcome] Compile error?
by Emil Dotchevski 07 Jul '20

07 Jul '20

When exceptions are disabled, I get: In file included from ../../../../boost/outcome/result.hpp:34: In file included from ../../../../boost/outcome/boost_result.hpp:36: In file included from ../../../../boost/exception_ptr.hpp:9: In file included from ../../../../boost/exception/detail/exception_ptr.hpp:17: ../../../../boost/exception/detail/clone_current_exception.hpp:22:6: error: This header requires exception handling to be enabled. Is there a way to configure Outcome so it does not use (boost) exception_ptr?

5 20

[random] pull requests stacking up
by Jeff Garland 06 Jul '20

06 Jul '20

Just submitted a pull request for boost.random to remove dependence on system library. There's 17 open requests -- some of which are pretty easy maintenance items. Can someone give these some a look?

2 1

Boost.Beast state of play
by Richard Hodges 06 Jul '20

06 Jul '20

Dear all, As you know, Boost.Beast has a strong dependency on Boost.Asio. At the present time, Chris is working to finalise some significant changes to Asio. These changes have required some refactoring of Boost.Beast at short notice in order to continue to provide a functioning library. Boost.Asio has two significant customisation macros: BOOST_ASIO_NO_DEPRECATED and BOOST_ASIO_NO_TS_EXECTORS. The 1.74 release of Asio deprecates some classes and interfaces relevant to net.ts-style executors. In addition, it introduces execution-style executors. *There is no combination of the above flags (save for none of them) that will allow an unmodified dependent library or program to compile as of boost.asio 1.74.* As of this moment, Beast is correctly compiling all examples and passing all tests with the exception of tests relevant to c++20 coroutines, where the latest Asio commit on develop branch has one (it would appear) remaining bug. Chris has been contacted and we are awaiting a fix. Once I have this, I will be in a position to rebase Beast PR1999 onto develop/master in readiness for the 1.74. Thank you for bearing with me during my time as an unwilling hostage to fortune. -- Richard Hodges hodges.r(a)gmail.com office: +442032898513 home: +376841522 mobile: +376380212

12 23

Fixed Boost.CallableTraits is_invocable_v
by Barrett Adair 03 Jul '20

03 Jul '20

It was recently brought to my attention that the variable template version of boost::callable_traits::is_invocable was always broken. A fix has been merged to match the non-variable version of the trait. I This is a minor change. Can this be included in 1.74? https://github.com/boostorg/callable_traits/commit/6da8b5a9b8b439f8e751191a…

2 1

[thread] Release critical bug (optimized away hooks)
by Nikita Kniazev 02 Jul '20

02 Jul '20

I am informing release managers that there is a severe bug in Boost.Thread that will affect static library users built with MSVC in the next release. The bug report: https://github.com/boostorg/thread/issues/316 (TLDR: thread_specific_ptr data destructor is not called in non-Boost.Thread threads) I have opened a PR that fixes the issue https://github.com/boostorg/thread/pull/320, but got no response in weeks.

2 1

How good to use dynamic_bitset?
by Jupiter 02 Jul '20

02 Jul '20

Hi, I am working on an embedded system where I read hardware 32-bit register values represented variables in bits. Currently I am using bit shift to extract values, it is too vague to represent variables. I have been thinking to make overhaul of using dynamic bitset, is it a good idea or bad idea? Thank you. Kind regards, jupiter -- "A man can fail many times, but he isn't a failure until he begins to blame somebody else." -- John Burroughs

3 4

Boost, not LEWG
by Glen Fernandes 01 Jul '20

01 Jul '20

(A new subject, since the thread has evolved past the Text review result). I spend part of my time in the C++ standards committee. I spend part of my time in Boost. I would prefer that my time spent in Boost, and that Boost itself, be focused on its goals of serving the C++ community and Boost users (existing ones, and growing to new ones). If there is benefit of Boost to any other entity, be it the LEWG of the committee, or some organization, that's great. i.e. When Boost is adopted by some organization, or when Boost components go into the standard, that's just a bonus. But Boost itself shouldn't compromise on quality - in its review process or what it ships in a Boost distribution, to serve any of those other interests. Putting a bunch of experimental libraries into a Boost release just because people have proposed them for standardization is not something we should do. If someone wants to, they can should just start their own project full of libraries that have not undergone any kind of formal review, and convince OS distributions to start including that as part of their packages based on its own merits. In case there was any misunderstanding on this point: Zach's goals of standardization are his own, and in Boost we don't have to be concerned with them. Because we're not changing the review process because of them, and he's not asking us to. Glen

16 40

[containers] Addition of a dense map implementation
by Jeremy Junac 29 Jun '20

29 Jun '20

Hi, While working on different projects in which performance is key, I came to realize that the efficiency of the associative containers that are available in the STL can be improved. For instance, it is well know that neither std::unordered_map nor std::map are cache-friendly. It isn't that hard to find implementations that are faster, for instance flat_map, already in Boost.Containers. However, I would be interested in another implementation, a "Dense Map", similar to the one we can find in SparseHash (https://github.com/sparsehash/sparsehash) or in LLVM's ADT (https://llvm.org/doxygen/DenseMap_8h.html) For sure I am not the only one attracted to such implementation, as we can find several ones in the internet, although, it really lacks of "one true generic implementation". SparseHash doesn't seem that maintained anymore and, well, LLVM is LLVM. Hence, instead of having yet another implementation of my own, I would rather have one in Boost, to ensure long-term maintainability. I know that this particular subject was kind of already discussed in this thread from 2016 (https://lists.boost.org/Archives/boost//2016/01/227076.php) and some very good points were made. But in the end, years have passed, and we still don't have an alternative, so in my opinion an implementation in Boost would actually be something to consider. Please let me know what you think about that. I am open to any other ideas, and in case we agree on the addition of a new implementation, I would actually be pleased to contribute. Best regards, Jeremy Junac

2 1

Re: [boost] Boost, not LEWG
by pbristow＠hetp.u-net.com 29 Jun '20

29 Jun '20

> -----Original Message----- > From: Boost <boost-bounces(a)lists.boost.org> On Behalf Of Vinnie Falco via Boost > Sent: 29 June 2020 06:40 > To: boost(a)lists.boost.org List <boost(a)lists.boost.org> > Cc: Vinnie Falco <vinnie.falco(a)gmail.com> > Subject: Re: [boost] [OT] Re: Boost, not LEWG > > On Sun, Jun 28, 2020 at 10:22 PM Schrom, Brian T via Boost <boost(a)lists.boost.org> wrote: > > My suggestion is.... > > Yeah mailing lists are nice for the monotonically decreasing set of older engineers used to the > anachronism but they are not in any way shape or form attractive for bringing in new, young blood. As one no longer in the first flush of youth (and I suspect a target of this barb 😉 ), I'm not sure that this is the most important issue. We seem to have shifted to CVS, SVN and now GIT and GitHub a little ahead of the curve (and I note that GitHub gives you an email interface as well as a web one). I suspect that 'If it ain't broke, don't fix it." applies to the mailing list/forum issue. I think that the key problem with reviews in finding people who are knowledgeable enough to make useful comments. Often users are best-informed we can get. Too many reviews are theoretical analyses, not based on any 'real-life' use that would expose strengths and weaknesses. There has long been a chicken and egg issue, you don't get many users until a library is in Boost, and so you don't get much informed feedback. I still favor some sort of 'Candidate' status, formalizing the current 'Acceptance subject to changes' status, but giving wider visibility on the Boost GitHub site. Boost has spawned several standards, but also provided many libraries that are entirely unsuitable for standardization. I hope this will continue. Paul Bristow PS I have always been impressed by the overwhelmingly politeness of interchanges on Boost and WG21 etc, in contrast to the internet in general. I believe that Boost is also entirely gender and color-blind.

6 6

[text] [review] Text formal review result
by Glen Fernandes 29 Jun '20

29 Jun '20

Many thanks to Zach for submitting his third library, Text, for Boost formal review. And thank you to the Boost community for participating. You can jump to result at the end of this email. The review period ran from June 11 to June 20 and we received a total of four reviews (three within the period). I won't summarise individual points, all reviews are accessible in the Boost list archives. 1. Emil Dotchevski submitted an early review, on June 3. He voted to accept the entire library with no conditions. 2. Rainer Deyke submitted a review on June 12. He voted to accept only the Unicode algorithms. 3. Phil Endecott submitted a review on June 18. He voted to accept only the UTF transcoding algorithms, and accept the Unicode layer providing the license issue is resolved. 4. JeanHeyd Meneide submitted a review after the review period ended, on June 21. He voted to accept the Unicode layer, and require that the text layer (if accepted) use std::string instead. I received no private reviews, but one email expressing concern about the copyright issue and eligibility for review. My thanks to Emil, Rainer, Phil, and JeanHeyd for your reviews. Thanks also to Gavin Lambert, Vinnie Falco, Alexander Grund, Villie Voutilainen, and everyone who participated in the discussion. The following points had the most weight in the review result that follows: 1. No desire for the string layer The bar for a custom string type is high. On a minor note presents incompatibilities with interfaces using std::string. On a major note a string replacement should give users things they currently depend on in std::basic_string. One of these is the ability to control dynamic allocations. Another is working with strings larger than 2GB. Allocators are not only about performance; i.e. the argument that supporting custom allocators would compromise the performance of the implementation is not enough to justify their absence. Users have the need to choose which area of dynamic memory their objects live in. In some cases users have a requirement that all dynamic allocations go through a custom (and stateful) allocator. JeanHeyd mentioned the now-deprecated wstring_convert functions which, despite their shortcomings, were usable. I filed LWG 2226 (http://wg21.link/lwg2226) years ago while at Microsoft because we had to reject its use in such a project where every dynamic allocation had to support stateful allocators, and wstring_convert did not. The end result was the developer reimplementing the functionality with proper support for stateful allocators. Supporting customizing allocation doesn't necessarily have to involve the current allocator model that containers or other standard library allocator-aware facilities support. As long as it provides the user with a similar level of control. 2. No strong acceptance for the text layer I won't repeat the points here. There was no strong desire expressed to have the text layer in Boost. The compromise to have it backed by std::string was still expressed in light of several shortcomings. 3. Portions of the library under a non-BSL license Phil identified three cases where the library did not have appropriate licensing. One was a simple omission, another has been resolved by the relevant code being relicensed under the BSL, but the other is still pending. We have a strict requirement for Boost licensing of code and data in our libraries that ship in the Boost distribution, and we cannot compromise on this. Zach understands this (he's authored two successful Boost libraries) and I'm confident he will address this. 4. A strong desire to have the Unicode layer in Boost Especially the encoding transcoding, the Unicode algorithms part of the library was well received. The reviews - though small in number - have convinced me of the value of accepting this layer of the library, provided the submission in question (all code and data) is licensed entirely under the BSL. A minor issue: 1. For a library of this size (all three layers are of non-trivial implementation size), I hoped for more reviews and participation. Rather than extend the review period by an additional week, the feedback received above lead me to believe that for Boost's and Zach's benefit, the result below and the prescribed course of action would be better: The result of this review is to reject the Text library in its current form, but to ask Zach to submit a subset of the library containing only the Unicode layer for mini-review, incorporating the feedback pertaining to it in this review. Where all of the code and data is licensed only under the BSL. The review wizard has the ability to grant a 5-day mini-review instead of a full 10-day review, and I've petitioned Mateusz to grant that Zach have this opportunity if he chooses for a second review of a library with just the Unicode layer. The text layer (backed by std::string, but ideally designed one that does not inhibit use of custom allocators ) could be reviewed as a separate library, to improve the chances of getting the Unicode algorithms in the hands of Boost users. My thanks once again to Zach for submitting his Text library for a review, and I hope that the second time's the charm. Glen

15 39

Re: [boost] [text] [review] Text formal review result
by Nikita Kniazev 28 Jun '20

28 Jun '20

> Mailing list sucks. I agree with this. I almost never reply to the mail list because I really have no idea how to do it without top-posting (I subscribed to daily digests). Simply, mail lists have only a single advantage -- everyone has an email. No code highlighting, quotes in digest are a bunch of '>' symbols and no threading. > We absolutely should move to a forum on boost.org for all things, > import as much as we can from the mailing list (as far back as > possible) into the forum, and then cease the use of the mailing list > forever. Anyone who emails the list should get an automated reply that > says "Please register for the wonderful forums at boost.org" etc With something like Discourse you can still use the old and good email to reply to posts (like on GitHub) and even to create threads ( https://meta.discourse.org/t/can-i-start-a-new-topic-by-sending-an-email-me… ).

1 0

[release] 1.74.0 deadline for new libraries is almost here!
by Marshall Clow 26 Jun '20

26 Jun '20

Tomorrow the master branch will be closed for new libraries and breaking changes. See the calendar here for more dates: https://www.boost.org/development/ <https://www.boost.org/development/> The next deadline is 1-July, when the master branch will be closed for major changes Thanks, — The Boost Release Team

2 3

Boost.Text review
by Phil Endecott 25 Jun '20

25 Jun '20

This is my review of Zach Laine's proposed Boost.Text. Zach is offering several things here: Unicode, a "better string", a trie, and more. I'm pleased that these components are all individually exposed to users and are independent of each other, rather than some being hidden as implementation details. I've spent a couple of days looking at a few parts of the library. I'll discuss at the Unicode stuff first. Boost gained support for Unicode functionality when Boost.Locale was accepted almost a decade ago, but I was not particularly impressed by that library and have not used it in my own work. Does the current proposal do better? I think it does, and though it's not perfect I think it would be worth accepting but subject to a concern about copyright. See another thread for the copyright discussion. Basically, if I understand correctly, Zach's code includes tables that are derived from Unicode data and the licence for that data requires a copyright attribution. The Boost licence does not require attribution and I support that. So if I've understood the situation correctly - and I am not a lawyer! - this means that sadly Boost must REJECT the affected code. I'll say some more about the other aspects of the Unicode code, just in case the copyright issue turns out to be surmountable. I've tried just a couple of things. Firstly, I tried the UTF-8 to UTF-32 conversion. This seems to work, and the API is reasonable. Performance is not bad, but it could be better (see another thread); that could be fixed later. I think it would be worth having just a UTF library in Boost! Secondly I looked at the line-splitting algorithm, i.e. template<typename CPIter, typename Sentinel, typename Extent, typename CPExtentFunc> unspecified lines(CPIter first, Sentinel last, Extent max_extent, CPExtentFunc cp_extent, bool break_overlong_lines = true); Again this seems to work, and the API is reasonable. Reference documentation is somewhat lacking though; in the description of lines(), the requirements for CPExtentFunc need to be described, and the "unspecified" return type needs to document that it includes members including iter and hard_line_break. I think there are probably similar omissions in much of the reference documentation. I'm unconvinced by the use of the word "sentinel" here. A sentinel is a value with a special meaning, e.g. a terminating null; what you have here is an end-iterator. It's good that you're allowing the begin and end iterators to have different types, but I think you should name that type something like CPEndIter. The implementation of line splitting seems to call its word length callback more often than necessary, i.e. when a word overflows a line, that word is subsequently measured a second time. That should be easily fixable. Moving on to other parts of the proposal, I'm less happy with text::string. The first thing I noticed was the very strange decision to use int, rather than (signed?) size_t, for indexing; yes I do work with chunks of text larger than 2 GB! I would REJECT text::string for this alone. I also dislike the use of operator() to extract substrings; the meaning just isn't obvious: auto x = y(4); Is that the 4th character of y? Or the substring from 4 to the end? No, it's the substring from the start to 3. I'd need to add a comment to explain what it's doing. But actually there's another problem with that line: x is a non-owning view of that substring. I think that methods that return a view (or span, etc.) should have a name that makes that clear, e.g. "subview". (This wouldn't have been a problem before auto.) This came up in the static_string review, where the substr() method was originally proposed to return a view; that was renamed subview() with substr() returning a copied string. I don't mind that the string isn't templated on the char type, but I do miss the allocator support; I've used strings with arena allocators (for performance) and with shared memory allocators. I know allocator support is a lot of work but it is necessary, IMO. text::text seems to be the obvious combination of text::string with unicode functionality, and I've not looked at that. I have had a look at the trie; I have sometimes wondered to what extent a trie can be implemented in C++ that works as much as possible like a standard container so this is interesting. The docs should mention briefly why trie is here, i.e. where it is used, just in anticipation of that obvious question from users. trie::operator[] returns an "optional ref". But it's not like a std::optional; as well as operator* it has conversion operators to access the value. Zach notes that this is "wonky" when the value type is bool, but it also seems to break for me when it's int: boost::trie::trie_map<std::string, std::string> counts; auto x = counts["Hello"]; if (x) std::cout << "present\n"; else std::cout << "absent\n"; // Prints absent, OK. boost::trie::trie_map<std::string, int> int_counts; // Now int. auto y = int_counts["Hello"]; if (y) std::cout << "present\n"; else std::cout << "absent\n"; // ../text/include/boost/text/trie.hpp:78: // boost::trie::optional_ref<T, Const>::operator T&() & // [with T = int; bool Const = false]: Assertion `t_' failed. operator T&() is being called by if(y), rather than operator bool(). There aren't has_value() and value() methods that I can use to work around this. Like a few other things in this proposal, Zach has implemented trie::operator[] how he wishes the standard library worked. As another example, dereferencing a trie_map iterator doesn't return a pair<KEY,VALUE> as a normal associative container would, but rather a struct with members called key and value. At worst, this will hit problems that the standard solutions avoid (as above). At best, it will make the library more difficult to learn for users who are familiar with the standard library (including its problems), and make generic code less likely to work with it. As a test I wrote a simple program to count word frequencies: using counts_t = std::map<std::string,int>; counts_t counts; while (std::cin.good()) { std::string s; std::cin >> s; counts[s]++; } for (auto i: counts) { std::cout << i.first << " = " << i.second << "\n"; } It would be great if I could just change it to: using counts_t = boost::trie_map<std::string,int>; but I can't do that; I need to change things: struct count { int value = 0; }; // Wrap the int. boost::trie::trie_map<std::string, count> counts; while (std::cin.good()) { std::string s; std::cin >> s; // operator[] doesn't insert, so: auto r = counts[s]; if (r) r->value++; else counts.insert(s,count{1}); } for (auto i: counts) { std::cout << i.key << " = " << i.value.value << "\n"; } That works; how about performance? Trie should perform well when the stored strings frequently share common prefixes, so I've tested with a large web server log file; this has timestamps and URLs which share common prefixes. The results: std::map: run time 1.2 seconds, memory 1007 pages trie_map: run time 1.8 seconds, memory 4868 pages So that's rather disappointing. Some general comments: Some people care about whether libraries are header-only or not, and the docs should mention this, and possibly say which functionality can be expected to work header-only. I got quite a few missing field initializer and unused parameter warnings; please fix these if at all possible. (gcc 6.3, -W -Wall). I think you should re-order the docs so that the "Hello World" example is much earlier. Some functions clearly need to embed large Unicode tables; it would be useful if the docs mentioned roughly how much the executable size is increased by. Some source files are executable. Conclusions: I fear that the only part of this that Boost should accept is the UTF transcoding. The implementation is not perfect but we could work on that. The other Unicode stuff would be good to have but the copyright issue is a blocker. Regards, Phil.

10 14

Re: [boost] Boost.Random
by degski 25 Jun '20

25 Jun '20

On Thu, 25 Jun 2020 at 03:24, <pbristow(a)hetp.u-net.com> wrote: > > > > > *From:* degski <degski(a)gmail.com> > *Sent:* 24 June 2020 15:25 > *To:* boost <boost(a)lists.boost.org> > *Cc:* Paul A. Bristow <pbristow(a)hetp.u-net.com> > *Subject:* Re: [boost] Boost.Random > > > > > > On Mon, 22 Jun 2020 at 06:59, Paul A Bristow via Boost < > boost(a)lists.boost.org> wrote: > > Using > > > std::mt19937::result_type(std::chrono::system_clock::now().time_since_epoch().count()); > > as seed looks nice and 'portable', assuming C++11. > > No need to build Boost.Chrono library - the disadvantage that I was trying > to avoid. > > But using random_device looks even simpler, again assuming Standard C++11. > > using std::random_device; > random_device seeder; > static std::mt19937 generator(seeder()); > > > > This can be better, you should seed the generator with a std::seed_seq, > which you would seed with the std::random_device. > > > > If you use sax::aes_random_device non of the above is needed, the seeder > (can) serve as a CPRNG, with a speed comparable (but faster) than > std::mt19937_64 (on Windows). > > > > > Random zealots seem to have reservations about random_device - and pretty > much anything? > > > > As I said before about random zealots! > > > > I am only testing round tripping of iostream, so true randomness is > entirely unimportant. > > And since the tests take many hours, any time for a randomish seed is also > of zero concern > > > > > > ps: > > > > All seem to work at C++11 with latest MSVC, Clang and GCC. > > > > We almost 2021, C++11 is almost complete on all compilers. > > > > But not necessarily standard libraries – GCC and Clang fail > roundtrip/loopback binary > decimal > binary using std::hexfloat ☹ > C++17 has introduced <charconv>, this does what the old stuff does, but much better (faster, better (C-) API). Here your caveat applies, I'm not sure this is in every standard library. STL has done most of the heavy lifting, as IIRC the MSVC implementation will be ported to GCC/Clang, when deemed 'finished'. I have not seen any announcement anywhere, so I guess it's on-going. I think you'll get std::hexfloat when the respective C++17-STL's have <charconv>. > > But Thanks > > Paul > > > > -----Original Message----- > > From: Boost <boost-bounces(a)lists.boost.org> On Behalf Of Christopher > Kormanyos via Boost > > Sent: 20 June 2020 11:41 > > To: Paul A Bristow via Boost <boost(a)lists.boost.org> > > Cc: Christopher Kormanyos <e_float(a)yahoo.com> > > Subject: Re: [boost] Boost.Random > > > > > > > So would following the crowd and using time(0)> be simplest? > > I never liked time(0) for that particular use casebecause in the old > days it had multiple > > millisecondresolution and lacked the seed resolution sometimes. > > I do not know it the code below is best practice,but I usually use some > kind of variation of below.You > > can switch system_clock for high_resolution_clock. > > All this is straight off-the-rack C++11. > > > > > > #include <chrono> > > #include <iostream> > > #include <random> > > > > // Use time point now seed to get a different set of values each time. > > const std::mt19937::result_type seed = > > > std::mt19937::result_type(std::chrono::system_clock::now().time_since_epoch().count()); > > > > // uint32_t > > static std::mt19937 gen(seed); > > > > int main() > > { > > std::cout << gen() << std::endl; > > } > > > > > > > > On Thursday, June 18, 2020, 10:27:27 AM GMT+2, Paul A Bristow via > Boost <boost(a)lists.boost.org> > > wrote: > > > > > > > > > -----Original Message----- > > > From: Boost <boost-bounces(a)lists.boost.org> On Behalf Of John Maddock > > > via Boost > > > Sent: 17 June 2020 18:48 > > > To: Paul A Bristow via Boost <boost(a)lists.boost.org> > > > Cc: John Maddock <jz.maddock(a)googlemail.com> > > > Subject: Re: [boost] Boost.Random > > > > > > > > > On 17/06/2020 15:53, Paul A Bristow via Boost wrote: > > > > I have wanted to use boost::random::random_device; as a seeder for > my generator. > > > > > > > > #include <boost/random/random_device.hpp> // For > > > > boost::random::random_device; seeder > > > > > > > > But using this requires that I link to a library file // LINK : > > > > fatal error LNK1104: cannot open file > 'libboost_random-vc142-mt-gd-x64-1_73.lib' > > > > > > > > So I have instead used C++ std random device successfully > > > > > > > > using std::random_device; > > > > random_device seeder; > > > > // Use seeder to get a different set of values each time. > > > > static boost::random::mt19937 gen(seeder()); // uint32_t > > > > > > > > But is there any way I can stick to the Boost version (I imagine > > > > that it might prove more > > portable? > > > > Or is this a delusion?) > > > > > > What do you mean by portable? random_device is inherently > > > non-portable because it's.... random ;) > > > > By portable I mean 'works on as many platforms and C++ standard versions > as possible'. > > > > > In many ways this is something that the std:: version does best as the > > > system implementer knows > > best > > > how to implement on their OS. Or you could just link to Boost.Random > > > of course which would work nearly everywhere too I'm sure. > > > > I was just puzzled why Boost.Random needed to *link* when > std:random_device doesn't appear to. Is > > it quietly linking to a standard library? > > > > Paul > > > > PS Thanks for the even-more-random suggestions but I really, really > don't care how randomly random it > > is for my application. > > > > So would following the crowd and using time(0) be simplest? > > > > > > > > > > _______________________________________________ > > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost > > > > _______________________________________________ > > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost > > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost > >

1 0

Boost.Random
by pbristow＠hetp.u-net.com 24 Jun '20

24 Jun '20

I have wanted to use boost::random::random_device; as a seeder for my generator. #include <boost/random/random_device.hpp> // For boost::random::random_device; seeder But using this requires that I link to a library file // LINK : fatal error LNK1104: cannot open file 'libboost_random-vc142-mt-gd-x64-1_73.lib' So I have instead used C++ std random device successfully using std::random_device; random_device seeder; // Use seeder to get a different set of values each time. static boost::random::mt19937 gen(seeder()); // uint32_t But is there any way I can stick to the Boost version (I imagine that it might prove more portable? Or is this a delusion?) Suggestions welcome. Paul

5 8

Boost Python issue with converters
by Dominik Cirmirakis 23 Jun '20

23 Jun '20

Hi, I have a question regarding the below code. It's an example how to pass a custom class via shared_ptr to embedded python code and it works when boost is dynamically linked. Unfortunately the same code with statically linked boost doesn't work with the following error message: "No to_python (by-value) converter found for C++ type: class boost::shared_ptr<class Foo>". I don't understand why a different linking can affect type recognition of a registered converter. What am I missing? Can anybody help me out? Thanks, Dominik https://stackoverflow.com/questions/8225934/exposing-a-c-class-instance-to-… |#include<boost/shared_ptr.hpp>#include<boost/make_shared.hpp>#include<boost/python.hpp>#include<string>#include<iostream>namespacebp =boost::python;structFoo{Foo(){}Foo(std::stringconst&s):m_string(s){}voiddoSomething(){std::cout <<"Foo:"<<m_string <<std::endl;}std::stringm_string;};typedefboost::shared_ptr<Foo>foo_ptr;BOOST_PYTHON_MODULE(hello){bp::class_<Foo,foo_ptr>("Foo").def("doSomething",&Foo::doSomething);};| |#include<boost/shared_ptr.hpp>#include<boost/make_shared.hpp>#include<boost/python.hpp>#include<string>#include<iostream>namespacebp =boost::python;structFoo{Foo(){}Foo(std::stringconst&s):m_string(s){}voiddoSomething(){std::cout <<"Foo:"<<m_string <<std::endl;}std::stringm_string;};typedefboost::shared_ptr<Foo>foo_ptr;BOOST_PYTHON_MODULE(hello){bp::class_<Foo,foo_ptr>("Foo").def("doSomething",&Foo::doSomething);};intmain(intargc,char**argv){Py_Initialize();try{PyRun_SimpleString("a_foo = None\n""\n""def setup(a_foo_from_cxx):\n"" print 'setup called with', a_foo_from_cxx\n"" global a_foo\n"" a_foo = a_foo_from_cxx\n""\n""def run():\n"" a_foo.doSomething()\n""\n""print 'main module loaded'\n");foo_ptr a_cxx_foo =boost::make_shared<Foo>("c++");inithello();bp::objectmain =bp::object(bp::handle<>(bp::borrowed(PyImport_AddModule("__main__"))));// pass the reference to a_cxx_foo into python:bp::objectsetup_func =main.attr("setup");setup_func(a_cxx_foo);// now run the python 'main' functionbp::objectrun_func =main.attr("run");run_func();}catch(bp::error_already_set){PyErr_Print();}Py_Finalize();return0;}|

1 0

[review][text] Text review has ended
by Glen Fernandes 22 Jun '20

22 Jun '20

The formal review for the Text library ended on June 20th. Thank you to everyone who participated by submitting a review, or by contributing to the discussion. A result will be posted on Friday, 2020-06-26 but continued discussion on the list in the meanwhile is more than welcome. Glen

1 0

[review] [text] Text formal review
by Glen Fernandes 22 Jun '20

22 Jun '20

Dear Boost community, The formal review of Zach Laine's Unicode library, Text, begins today (June 11th) and ends on June 20th. The library provides three layers: - The string layer, a set of types that constitute "a better std::string" - The Unicode layer, consisting of the Unicode algorithms and data - The text layer, a set of types like the string layer types, but providing transparent Unicode support Code: https://github.com/tzlaine/text Docs: https://tzlaine.github.io/text The master branch of the repository will be frozen for the duration of the review. Text requires C++14 or higher, and supports GCC 5+, Clang 3.6+, and MSVC 2017. Zach initially presented the library at C++Now in 2018. He also intends to standardize a library solution for Unicode based on this work. Talk: https://www.youtube.com/watch?v=944GjKxwMBo Slides: https://tinyurl.com/boost-text-slides We encourage your participation in this review. At a minimum, kindly state: - Whether you believe the library should be accepted into Boost * Any conditions for acceptance - Your name and knowledge of the problem domain. You are strongly encouraged to also provide additional information: - What is your evaluation of the library's: * Design * Implementation * Documentation * Tests * Usefulness - Did you attempt to use the library? If so: * Which compiler(s) * What was the experience? Any problems? - How much effort did you put into your evaluation of the review? Even if you are not submitting a formal review, your feedback on the library is welcome. Glen

10 21

[text] Copyright notices
by Phil Endecott 20 Jun '20

20 Jun '20

Dear All, Looking at the proposed Boost.Text source, I find that: 1. Many files don't have a copyright header. Random example: https://github.com/tzlaine/text/blob/master/include/boost/text/unencoded_ro… I guess this is an oversight and is easily fixed. 2. Some files have a copyright header which is not the Boost licence. Example: https://github.com/tzlaine/text/blob/master/include/boost/text/transcode_al… This one has a requirement that binary distribution includes the copyright notice, which is not a requirement of the Boost licence, and will be problematic for some users. Are the only affected files the SIMD implementation, (c) Robert N Steagall? If so, can this be disabled (by default?) by the user to avoid the copyright notice requirement? 3. The documentation includes a Unicode copyright notice: https://tzlaine.github.io/text/doc/html/boost_text__proposed_/unicode_copyr… This also includes a requirement that the copyright notice is included in data files, software or associated documentation, whatever that means. It's not clear to me what this actually covers; again, can some functionality (e.g. UTF-N-to-M conversion without normalisation) work without the Unicode data? Regards, Phil.

8 15

[text] Comparison with Unicode features of Boost.Locale
by Phil Endecott 19 Jun '20

19 Jun '20

Dear Zach & others, Boost already has some Unicode functionality in Boost.Locale. Would you like to compare the pros/cons of each? Regards, Phil.

3 3

[text] SIMD UTF-8 decoding
by Phil Endecott 18 Jun '20

18 Jun '20

Dear All, I have been looking at the UTF-8 decoding code in the proposed Boost.Text, as this is a problem I've looked at myself in the past. I've mentioned an issue with the copyright in another message. Here are my other observations. 1. The SIMD code is x86-specific. It doesn't need to be; I think it could use gcc's vector builtins to do the same thing and be portable to other SIMD implementations. (Clang provides the same builtins; I'm not sure about what you need to do on MSVC/Windows.) See: https://gcc.gnu.org/onlinedocs/gcc/Vector-Extensions.html 2. The SIMD code only seems to provide a fast path for bytes < 0x80, falling back to sequential code for everything else. I guess I was expecting something more sophisticated. 3. The code used for bytes >= 0x80, and in all cases for non-x86, is here: https://github.com/tzlaine/text/blob/master/include/boost/text/transcode_it… around lines 400-560. It implements a state machine, which surprises me; it takes much less code and gives better performance if you write out the bit-testing and shifting etc. explicitly. This seems to be about 50% slower than my existing UTF-8 decoding code. 4. There aren't enough comments anywhere in the code I've looked at! Regards, Phil.

4 6

[container] Proposal for ring queues
by Andrey Semashev 17 Jun '20

17 Jun '20

Hi, Some time ago I have proposed to include ring_queue and small_ring_queue containers to Boost.Container: https://github.com/boostorg/container/pull/121 The ring queues work similarly to std::queue with the main difference being that they use a ring buffer internally to store elements. The small_ring_queue also allows to allocate a static storage for a fixed amount of elements. The benefit of this is that dynamic memory allocations can be practically avoided when the number of enqueued elements does not exceed some limit. In his reply in that PR Ion was not very enthusiastic about including these containers into Boost.Container mostly because (a) there was presumably not much interest from users and (b) because the current implementation requires C++17 while Boost.Container supports C++03. I would like to ask if there is interest in the community for these kinds of containers. I know I would find them useful, and at least one person commented in the PR to the same effect. However, I would still like to see if more people need this. If there is interest, what would be the preferred course of action? 1. Should we work on inclusion into Boost.Container or maybe some other library? Candidates? Boost.CircularBuffer was mentioned in the PR, although I'm not sure it is suitable for these components. Creating a new submodule is also a possibility, although it seems like an overkill. 2. Somewhat related to p.1, what minimum C++ version is preferred. E.g. if we agree that Boost.Container is the right place for these components, I could work on lowering minimum C++ version, although C++03 would complicate things considerably. Thanks.

9 28

Re: [boost] [text] Copyright notices
by Andrey Semashev 16 Jun '20

16 Jun '20

On 2020-06-16 17:43, Hans Dembinski wrote: >> On 16. Jun 2020, at 16:41, Hans Dembinski <hans.dembinski(a)gmail.com> wrote: >> >>> >>> On 16. Jun 2020, at 16:32, Andrey Semashev via Boost <boost(a)lists.boost.org> wrote: >>> >>> On 2020-06-16 16:45, Hans Dembinski via Boost wrote: >>>>> On 16. Jun 2020, at 14:53, Niall Douglas via Boost <boost(a)lists.boost.org> wrote: >>>>> >>>>> On 15/06/2020 17:19, Phil Endecott via Boost wrote: >>>>> >>>>>> Are the only affected files the SIMD implementation, (c) Robert N >>>>>> Steagall? If so, can this be disabled (by default?) by the user >>>>>> to avoid the copyright notice requirement? >>>>> >>>>> If that's *the* Bob Steagall I'm almost certain he'll relicence his code >>>>> under Boost if you ask him. >>>> I think a multi-platform library like Boost should avoid using SIMD intrinsics and write the code so that the auto-vectorisers of the compilers understand it - if that is possible. I don't claim it is possible here, but I have a lot of trust in the auto-vectorisers of gcc and clang. Godbolt is very helpful in designing code that can be auto-vectorised well. >>> >>> In my experience, auto-vectorization is useless in all but trivial cases. >> >> Care to give me an example? > > I don't know what you consider trivial, but these examples here listed under "vectorizable" do not look trivial to me. > > https://gcc.gnu.org/projects/tree-ssa/vectorization.html The loops I see there are trivial. Any loop where you have two arrays and you apply an operation OP between elements of the arrays is trivial and actually not very often met in practice. In practice you often have: - Conditional expressions in loop body. - Non-trivial loop exit conditions. - Horizontal operations between elements of the same array. - Array elements more dense than int. (Auto-vectorizers tend to widen elements as per C++ promotion rules.) - Input data provided via pointers that may theoretically overlap. (Auto-vectorizers tend to be pessimistic about data overlap, unless persuaded by non-portable means.) Any of the above is typically poorly handled by auto-vectorizers, if at all. At least, that was my observation when I wrote code that I subsequently had to manually vectorize. PS: I'm sending this to the ML.

1 1

Re: [boost] linux build and version symlinks question
by Peter Dimov 16 Jun '20

16 Jun '20

> Aleksei Nikiforov wrote: > > > Besides just removing those symlinks after installation, what's the > > proper way for disabling creating these additional symlinks when > > building/installing boost using b2? > > I tried `b2 install install-no-version-symlinks=on`, but it had no effect. > So I guess the answer is "none". I suppose the right thing to do is to > reverse the change and reinstate the original behavior to not install > these symlinks on `b2 install`. I'm not quite sure about `b2 stage`, but > it should probably be consistent with `b2 install`, because many packaging > scripts use `stage` instead of `install` for some reason. See https://github.com/boostorg/boost_install/issues/43 and https://github.com/boostorg/boost_install/commit/ea28ed441fb04f2c5839e99e37…. If you see something wrong with these changes please let me know.

2 1

linux build and version symlinks question
by Aleksei Nikiforov 15 Jun '20

15 Jun '20

Hi. I've noticed that some versions ago boost started creating additional symlinks when built for linux. In addition to boost_${library}.so -> boost_${library}.so.A.B.C symlink, two more symlinks are created: boost_${library}.so.A -> boost_${library}.so.A.B.C and boost_${library}.so.A.B -> boost_${library}.so.A.B.C. Additional symlinks started appearing approximately around version 1.70.0. For example, boost 1.67.0 has library libboost_filesystem.so.1.67.0 and a symlink libboost_filesystem.so. Boost 1.73.0 has library libboost_filesystem.so.1.73.0 and 3 symlinks: libboost_filesystem.so, libboost_filesystem.so.1 and libboost_filesystem.so.1.73. My guess is that this change was introduced in following commit by removing install-no-version-symlinks feature for all libraries: https://github.com/boostorg/boost/commit/47ef674f752ad2cfeb581665cbea18ee6f… I couldn't find any mention of such change in changelog or any explanation or description of intention of this change. Did I miss it? Was it an unintentional change? In binary linux distributions, *.so files and header files are usually packed into devel packages, while *.so.* are packed into library packages. In case of boost and those symlinks it can lead to an issue. For example, during upgrade from boost 1.72.0 to boost 1.73.0, while both boost 1.72.0 libraries and 1.73.0 libraries are needed temporarily, boost_${library}.so.1 symlinks from both packages may conflict. These symlinks with same names point to different libraries. It's not an issue for devel packages and *.so symlinks with same names since you don't need two devel packages being installed at same time during upgrade. Besides just removing those symlinks after installation, what's the proper way for disabling creating these additional symlinks when building/installing boost using b2? Kind regards, Aleksei Nikiforov

4 9

[double-ended] where is it?
by degski 15 Jun '20

15 Jun '20

I remember going through this review. It was an active, lively and constructive review. Ever since I've been dying to use this new-fangled vector. The repo is dead, no dev branch being worked on. I am happy to implement this container starting from scratch, using the discussions we've had and the valuable comments as a base. I can give it a try, but it will (by the time it gets out of the sausage machine) be a C++20 lib. If that is not acceptable, then no-can-do. degski 🕔https://mega.nz/C!AlJBkaLI

4 4

Re: [boost] [review] [text] Text formal review
by Bjorn Reese 13 Jun '20

13 Jun '20

Why does Boost.Text contains trie types in their own boost::trie namespace?

2 1

[epochs] Strict vs. lax mode and epoch assignment reports
by Joaquin M López Muñoz 13 Jun '20

13 Jun '20

For those interested in the epoch proposal: * I've included a discussion on an alternative set of rules for epoch assignment dubbed "lax mode": https://github.com/joaquintides/boost_epoch#strict-vs-lax-mode This mode is somewhat more comprehensive that the original, strict mode, in the sense that more libs would progress to higher epochs. Comments welcome on which mode fulfills best the goals of the proposal. * I've written a utility to automate epoch assignment from a core set of human-decided lib rejections: * Strict mode: https://github.com/joaquintides/boost_epoch/blob/master/epoch_report.md * Lax mode: https://github.com/joaquintides/boost_epoch/blob/master/lax_epoch_report.md These are illustrative examples pretty much dependent on what libs are determined to be subsumed by the C++ standard or more modern Boost libs. You can try modifying this (https://github.com/joaquintides/boost_epoch/blob/master/epoch_report/booste… ) and running the epoch report tool to see the results. Best, Joaquín M López Muñoz

1 0

[Nowide] Opinion on slightly expanding the scope: LFS and more generic UTF-8 wide<->narrow conversion
by Alexander Grund 12 Jun '20

12 Jun '20

Hi all, just wanted to gather opinions on 2 changes I'd like to make to Boost.Nowide which go slightly above the initial goal: 1. Make detail implementations of widen/narrow public. - Mainly https://github.com/boostorg/nowide/blob/develop/include/boost/nowide/detail… which does templated conversion from/to wide strings which might be useful in generic contexts - But also the underlying UTF decoding/encoding templates initially extracted from Boost.Locale https://github.com/boostorg/nowide/blob/develop/include/boost/nowide/detail… I figured (and experienced) that those might be useful for consumers of Nowide as when they already use those UTF-8 APIs they might have other interface code which needs translation from/to wide strings, so exposing the existing code as a feature might make sense. Basically this would put them under boost::nowide::utf namespace instead of in the detail namespace. I guess I don't need to retain the old ones or put in forwarding headers, do I? 2. As requested and implemented over 2 PRs (last one still open: https://github.com/boostorg/nowide/pull/104) Large files are now supported by boost::nowide::filebuf (technically only used on Windows) but the implementation is pretty portable as e.g. Tests on Unix do use boost::nowide::filebuf. This is done by implementing ftell/fseek via _ftelli64/ftello and configure-time checking availability. As C++ is lacking C-Style file manipulation functions portably working with LFS I think a similar reasoning as above can be applied: It exists, it works and can be useful more generically so moving it out of the detail namespace might make sense. Opinions? Ideas? Regards, Alex PS: If anyone with filesystem experience would like to review #104 or at least glance over it, it would be appreciated.

2 3

How to clean boost::asio::streambuf before writing to it?
by Jupiter 10 Jun '20

10 Jun '20

Sorry, this is really a silly question, but I could not find a clear API in streambuf reference, I have following code to call PacketData in a loop, the buffer.get() looked to accumulate previous data in the buffer, so I should call buffer.clear() before calling buffer.get(), but apparently there no ‘clear’ in boost::asio::basic_streambuf. PacketData(const msgpack::sbuffer &sb, boost::asio::streambuf &buffer)) { ....... std::ostream os(buffer.get()); os.write((char *)&header, sizeof(header)); os.write((char *)sb.data(), sb.size()); ....... } Thank you. Kind regards, - jh -- "A man can fail many times, but he isn't a failure until he begins to blame somebody else." -- John Burroughs

3 4

Re: [boost] [Boost-users] Impossible to download a boost source from bintray: 403 Forbidden
by Marshall Clow 08 Jun '20

08 Jun '20

On Sat, Jun 6, 2020 at 10:34 AM Eisuke Kawashima via Boost-users < boost-users(a)lists.boost.org> wrote: > Dear All, > > I cannot download a boost source from bintray, e.g., > https://dl.bintray.com/boostorg/release/1.73.0/source/boost_1_73_0.tar.bz2 > returns 403 Forbidden. > OTOH, sourceforge works: > > https://sourceforge.net/projects/boost/files/boost/1.73.0/boost_1_73_0.tar.… > . > > We (boost) have reached our monthly allocation of bandwidth donated by Bintray/JFrog (Thanks, JFrog!) We're trying to figure out how we blew through that much bandwidth in 5+ days. (10s of TB). I will post here again when we know more. -- Marshall

2 2

problem with boost test matrix for serialization related to changes in file system?
by Robert Ramey 08 Jun '20

08 Jun '20

I made a few checkins to the serialization library which I had previously tested on my working system. But Now I'm getting some very weird errors in the Boost Test matrix: https://www.boost.org/development/tests/develop/developer/serialization.html Anyone who has some useful insight would be free to chime in. According to P Dimov, Filesystem is guilty and i should request help from andrey semashev - so here it is. Robert Ramey

3 3

[review][LEAF] Review of LEAF starts today : May 22 - May 31
by Michael Caisse 08 Jun '20

08 Jun '20

The Boost formal review of Emil Dotchevski's LEAF (Lightweight Error Augmentation Framework) library will take place from May 22 through May 31st. LEAF isn't just another error reporting library in the family of expected-like types. It provides a unique take on error handling which plays into usability, flexibility, and performance. Every software developer must deal with handling errors which makes this review relevant to all. Please participate! I will be grateful to receive a review based on whatever level of effort or time you can devote. LEAF is brought to us by Emil Dotchevski, the author of Boost.Exception. Similar to Boost.Exception, this library allows arbitrary error objects to be returned; however, unlike Boost.Exception it does not require dynamic memory. The library can be used with or without exception handling. The LEAF documentation highlights the following features: * Efficient delivery of arbitrary error objects to the correct error handling scope. * No dynamic memory allocations. * Compatible with std::error_code, errno and any other error code type. * Can be used with or without exception handling. * Support for multi-thread programming. "LEAF is designed with a strong bias towards the common use case where callers of functions which may fail check for success and forward errors up the call chain but do not handle them." LEAF offers a pattern matching facility to specify which errors to handle and how to handle them. Take a look at the 5-minute Introduction. <https://zajo.github.io/leaf/#introduction> You can find the source code to be reviewed here: <https://github.com/zajo/leaf/tree/review> You can find the documentation here: <https://zajo.github.io/leaf/> The documentation includes a tutorial, examples, reference, design rationale, and comparisons to other error handling approaches/libraries. There is a benchmark document also: <https://github.com/zajo/leaf/blob/master/benchmark/benchmark.md> and a whitepaper: <https://github.com/zajo/leaf/blob/master/doc/whitepaper.md> Please provide in your review information you think is valuable to understand your choice to ACCEPT or REJECT including LEAF as a Boost library. Please be explicit about your decision (ACCEPT or REJECT). Some other questions you might want to consider answering: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With which compiler(s)? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? More information about the Boost Formal Review Process can be found here: <http://www.boost.org/community/reviews.html> Thank you for your effort in the Boost community. Happy coding - michael -- Michael Caisse Ciere Consulting ciere.com

14 42

[atomic] Bikeshedding over address-free waiting/notifying operation names
by Andrey Semashev 07 Jun '20

07 Jun '20

Hi, As some of you may know, C++20 added new waiting/notifying operations to std::atomic: wait, notify_one and notify_all. These operations are not address-free, i.e. their implementation is allowed to use process-local addresses of the atomics as keys. In particular, it means you can't use them for inter-process communication. In Boost.Atomic I intend to provide address-free variants as well, where possible, and I'm thinking about the naming scheme for them. Currently, I'm using the "_address_free" suffix, so we have wait_address_free, notify_one_address_free and notify_all_address_free. The "address-free" term comes from the C++ standard, but the resulting names seem a bit long. Maybe there are better suggestions? Thanks.

6 11

[epochs] Boost conditional dependency map
by Joaquin M López Muñoz 05 Jun '20

05 Jun '20

As part of the epoch proposal, I've written a small toolchain to generate a so-called Boost conditional dependency map: https://github.com/joaquintides/boostcdmap/ Such a map gives, for each Boost module and each epoch Boost03, ... , Boost20, the dependencies of the module under the given epoch (which may vary across epochs). The actual map for Boost 1.73 is provided at: https://github.com/joaquintides/boostcdmap/blob/master/boostcdmap.1.73.0.js… The conditional dependency map is a key asset for the automation of epoch assignment; I'll elaborate on this point in the upcoming days. As always, comments welcome. Best regards, Joaquín M López Muñoz

1 0

[epochs] Internal relevance in post-C++03 Boost of Boost03 components vs. standard equivalents
by Joaquin M López Muñoz 05 Jun '20

05 Jun '20

For those of you who are following the discussion on epochs, I've just prepared a report on the relevance of "legacy" components intra-Boost for these Boost libs that require C++11 (or higher) to work: https://github.com/joaquintides/boost_epoch/blob/master/boost_vs_std_intern… Quoting from the report: "It can be seen that (direct) usage of Boost03 components is residual (and in some cases due to backwards compatibility rather than for their functionality). We can draw then the conclusion that newer Boost libraries are already dismissing legacy dependencies when the standard environment offers alternatives." Best, Joaquín M López Muñoz

2 3

[LEAF] A sort of review
by Andrzej Krzemienski 04 Jun '20

04 Jun '20

Hi Everyone, According to the schedule the review period of LEAF should have ended, but since I haven't heard a clear announcement, I assume it isn't too late to provide feedback. I regret that I cannot afford to make a full review of the library that Emil deserves. So this will be just "notes". I didn't have time to study the implementation of the library. I only read most of the documentation (documentation is really good), tried some toy examples to see if I can brake it (didn't manage to), and participated in Boost discussions on the subject. Only from this am I confident that the library has been well designed. Its goals are clearly set and sound, and the designed explained in the docs. We have competing libraries in Boost for error handling (Boost.Outcome) but they put accent on different things, and besides Boost is already known to host competing designs and approaches to the same problem. The need to transport arbitrary number of information collected at different levels of call stack is a sound goal, and well addressed in LEAF. The choice to put error data on the stack is great, and well understood and explored, for instance in https://www.research.ed.ac.uk/portal/files/78829292/low_cost_deterministic_… I find function preload() (https://zajo.github.io/leaf/#tutorial-preload) really great and novel. This is the first big C++ library that I know that implements it. This really makes the error reporting code brief, clean and bug-free. Some people have reported that the usage of multiple lambdas in try-catch-like statements is inconvenient. It is; but I think it works to the advantage of the library. My approach to handling errors based on skipping dependent operations ( https://akrzemi1.wordpress.com/2019/04/25/handling-errors-is-canceling-oper…) is that you report errors (start the "stack unwinding") in many places, keep the most functions error neutral, and you stop the "stack unwinding" only in very few places. In this approach, only very few places in program code would have to put these try-catch statements with lambdas, and the clumsiness of the syntax would encourage the users to adapt the methodology "stop unwinding in very few places". My only criticism of the library is that it makes a serious design choice to use a thread-local storage and fails to communicate it clearly to potential users in the documentation. It is ok for the library to make the choice to use TLS, but it is not ok to omit it from the "design choices" in documentation. I wouldn't bring it up if the documentation was poor; but because it is so high-standard, it strikes me that this information is missing. The reservations about TLS have nothing to do with performance. First, some platforms do not provide it. But as Bjorn Reese indicated, the same functionality could be implemented with a global lock-free map with thread IDs as keys, and no TLS would be required. Second, and I think more serious, is that thread-local solutions (including the global hash map with thread IDs) play very badly with coroutines: in a coroutine world a function can start executing in one thread, and finish executing in a different one. All those TLS-based solutions compile and may pass tests but are likely to fail with random results or crashes later. Many good programmers do not realize this. Emil informs me that this problem could be worked around by manually propagating some error information at the point where coroutines are managed. And I trust him on that. But in order for the programmer to do this manual part correctly, she has to know that this problem exists, and that she has to do it. This has to be stated prominently in the documentation along with the example how to do it. This criticism is only about the documentation. Not the design or implementation. I would not use LEAF for production applications I work with. The reason is that I am satisfied c++ exceptions and I find their cost tolerable in most of the places. In the remaining parts, usually low-level, where the performance or explicit control flows are important, I do not care about the detailed information about the failure, other than an integer code. But this is just my use case. My familiarity with the domain: I report failures in my code :). I study the topic of reporting failures effectively a lot. I follow the progress of ISO C++ Committee on the subject. I have co-authored the documentation of Boost.Outcome. As I said, I didn't review the implementation, so the Review Manager will consider it in weighing my opinion, but my recommendation is to **ACCEPT** LEAF into Boost. Thank you, Emil, for writing and sharing this library. Regards, &rzej;

3 3

[review][LEAF] Review period is over
by Michael Caisse 04 Jun '20

04 Jun '20

I apologize for not sending this out earlier. The review period is officially complete. A few people have contacted me about completing reviews that they in the middle of and I will be waiting until after this coming weekend to publish the review results. Thank you to those that joined the conversation and provided a review. michael -- Michael Caisse Ciere Consulting ciere.com

1 0

[review][LEAF] Additional reviews in progress?
by Michael Caisse 03 Jun '20

03 Jun '20

Anybody in the process of producing a review to submit? Please respond here or contact me directly. -- Michael Caisse Ciere Consulting ciere.com

3 3

[review] [text] Text review begins June 11
by Glen Fernandes 03 Jun '20

03 Jun '20

The Boost formal review of Zach Laine's Unicode library, Text, commences on June 11th and concludes June 20th. We welcome the participation of Boost developers and users, and the C++ community. Quote: This library includes three layers: - The string layer, a set of types that constitute "a better std::string" - The Unicode layer, consisting of the Unicode algorithms and data - The text layer, a set of types like the string layer types, but providing transparent Unicode support Code: https://github.com/tzlaine/text Docs: https://tzlaine.github.io/text Text requires C++14 or higher, and supports GCC 5+, Clang 3.6+, and MSVC 2017. Zach initially presented the library at C++Now in 2018. He also intends to standardize a library solution for Unicode based on this work. Talk: https://www.youtube.com/watch?v=944GjKxwMBo Slides: https://tinyurl.com/boost-text-slides Try the library today, and please consider submitting a review, or even contributing to the discussion next week. Glen

1 0

Re: [boost] [review][LEAF] Review of LEAF starts today : May 22 - May 31
by Bjorn Reese 02 Jun '20

02 Jun '20

On 2020-05-22 11:31, Michael Caisse via Boost wrote: > Please provide in your review information you think is valuable to > understand your choice to ACCEPT or REJECT including LEAF as a > Boost library. Please be explicit about your decision (ACCEPT or REJECT). I vote to conditionally accept LEAF into Boost. LEAF provides a new perspective on error propagation that is worth exploring in the real world. The conditions for acceptance are: 1. Provide a lower-level API for error handling which does not necessitate a pattern matching framework. I would prefer an API closer to the variant::index() and std::get<I>() combination that enables you to write the error handling as switch statements. More rationale for this request is given under the design evaluation. > - What is your evaluation of the design? LEAF propagates error objects across multiple function calls by letting the callee store the error payload directly in a stack object, called the error context, at the caller. A pointer to the error context is located in thread-local storage. When there are more error contexts on the call stack, they are daisy chained via pointers in the child error context. This is a sound design, which gives LEAF an efficient way of propagating error payloads then a failure occurs. I like that the returned error_id can be passed through C code. There is runtime overhead in creating and destroying the error contexts even when no failure occurs. Whether or not that overhead is acceptable depends on circumstances. It seems to me that the noexcept performance overhead in the successful case and the failure case are not that different (assuming the error payload is not too heavy), so it may be a good idea to choose LEAF when worst-case performance is more important than average-case performance. The more I experimented with LEAF, the more I wished that there was an error handing API with less syntatic sugar. 1. Single-stepping into a TryBlock is really cumbersome. The developer has to single-step through layers of unfamiliar templated code before reaching their own TryBlock. This interrrupts their flow. Setting a breakpoint in the TryBlock helps but is still cumbersome. 2. Some compilation errors are difficult to interpret. For example, if you accidentally omit a required return statement in one of the try_handle_all handlers, then the compiler reports the start of the try_handle_all statement and some internal LEAF voodoo. If you are experienced with reading templates errors, then you may be able to discover the erroneous handler from the LEAF template parameters in the compiler output. The LEAF handling is reminiscient of a variant visitor, but with the variants we can use index() and std::get<T> in a switch statement instead of visitation. I would like to see something similar for LEAF error contexts. I am undecided about the reliance on thread-local storage. Initially I thought that we could just replace thread-local storage with a home- made lookup table using atomics (which are generally available on OS-less platforms, whereas mutexes etc are not,) but Niall's mention of consteval made me unsure (damn you Niall ;-) However, I do not see this as a show-stopper. The try_handle_all() and try_handle_some() functions have different return values. While I understand the rationale given in the reference documentation, it may still be confusing to users if they change from one to the other. This could possibly be solved by making it more clear in the documentation. The remote_handle_all() name is confusing. I would rename it to nested_handle_all(). > - What is your evaluation of the implementation? The implementation is of high quality, and reasonably readable if you are comfortable with templates. I did not do a proper code review, so the following are random notes. Some classes (leaf::result and the internal optional) uses placement-new and explicit destructor calls. I suggest that you create your own construct_at() and destruct_at() which uses the std counterparts when available, and placement-new / explicit destruction otherwise. This will make the code more readable. std::ostream is entangled into various classes for printing. I would prefer if printing was moved into seperate X_io.hpp files to speed up compilation times when not using them. The LEAF_CONSTEXPR should be renamed to LEAF_CXX14_CONSTEXPR to align with the BOOST_CXX14_CONSTEXPR naming. Also the #if should use '>=' instead of '>'. config.h includes <Windows.h>. This should be replaced with Boost.WinAPI. > - What is your evaluation of the documentation? Overall the documentation is well-presented. The examples reconfigures std::cout to throw exceptions. That obscures the examples because now the reader has to learn LEAF and how std::cout exceptions work at the same time. It would be better to move the std::cout exception stuff into a separate example which is only about std::cout. > - What is your evaluation of the potential usefulness of the library? LEAF presents a unique error handling solution, that may be useful to certain users. I do not expect a huge user base though, as LEAF users mainly are going to be projects with requirements not met by the alternatives. > - Did you try to use the library? With which compiler(s)? Did you > have any problems? I experimented with small examples and found no compiler-related issues. > - How much effort did you put into your evaluation? A glance? A quick > reading? In-depth study? About 6 hours. Spent most time trying understanding the design than reviewing the code and documentation. > - Are you knowledgeable about the problem domain? Yes.

6 10

Relevance of platfrom-specific shared_ptr implementations
by Peter Dimov 01 Jun '20

01 Jun '20

Greetings, shared_ptr has a number of platform-specific implementations for its control block, specifically the atomic reference count manipulation: https://github.com/boostorg/smart_ptr/blob/develop/include/boost/smart_ptr/… Those have been accumulated over the years and I'd like to clean them up, remove the unused ones and fold as many of them as possible into a few generic implementations using either std::atomic, GCC atomic intrinsics (https://gcc.gnu.org/onlinedocs/gcc-10.1.0/gcc/_005f_005fatomic-Builtins.html) or GCC/intel sync intrinsics (https://gcc.gnu.org/onlinedocs/gcc-10.1.0/gcc/_005f_005fsync-Builtins.html) But I have no experience with non-x86 platforms and don't know where boost::shared_ptr is still used and which of the platform-specific implementations are still needed. (Neither do I know on which platforms the atomic and the sync intrinsics actually work, as opposed to just compile and then fail to link.) Any information along these lines is welcome. If you know of a platform where boost::shared_ptr is still used, but which supports none of the "modern" ways to implement atomic ops, please let me know. If you would like some of the plaform-specific files to be retained, please let me know. Thanks in advance.

3 2

[boost-ml] recommended way-of-working on the ml leaks locations data.
by degski 01 Jun '20

01 Jun '20

As email clients report local time, the way we (are supposed to) post results in leaking of one's location (if one would analyze, which is easily possible with the archive), first of relative location, but once you triangulate a few (and make a few assumptions, like Niall Douglas is probably in Ireland), you can work them all out. Maybe I'm the person who finds this unpleasant, but I don't find this ideal. degski -- @systemdeg https://www.instapaper.com <http://instapaper.com> "We value your privacy, click here!" Sod off! - degski

1 0

Re: [boost] [Boost-users] [review][LEAF] Review of LEAF
by Niall Douglas 01 Jun '20

01 Jun '20

On 01/06/2020 12:51, degski via Boost-users wrote: > Is there scope for merging LEAF and Outcome as it seems from (very > detailed discussions) that they only partially overlap? My own opinion: 1. You may remember that Emil was one of two people who voted to reject Outcome back during its review, as he felt that it was the wrong design. His comments on what would be better back then map well onto what he has presented in LEAF. I find that very reasonable: (i) he thought he could do better (ii) he went ahead and did better in his opinion (iii) he is presenting now what he thinks is better, and is asking Boost for its opinion on whether he improved things or not. 2. There is long established precedence for Boost containing multiple libraries that approach a problem from multiple perspectives e.g. we currently have three error handling libraries, four maths libraries etc. If LEAF were accepted, you'd now have four instead of three error handling libraries. And that seems to me just fine, and not out of precedence. 3. I specifically and deliberately chose to not design Outcome like LEAF. I thought then, and I still do, that Outcome ought to be great at all the things no other solution is great at. I think I succeeded on that. As I already stated in my own review of LEAF, I personally think that there is already a perfectly good implementation of LEAF shipping in any C++ compiler of the past twenty years. I don't, personally speaking, see the value add for choosing LEAF over C++ exceptions except to tick some box called "C++ exceptions globally disabled compatible". > I don't think > that 'we' should keep on adding distinct libraries that partially > overlap, Existing libraries should be expanded instead, and > deduplication should be done in a coordinated way (in this case between > LEAF and Outcome). Something has to be done to stop exponential growth > of Boost while maintaining flexibility to add code at will. The best way to stop exponential growth of Boost, if that is desirable, is to start culling libraries that aren't maintained nor useful. Or at least publish a documented list of libraries that new code ought to not use. > As C++ already has exceptions (and will have exceptions light in the > future), the use-case you presented to use LEAF surgically with C-api's > seems convincing (it presents a better case than the case of generically > re-working an exception system that works, is fundamental to C++ and is > promised to be improved in the future, i.e. it's the safest bet. Any > library is secured till maintenance ceases, the language/STL > (exceptions, exceptions light) is a pdf-file (i.e. future proof by default). The current formulation of lightweight exceptions before WG21 is literally Experimental Outcome in language form. Same proposed error object, std::error. It is currently expected that both value-based and type-based exceptions would exist in future C++, in order to retain backwards compatibility, as the semantics between the two are not currently believed possible to be made exactly one-one. Experimental Outcome works fine in C code, same as how the most recent proposal for lightweight exceptions also supports C. Niall

2 3

Re: [boost] Relevance of platfrom-specific shared_ptr implementations
by Bjorn Reese 31 May '20

31 May '20

On 2020-05-31 17:18, Peter Dimov via Boost wrote: > Those have been accumulated over the years and I'd like to clean them > up, remove the unused ones and fold as many of them as possible into a > few generic implementations using either std::atomic, GCC atomic > intrinsics > (https://gcc.gnu.org/onlinedocs/gcc-10.1.0/gcc/_005f_005fatomic-Builtins.html) > or GCC/intel sync intrinsics > (https://gcc.gnu.org/onlinedocs/gcc-10.1.0/gcc/_005f_005fsync-Builtins.html) How about a fall-back to Boost.Atomic?

1 0

Re: [boost] boost reviewLEAF Review of LEAF starts today : May 22 - May 31
by Jess 29 May '20

29 May '20

Hey, big boy! My boyfriend is visiting his parents for a week and I want to get laid. You actually live just nearby. Do you want to see some of my cheeky pictures? It is in my profile On this site | | | | Online Hookup | | | Kisses, Jess

3 2

[review][LEAF] Review period ending soon - May 31
by Michael Caisse 28 May '20

28 May '20

I'd like to encourage each of you to review Emil's error handling library. We often focus on design or implementation based reviews, and I encourage those but what I would really like to see are more user based reviews. Grab the library and docs and play with it a bit. What works well? What can be improved? As a reminder, some of LEAF's features include: * arbitrary error types * header-only * no dependencies * use without exceptions * use with exceptions * no dynamic memory alloc You can find the documentation here: <https://zajo.github.io/leaf/> and the library source here: <https://github.com/zajo/leaf/tree/review> Thanks! michael -- Michael Caisse Ciere Consulting ciere.com

1 0

[epochs] Proposal for an epoch-based organization of Boost libraries
by Joaquin M López Muñoz 28 May '20

28 May '20

Hi, Prompted by general feelings about Boost perceived lack of modernization and internal "bloat", and after an explicit survey on what users dislike about Boost [1], I decided to try and write a more or less fleshed out proposal for an epoch-based organization of Boost libraries. I've extensively tested and refined the proposal during discussions on Reddit and the Boost Slack channel, and I feel this is now ready for presentation at the mailing list: https://github.com/joaquintides/boost_epoch/blob/master/README.md I hope the proposal can start a productive conversation. Looking forward to your feedback. Best, Joaquín M López Muñoz [1]: https://www.reddit.com/r/cpp/comments/gfowpq/why_you_dont_use_boost/

13 42

Optional library
by anshu khare 27 May '20

27 May '20

Hi mentors I was going through the optional library of boost. I was facing some problem in understanding the code base. In lines from 94 to 97 in optional.hpp, the code is as follows: struct in_place_init_if_t { Struct init_tag{}; explicit in_place_init_if_t(init_tag) {} //not able to understand this line }; I understand that we are creating a structure in_place_init_if_t and inside that we are creating another structure init_tag and then we are calling the constructor of in_place_init_if_t. But I am not able to understand that what does it the constructor do when we pass init_tag as an argument to it. Is it same as we are creating a structure Car and then creating another structure wheels inside it and passing wheels as an argument to the constructor of car as follows: struct car { Struct wheels{}; explicit car(wheels) {} //not able to understand this line }; Could you please tell what is the significance of passing wheels as an argument in this counter example?

2 1

[LEAF] Loss of error_id
by Bjorn Reese 26 May '20

26 May '20

In the noexcept case, what happens in the Error-Handling function if the error_id generated by the Error-Reporting function is lost by the intermediate functions?

2 4

Request for 1.73 patch release
by Richard Hodges 25 May '20

25 May '20

Dear all, Just prior to the release of boost 1.73, some changes appeared in Asio which use the new c++20 concepts (and concepts-ts) features where available. These changes have introduced breakage in Beast in compilers where concepts are enabled. Examples are gcc=10 and clang10 with -std=c++20. I have pushed a fix to beast/develop to address this, but sadly we only became aware of the problem after the release of boost 1.73.0 I suspect the cause here is a combination of my relatively new appointment as a Beast maintainer and the ground-breaking event which I am sure c++20 will prove to be. I welcome any guidance on preparing or initiating a patch release as I lack the Arcane Knowledge required. For information, here is a link to the commit which fixes the problem: https://github.com/boostorg/beast/pull/1927 And some bug reports that alerted us that somethig was wrong: https://github.com/boostorg/beast/issues/1916 https://github.com/boostorg/beast/issues/1925 -- Richard Hodges hodges.r(a)gmail.com office: +442032898513 home: +376841522 mobile: +376380212

6 13

Re: [boost] [LEAF] The usage of TLS
by Bjorn Reese 22 May '20

22 May '20

On 2020-05-04 01:15, Andrzej Krzemienski via Boost wrote: > There is a number of reasons people do not want to or cannot use the C++ > exception handling mechanism. One of them is that the implementation of > exception handling requires the usage of TLS, and TLS is not implementable > on some platforms, like GPUs. If Nvidia's compiler does not implement C++ > exception handling mechanism, it is not because it would be slow, but > because it would require TLS support. From this perspective, if I cannot > use C++ exceptions because of TLS and I have to use something else, then > another TLS-based library is not really an alternative. In this case it > does not matter that it is only IDs that are stored in TLS. The sole fact > of even employing TLS is a deal breaker. LEAF really only needs one thread-local pointer to the topmost context per thread, so it may be possible to replace the thread-local storage with a global lock-free hash table. A lock-free hash table only requires atomic support, which is generally available on GPUs and microcontrollers. The key of the hash table could be the thread id. Task-based RTOS systems could use its task handle instead. An example of a lock-free hash table: https://eourcs.github.io/LockFreeCuckooHash/

2 1

Re: [boost] [container] Proposal for ring queues
by Bjorn Reese 22 May '20

22 May '20

On 2020-05-22 00:17, Andrey Semashev via Boost wrote: > I would like to ask if there is interest in the community for these > kinds of containers. I know I would find them useful, and at least one > person commented in the PR to the same effect. However, I would still > like to see if more people need this. Do notice that we also have this proposal floating around: https://lists.boost.org/Archives/boost/2019/09/246925.php https://lists.boost.org/Archives/boost/2020/05/248871.php

2 1

Help sought with identifying failure cases on the boost.org test matrix
by Richard Hodges 22 May '20

22 May '20

Dear all, Looking here: https://www.boost.org/development/tests/master/developer/beast.html We're seeing a lot of yellow, but when I run tests locally I get 100% passes. I'm reaching out to anyone who might have information on how I can replicate the steps to failure, and then either fix the problem or help the test host correct the configuration, as appropriate. Many thanks for your time. -- Richard Hodges hodges.r(a)gmail.com office: +442032898513 home: +376841522 mobile: +376380212

2 1

[Bimap] Maintenance
by Matias Capeletto 21 May '20

21 May '20

Hello Some Boost.Bimap's maintenance PRs have remained unmerged. The library also hasn't been following additions to the STL that should be mapped in the provided containers and implementing proper support for move semantics, between other features. Since I haven't been involved in C++ for a while, I am not currently in a position to push for a new version and I would prefer to allow other people to become a maintainer. What is the process to enable other maintainers to push the library forward? Best Matias

4 4

Review Wizard Status Report for May 2020
by Mateusz Loskot 20 May '20

20 May '20

============================================== Review Wizard Status Report for May 2020 ============================================== News ==== List of events that happened since the last report in 2016 is long and includes 13 releases of Boost, 21 libraries accepted and 4 libraries rejected. Details at https://www.boost.org/community/review_schedule.html What happened in 2020: 1. 2020-01: Ronald Garcia retired as a Review Wizard. Thank you Ronald! 2. 2020-02: StaticString accepted 3. 2020-04: Boost 1.73 Released New Libraries: - Nowide from Artyom Beilis, maintained by Alexander Grund - StaticString from Vinnie Falco and Krystian Stasiowski 4. 2020-05: Bimap library needs a maintainer https://lists.boost.org/Archives/boost/2020/05/248940.php Review Schedule Status ====================== The following libraries need a review manager: * JSON - author: Vinnie Falco, Krystian Stasiowski, Peter Dimov The following libraries have review managers, but have not yet been scheduled for review: * none The following libraries have review managers and have been scheduled for review: * LEAF - May 22, 2020 - May 31, 2020; author: Emil Dotchevski; review manager: Michael Caisse * Text - June 11, 2020 - June 20, 2020; author: Zach Laine; review manager: Glen Fernandes The following libraries have been reviewed and await reports from their review managers: * none The following libraries have been accepted to Boost, but have not yet been integrated into Boost Git: * Double-Ended - conditionally accepted in October 2017; author: Benedek Thaler * Parallel Sorting Sub-library - accepted November 2016; author: Francisco José Tapia The following libraries have been accepted and submitted to Boost Git, but have not yet appeared in a release: * STLInterfaces - conditionally accepted December 2019; author: Zach Laine The following libraries have been accepted provisionally to Boost, but have not been submitted for mini-review and full acceptance: * STLInterfaces - conditionally accepted December 2019; author: Zach Laine General Announcements ===================== As always, we need experienced review managers. Please take a look at the list of libraries in need of managers and check out their descriptions. In general review managers are active boost participants, including library contributors, infrastructure contributors, and other mailing list participants with a substantial track record of constructive participation. If you can serve as review manager for any of them, email us at Mateusz Loskot (mateusz at loskot dot net) or John Phillips (johnphillipsithaca at gmail dot com). We are also suffering from a lack of reviewers. While we all understand time pressures and the need to complete paying work, the strength of Boost is based on the detailed and informed reviews submitted by you. If you are interested in reviewing a library but won't have time during the review period, you can always prepare your review ahead of time. No rule says you can only work on a review during the review period. A link to this report will be posted to www.boost.org. If you would like us to make any modifications or additions to this report, please email Mateusz. The review schedule is an unordered list of the libraries awaiting review. As such, any library on the schedule can be reviewed once the developer is ready, a review manager has been secured, and the manager, developer, and wizards agree on a date to schedule the review. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

1 0

[interprocess] Mutex and condition at process termination
by Phil Endecott 20 May '20

20 May '20

Dear Experts, Can we improve how interprocess mutexes and condition variables behave on process termination? Currently if a process terminates (i.e. it crashes, or you press ctrl-C), the interprocess docs say nothing as far as I can see about what happens to locked mutexes and awaited conditions. In practice it seems that mutexes that were locked remain locked, and other processes will deadlock. (I'm using Linux.) A few thoughts: * If a process were only reading the shared state, then it would be appropriate for the mutex to be unlocked on termination. * If a process were modifying the shared state, then it would be wrong to unconditionally unlock the mutex. So it would be useful to distinguish between reader and writer locks, even if we're not implementing a single-writer/multiple-reader mutex. * The system could be made more robust by blocking signals while a mutex is locked. This doesn't help with crashes, e.g. segfaults, but it would help with ctrl-C. * It may be useful to cause all processes to terminate if one of them terminates with a mutex held for writing, either immediately or as soon as they try to lock the same mutex. Perhaps also to delete the presumed-corrupted shared memory segment. * PTHREAD_MUTEX_ROBUST might be part of the solution. That seems to require the non-crashed process to do clean up, i.e. we would need to record whether the crashed process were reading or writing and react appropriately. I'm less clear about what happens to condition variables, but it does seem that perhaps terminating a process while it is waiting on a condition will cause other processes to deadlock. Perhaps the wait conceptually returns and the mutex is re-locked during termination. I have encountered this while trying to use a simple diagnostic program that just dumps some shared memory data structures and waits on a condition in a loop. I run this for a while and then press ctrl-C. Yes, a while after I disconnect the diagnostic program the system crashes... the worst sort of bug! Regards, Phil.

6 17

Embarcadero PRs
by Edward Diener 20 May '20

20 May '20

I have PRs for these libraries, which have passed CI testing, for distinguishing the Embarcadero C++ clang-based compilers from the legacy bcc32 compiler: beast thread regex container python program_options units circular_buffer graph parameter unordered random typeof Can the maintainers of these libraries please merge the appropriate PR ? The PR should not affect any other compiler, and it gives a chance for the Embarcadero C++ clang-based compiler(s) to use the appropriate Boost library even when some lacking feature or Embarcadero bug currently prevents the full functionality of the library to be used.

1 0

Re: [boost] [B2] Propagate CXX requirements to consumers
by Nikita Kniazev 19 May '20

19 May '20

> I guess this could be solved if B2 allows negation. So I can say: > `<target-os>not windows:<build>no `. > Does this exist? It is supported, but was broken until recently https://github.com/boostorg/build/pull/594

1 0

BOOST_NO_CXX11_HDR_CHRONO?
by Frédéric 19 May '20

19 May '20

Hi, When I compile the following program: #include <boost/math/constants/constants.hpp> #include <chrono> int main() { return 0; } with a osx cross compiler based on clang 9 on linux,I get the following warnings (full output below): CAUTION: This message was generated due to the define: BOOST_NO_CXX11_HDR_CHRONO [-W#pragma-messages] This is quite strange as the compiler generates the binary which means there was no issue to find <chrono>. What's wrong then? Kind regards, F $ x86_64-apple-darwin13-clang++-libc++ -o boost_math_constants -Wall -Wextra -std=c++14 -m64 -mmacosx-version-min=10.9 -I/softs/osx64-clang-9.0.1/release/boost/include boost_math_constants.cpp In file included from Progs/boost_math_constants.cpp:1: In file included from /softs/osx64-clang-9.0.1/release/boost/include/boost/math/constants/constants.hpp:11: /softs/osx64-clang-9.0.1/release/boost/include/boost/math/tools/cxx03_warn.hpp:99:1: warning: CAUTION: One or more C++11 features were found to be unavailable [-W#pragma-messages] BOOST_PRAGMA_MESSAGE("CAUTION: One or more C++11 features were found to be unavailable") ^ /softs/osx64-clang-9.0.1/release/boost/include/boost/config/pragma_message.hpp:24:34: note: expanded from macro 'BOOST_PRAGMA_MESSAGE' # define BOOST_PRAGMA_MESSAGE(x) _Pragma(BOOST_STRINGIZE(message(x))) ^ <scratch space>:307:2: note: expanded from here message("CAUTION: One or more C++11 features were found to be unavailable") ^ In file included from Progs/boost_math_constants.cpp:1: In file included from /softs/osx64-clang-9.0.1/release/boost/include/boost/math/constants/constants.hpp:11: /softs/osx64-clang-9.0.1/release/boost/include/boost/math/tools/cxx03_warn.hpp:100:1: warning: CAUTION: Compiling Boost.Math in pre-C++11 conformance modes is now deprecated and will be removed from March 2021. [-W#pragma-messages] BOOST_PRAGMA_MESSAGE("CAUTION: Compiling Boost.Math in pre-C++11 conformance modes is now deprecated and will be removed from March 2021.") ^ /softs/osx64-clang-9.0.1/release/boost/include/boost/config/pragma_message.hpp:24:34: note: expanded from macro 'BOOST_PRAGMA_MESSAGE' # define BOOST_PRAGMA_MESSAGE(x) _Pragma(BOOST_STRINGIZE(message(x))) ^ <scratch space>:310:2: note: expanded from here message("CAUTION: Compiling Boost.Math in pre-C++11 conformance modes is now deprecated and will be removed from March 2021.") ^ In file included from Progs/boost_math_constants.cpp:1: In file included from /softs/osx64-clang-9.0.1/release/boost/include/boost/math/constants/constants.hpp:11: /softs/osx64-clang-9.0.1/release/boost/include/boost/math/tools/cxx03_warn.hpp:101:1: warning: CAUTION: Define BOOST_MATH_DISABLE_DEPRECATED_03_WARNING to suppress this message. [-W#pragma-messages] BOOST_PRAGMA_MESSAGE("CAUTION: Define BOOST_MATH_DISABLE_DEPRECATED_03_WARNING to suppress this message.") ^ /softs/osx64-clang-9.0.1/release/boost/include/boost/config/pragma_message.hpp:24:34: note: expanded from macro 'BOOST_PRAGMA_MESSAGE' # define BOOST_PRAGMA_MESSAGE(x) _Pragma(BOOST_STRINGIZE(message(x))) ^ <scratch space>:313:2: note: expanded from here message("CAUTION: Define BOOST_MATH_DISABLE_DEPRECATED_03_WARNING to suppress this message.") ^ In file included from Progs/boost_math_constants.cpp:1: In file included from /softs/osx64-clang-9.0.1/release/boost/include/boost/math/constants/constants.hpp:11: /softs/osx64-clang-9.0.1/release/boost/include/boost/math/tools/cxx03_warn.hpp:102:1: warning: CAUTION: This message was generated due to the define: BOOST_NO_CXX11_HDR_CHRONO [-W#pragma-messages] BOOST_PRAGMA_MESSAGE("CAUTION: This message was generated due to the define: " BOOST_MATH_CXX03_WARN_REASON) ^ /softs/osx64-clang-9.0.1/release/boost/include/boost/config/pragma_message.hpp:24:34: note: expanded from macro 'BOOST_PRAGMA_MESSAGE' # define BOOST_PRAGMA_MESSAGE(x) _Pragma(BOOST_STRINGIZE(message(x))) ^ <scratch space>:316:2: note: expanded from here message("CAUTION: This message was generated due to the define: " "BOOST_NO_CXX11_HDR_CHRONO") ^ 4 warnings generated.

5 15

[Config] Swappable/Movable std::streambuf requirement
by Alexander Grund 18 May '20

18 May '20

Hello, C++11 has `std::basic_streambuf<char>::swap` and move operators for that defined. However there are stdlibs which don't support that. clang 5.0 on travis e.g. fails due to that. Is there already something in Boost.Config dealing with that case which I can `requires` on to skip the build for that case? Most of the checks I've seen in Boost.Config are using the C++ feature test macros but for this there is none. If it doesn't exist: Would this be something to be added to Boost.Config? Or my local build files? How would such a test work? Can anyone point me to a similar example? I'm having trouble navigating over the many partially auto-generated files in Boost.Config. Thanks, Alex

2 2

Continued Fraction library/extension for Boost
by Fahad Syed 14 May '20

14 May '20

Hello, I am an Electrical Engineering fresher at National Institute of Technology, Srinagar. I have a proposal for a Continued Fraction class, with all arithmetic implemented through Gosper's HAKMEM algorithm. Here are some advantages/applications I can think of right now for a continued fraction representation: 1. Exact, base-independant representation of rationals AND irrationals (of course limited by the precision required) 2. Unlike rationals where numerator and denominator need to be "canonicalized" (i.e. divided by gcd for optimal representation), continued fraction arithmetic incorporates that naturally. 3. Approximation: Continued fraction give the best possible rational approximation for a given number 4. Comparison is extremely easy and fast 5. Conversion to float and base-conversion do not require division. Conversion to float, especially, is extremely fast and simple. I propose to implement most of the functions supported by the multi-precision library. Although I am sure there are many more applications and advantages, I would like some feedback on whether this library/extension would be of enough interest to be included in boost. Thank you.

1 0

[Filesystem] Directory entry caching
by Chris Glover 13 May '20

13 May '20

Hi All, Whatever happened to the work in this branch https://github.com/boostorg/filesystem/tree/feature/directory-entry-cache-r… that looks to implement this paper? http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0317r1.html Wondering if it's planned, dead, or looking for someone to do the work. I ran into the problem today by chance. -- chris

4 10

[Range] Transform in place
by Frederick Gotham 11 May '20

11 May '20

Earlier today I wrote the following two lines of code: auto const my_range = v | boost::adaptors::sliced(1,15) | boost::adaptors::strided(2); boost::range::transform( my_range, my_range.begin(), std::bit_not<uint8_t>() ); However it would have been nice as a one-liner: boost::range::transform( v | boost::adaptors::sliced(1,15) | boost::adaptors::strided(2), std::bit_not<uint8_t>() ); Why isn't there a form of "range::transform" that can transform in place (and therefore takes exactly two arguments)?

3 2

Boost.Asio's service_registry::do_use_service may block forever if a service with the same key was created
by Niklas Gürtler 11 May '20

11 May '20

Hello boost developers, I found a bug in Boost.Asio on Windows using IOCP that can make the service_registry::do_use_service block forever if a service with the same key was created and registered while the mutex was unlocked. If the service uses win_iocp_io_context, its destructor (implicitly called upon return, by destroying new_service) will join() the internal thread for IOCP handling, without requesting it to stop before. This will leave both threads to block forever, while the mutex_ is still locked (lock's destructor may be called after new_services), which may cause further blockages in other threads. I submitted a PR ( https://github.com/boostorg/asio/pull/350 ) which aims to fix this by calling shutdown() on the thread before returning, and unlocking the mutex explicitly before that. Another solution would be to call shutdown() from within win_iocp_io_context::~win_iocp_io_context(). Regards, Niklas Gürtler

1 0

Boost and unsigned chars
by REIX, Tony 11 May '20

11 May '20

Hi, I have tried to build Boost, and mainly Boost.math, with -funsigned-char, and I’ve faced several issues. Is Boost designed to work with unsigned chars (default on AIX) in addition to signed chars (default on Fedora)? Thanks Tony

1 0

Google Summer of Code 2020 selected projects
by David Bellot 09 May '20

09 May '20

Dear Boost community, I would like to welcome our Google Summer of Code. 2020 students. This year, 10 students will work very very hard on improving and adding new features to many of our libraries. Once again, the competition has been very hard. A few numbers: - we received 93 proposals in total. 85 of them were complete, then we kept 47 proposals only - finally we selected 10 of them, covering 7 different Boost libraries - and countless hours of work from the most incredible team of mentors! Here are the list of projects for 2020: *Boost.Real* Kishan Shukla will be working on making the Real library ready for revision. His main goal is to reimplement the division algorithm so it can be used with any number base representation and the Karatsuba multiplication algorithm. Also, it will be working on implementing some operators and common irratianal numbers as Pi. Mentors: Laouen Belloli and Damian Vicino. *Boost.Astronomy* Syed Ali Hasan will be working on the astronomical coordinate system, he will implement different coordinate conversion using SOFA library Mentor: Pranam Lashkari Gopi Krishna Menon will be completing the parser for FITS file and also optimise the already developed components. Mentor: Sarthak Singhal *Boost.GIL* Debabrata Mandal will be implementing histogram computation as a built-in feature, algorithms for histogram analysis, image processing algorithms based on histogram and possibly integration with Boost.Histogram library. *Mentor*: Mateusz Loskot, Pranam Lashkari Olzhas Zhumabek will be extending GIL's portfolio of image processing algorithms, implementing for image scaling and sampling, Perona–Malik diffusion, Non-Maximum Suppression for object detection, Hysteresis threshold and some more. *Mentor*: Mateusz Loskot *Boost.Multiprecision* Dimitris Los will work on extending and optimizing parts of Boost.Multiprecision to higher precision of many thousands of bits or more. *Mentor*: Christopher Kormanyos *Boost.uBlas* Ashar Khan will stabilize and improve Boost.uBlas using the C++20-Standard. The main focus of his project will be enhancing code-coverage and documentation, integrating static code analysis and generating tensor concepts. *Mentor*: Cem Bassoy Tom Kwok will improve and finalize the implementation of data frames in uBlas, with the aim of delivering production-ready by the end of the summer. Data frame in uBlas are similar in functionalities to other implementations like in R, Python.Pandas or Julia. *Mentor*: David Bellot *Boost.Geometry* Tinko Bartels will work on robust yet efficient geometric predicates for Boost Geometry. *Mentor*: Vissarion Fisikopoulos *Boost.Real* Vikram Singh Chundawat will work in taking Real to revision ready state. His focus will be in improving the internal representation datatypes and providing functions required to conveniently support Taylor series. *Mentors*: Damian Vicino and Laouen Belloli Best regards, David Bellot

1 0

[github] Retriggering CI tests
by Edward Diener 08 May '20

08 May '20

How does one retrigger CI testing for a PR on Github without having to artificially update the PR ? I tried to find the answer to this in Github Help with no success. Maybe you have to retrigger tests within the testing environment somehow but I could not see how in either Appveyor or Travis CI.

4 5

[LEAF] The usage of TLS
by Andrzej Krzemienski 05 May '20

05 May '20

Hi Everyone, I have a remark regarding the LEAF library. But first, I would like to thank Emil for writing and sharing this library. Handling failures is an important aspect of writing programs that does not have an ultimate answer in C++, and is still a subject of exploration. LEAF seems to confirm this. I would also like to thank Michael for managing this upcoming review and for making the announcement ahead of time. A ten-day review period is usually too short (even if later extended), and the early announcement gives the opportunity to devote more time into reviewing a library and interact with the author. The following is not a review, but I wanted to highlight only one aspect of the library. Namely, the usage of thread-local storage. There is a number of reasons people do not want to or cannot use the C++ exception handling mechanism. One of them is that the implementation of exception handling requires the usage of TLS, and TLS is not implementable on some platforms, like GPUs. If Nvidia's compiler does not implement C++ exception handling mechanism, it is not because it would be slow, but because it would require TLS support. From this perspective, if I cannot use C++ exceptions because of TLS and I have to use something else, then another TLS-based library is not really an alternative. In this case it does not matter that it is only IDs that are stored in TLS. The sole fact of even employing TLS is a deal breaker. Of course, LEAF does not have to satisfy all the people that cannot use C++ exceptions. It can service the environments where TLS is affordable. But the usage or non-usage of TLS is an important factor in making a decision what tool/framework/library to use for handling failures, and because of this it deserves to be mentioned in the beginning of the documentation, so that potential clients can quickly make a decision if this library is for them. If your concern is that people would be incorrectly led to think that the entire error objects are stored in TLS, you can also say explicitly up front that it is only about int-size IDs. Otherwise, people will be mislead anyway. A person will ask, "how is it possible that this library does not return the entire error object in leaf::result<> and it does not take the pointer to the allocated object as function argument? Is it using TLS? Let's grep for `thread_local`. Positive: it must be using TLS for storing error objects." For a similar reason, I find the comparison with Boost.Outcome, at the end of documentation, unfair. If the goal of this comparison is to help people decide which library is best suited for them, LEAF or Outcome, the usage or non-usage of TLS is an important factor. Another thing is that I cannot see how a TLS-based implementation can work with C++20 coroutines. In C++ 20 the following piece of code { A(); co_await X(); B(); } means that when the call to B() will be potentially "packaged" as a task and scheduled to be executed possibly on a different thread. It means that B() will be executed on a different thread than A(), which means that any attempt to communicate between A() and B() using TLS will not be reliable (e.g. if A() is in fact a call to leaf::preload()). This is the reason why we still cannot implement the feature known as "on scope failure" (like destructor call, but only when we are leaving the scope due to exception) in C++ even though we have `std::uncaught_exceptions()` (which uses TLS under the hood). This is why a proposal like P0052 ( http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p0052r10.pdf) didn't make it to C++20. Now, LEAF may have a solution to this problem, but I cannot figure it out from the documentation. So, I do not know if it is safe to use LEAF with coroutines in multi-threaded environment. I would really want this to be clarified in the docs before the library review starts. Regards, &rzej;

5 7

Re: [boost] [release] Boost 1.73.0 Release Candidate 1
by Tim Haines 04 May '20

04 May '20

The patch has an extra directory indirection that prevented installation for me. Changing a/boost_1_73_0/boost/outcome to a/boost/outcome worked for me. Thanks. - Tim P.S. Apologies if this interjection breaks the correct flow of the mailing list. I get mine in a digest and couldn't figure out how to reply to just this message. On 28/04/2020 01:08, Glen Fernandes wrote > Niall, if you want we can provide a Boost.Outcome patch on the 1.73 > release notes (in similar fashion to the Coroutine patch on > https://www.boost.org/users/history/version_1_72_0.html under Known > Issues) and on https://www.boost.org/patches/ . Please find attached a diff against Boost 1.73 which was generated from bug fix commit https://github.com/ned14/status-code/commit/9f414ea58264fe0a62172a06f4653ad… Thanks for this, sorry for the bother. Niall

2 1

Circular span still alive
by Bjorn Reese 03 May '20

03 May '20

Last Autumn I asked if people were interested in a circular span and got a positive response. Since then I have been quite about it, mainly due to the usual daily work load. However, I have continued development, and now the project has been renamed and extended with other kinds of spans: circular queue, priority queue, and associative array. https://github.com/breese/vista The common theme for these spans are that they operate on contiguous memory that they do not own. The spans have been developed to be usable for embedded projects that cannot use dynamic memory allocation or exceptions, and where minimal code size is essential. There are also algorithms for in-place incremental insertion and removal in sorted sequences, similar to std::push_heap() and std::pop_heap(). There is also a C++11 std::span in hiding there. The documentation is still incomplete: https://github.com/breese/vista/blob/develop/doc/vista.adoc

1 0

Embarcadero C++ and Boost libraries
by Edward Diener 01 May '20

01 May '20

Embarcardero ( formerly Codegear, formerly Borland ) has had for about five years C++ compilers based on clang, along with the venerable bcc32, which is the Borland compiler of old through a number of transformations. The clang-based Windows compilers are bcc32c/bcc32x for 32-bit development and bcc64 for 64-bit development. The only difference between bcc32c and bcc32x is that the former takes the same command line flags as their legacy bcc32 compiler while the latter, like bcc64, takes clang command line flags. The clang-based C++ compilers are based on clang-5.0, and use the Dinkumware library. The clang based compilers still predefine __BORLANDC__ and __CODEGEARC__ but also predefine __clang__. The latter is the way to distinguish in preprocessor code between the bcc32 compiler and the clang-based compilers. Despite numerous workarounds in Boost code based on the predefined macros __BORLANDC__ and __CODEGEARC__ the bcc32 compiler, not being very C++ compliant even at the C++98/C++03 level at which it operates, has not really worked for Boost since about Boost 1.39. It is useless for modern day Boost. Therefore I have made efforts, in contact with some Embarcadero C++ representatives, to integrate the clang-based compilers into Boost, especially since there is a free non-commercial offering by Embarcadero called C++ Builder Community Edition at https://www.embarcadero.com/products/cbuilder/starter which any Boost developer could use to test these compilers if they wished. I am doing this in the hopes that this may become effective for Boost 1.74.0. Doing this involves: 1) Creating an embarcadero.jam toolset, based on the clang-linux.jam toolset, which supports bcc32x and bcc64. Updating the borland.jam toolset to also support bcc32c. I have done these and the PR has been merged to 'develop' on Boost Build. 2) Updating Boost Config to support the clang-based compilers. I have done this and the PR has been merged to 'develop' on Boost Config. 3) In the update to Boost Config, I have created these macros: a) BOOST_BORLANDC = __BORLANDC__ with __clang__ not defined b) BOOST_CODEGEARC = __CODEGEARC__ with __clang__ not defined c) BOOST_EMBTC = Embarcadero C++ compilers with __clang__ defined Therefore what is really needed in Boost libraries is to change all the code which currently uses __BORLANDC__ to BOOST_BORLANDC and all the code which uses __CODEGEARC__ to BOOST_CODEGEARC when Boost config has been included. When in the rarer case that Boost config has not been included, then __BORLANDC__ logic becomes __BORLANDC__ and !__clang__ and __CODEGEARC__ logic becomes __CODEGEARC__ and !__clang__. I am workiog on doing this for the numerous Boost libraries with workarounds nased on __BORLANDC__ and __CODEGEARC__ in Boost code, and will create PRs for those libraries. I only ask that library maintainers will merge the PRs I create once they have passed their CI tests, since the PRs are almost all just simple transformations regarding the __BORLANDC__ and __CODEGEARC__ in the code. If any library maintainer wants to so this on their own in the 'develop' branch it would be appreciated. Further points: The Embarcadero C++ clang-based compilers are not as good as clang itself, which is at release 9, gcc, or vc++. But they are good enough for the majority of Boost code. The Embarcadero C++ clang-based compilers support only C++17. The documentation implies that they also support C++11 and C++14 but that is not so. But since Boost libraries written for a C++ standard level are supposed to work flawlessly at a higher level this is no impediment for C++ Builder programmers using the Embarcadero C++ compilers in current Boost. I have reported a number of bugs, based on my Boost testing, for the Embarcadero C++ compilers to Embarcadero themselves in their bug reporting system. I believe that any registered user of their free community edition can report bugs to Embarcadero C++ at their bug reporting system at https://quality.embarcadero.com. Hopefully these reports will improve the compilers. It would really be nice, once the Embarcadero C++ clang-based compilers are integrated into current Boost, if regression testers could test their compilers. I will try to do so myself if I have the time and resources. I have discussed this with some Embarcadero C++ representatives about adding the Embarcadero clang-based C++ compilers to one or more CI testing services, but currently there are not any which support them of which I know. Besides the clang-based Windows compiler Embarcadero also has clang-based C++ compilers for 32-bit and 64-bit iOS ( Apple ) and for Android ( Google ). The code in Boost Config distinguishes between these environments, if necessary, with further macros based off of the mnemonic BOOST_EMBTC. It would be nice to add these configurations to embarcadero.jam once the rest of the work is done. But I have no idea how to test any of these other compilers as they are not part of the Windows based Embarcardero C++ Builder Community Edition.

2 4

[review] [LEAF] LEAF Review Starts May 22
by Michael Caisse 01 May '20

01 May '20

The Boost formal review for LEAF (Lightweight Error Augmentation Framework) will take place May 22, 2020 through May 31st. LEAF is brought to us by Emil Dotchevski, the author of Boost.Exception. Similar to Boost.Exception, this library allows arbitrary error objects to be returned; however, unlike Boost.Exception it does not require dynamic memory. The library can be used with or without exception handling. Error handling is such an import part of every software system. LEAF provides a unique solution to the problem. The excellent documentation can be found here: <https://zajo.github.io/leaf/> and includes a tutorial, examples, reference, design rationale, and comparisons to other error handling approaches/libraries. The source is available at github. The review branch will be used during the review period. <https://github.com/zajo/leaf/tree/review> The purpose of this announcement is to give people some time to start looking at the documentation and source code for the library. Feel free to begin asking questions. Most of all, get involved! Everybody has some experience with handling errors. Tell the Boost community what you think of LEAF. Thank you for your participation! michael -- Michael Caisse Ciere Consulting ciere.com

3 2

Re: [boost] [review][STLInterfaces] STLInterfaces review results (ready for merge)
by Barrett Adair 30 Apr '20

30 Apr '20

On Thu, Dec 26, 2019 at 2:31 AM Barrett Adair <barrettellisadair(a)gmail.com> wrote: > > Many thanks are owed to all who participated in the formal review of Zach Laine's STLInterfaces library, especially during this busy holiday season: > > * Hadriel Kaplan - ACCEPT > * Andreas Wass - ACCEPT > * Rainer Deyke - ACCEPT > * Arthur Gruzauskas - ACCEPT > * Krystian Stasiowski - ACCEPT > * Daniela Engert - CONDITIONALLY ACCEPT > * Gavin Lambert - Technical comments > > (snip) > > The reviews clearly demonstrate a consensus. Accordingly, I'm pleased to announce that STLInterfaces is CONDITIONALLY ACCEPTED as a Boost library. > > Conditions for acceptance: > 1. Remove optional dependency on cmcstl2 (issue #27) > 2. Add Boost license comments to all files, including appveyor.yml, .travis.yml, README.md, */CMakeLists.txt (issue #26) > 3. Support Boost.Build (issue #25) > 4. Replace googletest with Boost equivalent (issue #24) > 5. Remove usage of non-existent v2_dtl members in container_interface.hpp (issue #22) > 6. Include <tuple> for std::tie usage in C++14 mode (issue #21) > 7. Fix dangling parens in container_inteface.hpp:731 (issue #20) > 8. Make Concepts usage C++20-conformant (issue #13) > 9. Remove the destructor in container_interface (issue #12) > 10. Add tests for non-copyable value types (issue #30) > > (snip) I've confirmed that STLInterfaces (https://github.com/tzlaine/stl_interfaces) has met the conditions for acceptance. Review wizards, please reply with any objections. Merge ticket here: https://github.com/boostorg/admin/issues/174 Thanks, Barrett

4 5

GSoC 2020 proposal review and GSoD
by Tom Kwok 29 Apr '20

29 Apr '20

Hi David (and other potential mentors), I updated my repository hosting my little project of C++ matrix classes for the GSoC competency test. Also, is there any editing needed for my proposal? I am sure you and other mentors are busy reviewing so I am sorry for bothering you with this message. If I don’t receive further feedback I would take it as no changes are needed (yet). Also, I read that Boost community is interested in participating GSoD (Google Season of Docs) as well. I would like to express my interest in GSoD participation and I look forward to hearing updates on specific requirements on GSoD participants and/or projects that Boost community may have. Best regards, Tom > On 23 Apr 2020, at 3:51 PM, boost-request(a)lists.boost.org <mailto:boost-request@lists.boost.org> wrote: > > Message: 8 > Date: Thu, 23 Apr 2020 08:25:22 +1000 > From: David Bellot <david.bellot(a)gmail.com <mailto:david.bellot@gmail.com>> > To: Boost <boost(a)lists.boost.org <mailto:boost@lists.boost.org>>, Boost users list > <boost-users(a)lists.boost.org <mailto:boost-users@lists.boost.org>> > Subject: [boost] 10 slots for the Google Summer of Code 2020 > Message-ID: > <CAOE6ZJGh_rM_Dg=h8SYktYoMqux2g+eAt7FiTaShJSs9UkeVMA(a)mail.gmail.com <mailto:CAOE6ZJGh_rM_Dg=h8SYktYoMqux2g+eAt7FiTaShJSs9UkeVMA@mail.gmail.com>> > Content-Type: text/plain; charset="UTF-8" > > Hi Boost community, > > this year Google allocated 10 slots for the Google Summer of Code. It's > again a great achievement thanks to the hard work of our team of dedicated > mentors. > > We are now selecting the best students among all the proposals we receive. > We received 79 proposals this year. 10 of them will be selected. > > This year, a lot of proposals if not all are targeting a finalization of > the work which has been done in the previous GSoCs and we should see a lot > of code being pushed in production. It's a very exciting time for all of us. > > The mentors are now hard at work to choose the students. We'll keep you > informed when it's official. > > Best regards, > David

2 1

[release] Boost 1.73.0 Release Candidate 1
by Marshall Clow 28 Apr '20

28 Apr '20

The first release candidates for the 1.73.0 release are now available at: <https://dl.bintray.com/boostorg/release/1.73.0/source/> The SHA256 checksums are as follows: d2e7501bb04fe7abc09aa93f013ae997604286a882da1bd36ddd96ea1163ea71 boost_1_73_0_rc1.7z 4eb3b8d442b426dc35346235c8733b5ae35ba431690e38c6a8263dce9fcbb402 boost_1_73_0_rc1.tar.bz2 9995e192e68528793755692917f9eb6422f3052a53c5e13ba278a228af6c7acf boost_1_73_0_rc1.tar.gz 0909a79524f857ef54570ceef8f397cc0629202532cc997785479c7c08bbc2a4 boost_1_73_0_rc1.zip As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. -- The Release managers

9 22

Emails from Travis CI not coming?
by Andrey Semashev 28 Apr '20

28 Apr '20

Hi, Does anyone else have a problem with build result notifications from Travis CI not coming? I haven't received emails from Travis for about a month, although I can see the completed builds in the web UI. I checked spam, they aren't there.

2 4

CI Testing and failures
by Edward Diener 28 Apr '20

28 Apr '20

Sometimes CI testing fails because of a bug in a compiler. It is possible to designate in a jam file that a particular test should not be done for a particular compiler version so that CI testing succeeds, and therefore a PR can be more easily merged because the CI tests "succeed". But then the fact that the compiler has a bug is masked by such a change to the jam file. Is there a solution to such a problem, or maybe this is really not a problem at all ? What do others think about this ?

2 3

[release] 1.74.0 open for merging
by Marshall Clow 28 Apr '20

28 Apr '20

The master branch is open for merging all stable changes from develop, including bug fixes and major upgrades to existing libraries. Breaking changes should be coordinated via the mailing list with the developers of the other libraries affected. New libraries may be added, but require permission of a release manager. In other words, merging does not require permission from a release manager, except for new libraries. Boost Calendar with the release schedule: http://www.boost.org/development/index.html Release schedule explanation: https://github.com/boostorg/wiki/wiki/Releases%3A-Schedule Release practices for developers: http://svn.boost.org/trac/boost/wiki/ImprovingPractices -- The Boost Release Team

1 0

[release] Boost 1.73.0
by Marshall Clow 28 Apr '20

28 Apr '20

Release 1.73.0 of the Boost C++ Libraries is now available. These open-source libraries work well with the C++ Standard Library, and are usable across a broad spectrum of applications. The Boost license encourages both commercial and non-commercial use. This release contains 2 new libraries and numerous enhancements and bug fixes for existing libraries. For details, including download links, see < http://www.boost.org/users/news/version_1.73.0> You can also download directly from: < https://dl.bintray.com/boostorg/release/1.73.0/> To install this release on your system, see < http://www.boost.org/doc/libs/release/more/getting_started/index.html> Thanks to everyone who participated in this release. Thanks, -- The Boost Release Team Marshall Clow, Micheal Caisse and Glen Fernandes

1 0

Controlling _BOOST_CMAKEDIR in installed .cmake files
by Jonathan Wakely 24 Apr '20

24 Apr '20

With Peter Dimov's help I've resolved my earlier problems packaging Boost for Fedora. Now my problem is that the generated .cmake files contain the full --prefix path, which is not what I want because that's just a staging area, not the final resting place for the files (think DESTDIR in an autotools build). I see lines like this in each of the installed .cmake files: /builddir/build/BUILDROOT/boost-1.73.0-0.1.fc33.x86_64/usr/lib64/openmpi/lib/cmake/boost_python-1.73.0/boost_python-config.cmake:if(EXISTS "/builddir/build/BUILDROOT/boost-1.73.0-0.1.fc33.x86_64/usr/lib64/openmpi/lib/cmake") /builddir/build/BUILDROOT/boost-1.73.0-0.1.fc33.x86_64/usr/lib64/openmpi/lib/cmake/boost_python-1.73.0/boost_python-config.cmake: get_filename_component(_BOOST_CMAKEDIR_ORIGINAL "/builddir/build/BUILDROOT/boost-1.73.0-0.1.fc33.x86_64/usr/lib64/openmpi/lib/cmake" REALPATH) /builddir/build/BUILDROOT/boost-1.73.0-0.1.fc33.x86_64/usr/lib64/openmpi/lib/cmake/boost_python-1.73.0/boost_python-config.cmake: set(_BOOST_CMAKEDIR "/builddir/build/BUILDROOT/boost-1.73.0-0.1.fc33.x86_64/usr/lib64/openmpi/lib/cmake") These files won't work after everything gets moved from the staging area $RPM_BUILD_ROOT/usr/... to the final lcoation on a user's machine, under /usr/... I can just use sed to alter them, but surely there's way to set the desired prefix? I'm trying: ./bootstrap.sh --with-toolset=gcc --with-icu --prefix=/usr ./b2 -d+2 -q -j 4 \ --without-mpi --without-graph_parallel --build-dir=serial \ --prefix=/usr --libdir=/usr/lib64 \ variant=release threading=multi debug-symbols=on pch=off \ python=3.8 \ stage ... ./b2 -d+2 -q -j 4 \ --without-mpi --without-graph_parallel --build-dir=serial \ --prefix=$RPM_BUILD_ROOT/usr \ --libdir=$RPM_BUILD_ROOT/usr/lib64 \ variant=release threading=multi debug-symbols=on pch=off \ python=%{python3_version} \ install And this produces the .cmake files with the unwanted $RPM_BUILD_ROOT/usr prefixes. I originally didn't have the --prefix and --libdir options on the bootstrap.sh command and the 'b2 .. . stage' command, but it doesn't seem to matter whether they're there or not. Is there some way to control the prefix that ends up in those .cmake files?

2 2

Google Season of Docs
by David Bellot 24 Apr '20

24 Apr '20

Hi, The registration for organization is now open. If anyone is interested in managing this project and wish to talk about now, please let me know. I've got some experience now managing the Google Summer of Code and can help with GSoD too. Cheers, David

13 46

[thread] Determinig the thread API
by Edward Diener 23 Apr '20

23 Apr '20

What determines whether the Boost thread library is built with pthreads or win32 thread support if the threadapi feature is not specified when building the library ?

2 2

[release] Master branch now closed for 1.73.0 release
by Marshall Clow 23 Apr '20

23 Apr '20

1 0

10 slots for the Google Summer of Code 2020
by David Bellot 22 Apr '20

22 Apr '20

Hi Boost community, this year Google allocated 10 slots for the Google Summer of Code. It's again a great achievement thanks to the hard work of our team of dedicated mentors. We are now selecting the best students among all the proposals we receive. We received 79 proposals this year. 10 of them will be selected. This year, a lot of proposals if not all are targeting a finalization of the work which has been done in the previous GSoCs and we should see a lot of code being pushed in production. It's a very exciting time for all of us. The mentors are now hard at work to choose the students. We'll keep you informed when it's official. Best regards, David

1 0

[release] 1.73.0 post-beta merges
by Marshall Clow 22 Apr '20

22 Apr '20

The master branch is is now open for post-beta merges, but only as described in the Post-Beta Merge Policy. See <https://github.com/boostorg/boost/wiki/Releases%3A-Beta-Merge-Policy> Reminder: The master branch closes for the release on April 22nd. -- The release managers

8 13

MySQL ASIO library
by Ruben Perez 22 Apr '20

22 Apr '20

Hi all, I have been writing an ASIO-based client for MySQL, trying to mimic what Beast is to HTTP. It currently supports SQL queries and prepared statements. It can be viewed here: https://github.com/anarthal/mysql-asio Do you guys think this has the potential to be useful or become part of Boost long term? Any feedback is very welcome. Thanks, Ruben (Anarthal).

6 12

[release] Reminders - Master branch closes for 1.73.0 release TOMORROW
by Marshall Clow 21 Apr '20

21 Apr '20

And don't forget to update your release notes! -- Marshall

2 1

[build][b2] Add colors support to echo rule and actions
by Mateusz Loskot 21 Apr '20

21 Apr '20

Hi, I did an experimental UI/UX wank for B2: https://github.com/boostorg/build/pull/573 If anyone is interested in this kind of thing, then let's make B2 great again! ;) Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

1 0

[geometry] Boost 1.73 beta docs include broken links to Geometry Extensions
by Mateusz Loskot 19 Apr '20

19 Apr '20

Hi, I asked about it here a while ago, but without responses [1] https://lists.boost.org/Archives/boost/2020/03/248531.php We have been observing this problem since 1.70 and we have pretty much run out of ideas what is wrong with Boost.Geometry setup [2] https://github.com/boostorg/geometry/issues/585#issuecomment-605106308 The issue is still observed in the 1.73 beta docs [3] https://github.com/boostorg/geometry/issues/585#issuecomment-614263295 Could anyone help us understand [2] what is the problem with our docs? Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

1 1

Wrong boost.173-beta1 tag for boost.test
by Raffi Enficiaud 18 Apr '20

18 Apr '20

Hi, I just noticed that the tag "boost-1.73-beta1" points to e8b173655c207ec2286227fe17f2e1f68ce44f17 in boost.test, while master points to 9a8cdba280a9c5dc60c4781a26e055ebfe2446ea, and the content of the boost_1_73_0_b1_rc1.tar.bz2 archive is the same as master. I am expecting that the tag "boost-1.73-beta1" points to the content of the archive boost_1_73_0_b1_rc1 . Raffi

2 1

Git documentation is full of twisty passages
by Jonathan Wakely 17 Apr '20

17 Apr '20

I've once again got lost trying to find how to check out Boost from Git. I started at boost.org and (after some missteps) went to https://www.boost.org/users/download/#repository which tells me "Details of the git repositories are on the Boost wiki." https://svn.boost.org/trac/boost/wiki/ModularBoost That takes me to a page with about 20 links. Eventually I decided that the 13th one is the one I want: Getting Started with Modular Boost https://svn.boost.org/trac10/wiki/TryModBoost That takes me to a page that says: "This page is superseded by https://github.com/boostorg/boost/wiki/Getting-Started Please help migrate the rest of the old wiki !" But when I go to that page it says: "The Boost Wiki is at: https://github.com/boostorg/wiki/wiki" So I go there instead, which has nothing about Git. The "Getting Started" page has a link to "Getting Started with Modular Boost Library Development using Git" right at the very bottom, and the "Getting Started - Using Git" link in the sidebar takes me to a different page with very generic Git info (not specific to Boost), and again, near the bottom, is the "Getting Started with Modular Boost Library Development using Git" link. So I click that and ... I'm back in Trac, at https://svn.boost.org/trac10/wiki/StartModWorkflow I don't care bout Boost's use of Git Flow. I don't care about your branching policy, I want to check out the repo! It turns out that on the front page of https://github.com/boostorg/wiki/wiki I should have clicked the "Cheat Sheet" link in the sidebar: https://github.com/boostorg/wiki/wiki/Getting-Started%3A-Cheat-Sheet Could you please make that easier to find from boost.org? It seems to me that https://www.boost.org/users/download/#repository should just link straight to that cheat sheet, or to another page with the correct git submodule commands for checking out the repo.

2 3

Fwd: teeks / boost.test: some test files not found
by Raffi Enficiaud 16 Apr '20

16 Apr '20

I am cross-posting this on the dev mailing list as I would like to know how to fix this before the 1.73 deadline. Thanks and sorry for cross-posting, Raffi -------- Forwarded Message from the test gmane group Hi, On some teeks workers, I have this strange issue: teeks99-09-p-64: https://www.boost.org/development/tests/develop/developer/output/teeks99-09… The error says: .../libs/test/test/framework-ts/log-formatter-test.cpp(117): error: in "test_logs": check output.match_pattern(true) has failed: Pattern file can't be opened! which means some files used for testing, such as test/test/baseline-outputs/log-formatter-test.pattern , are not found. Those files are advertised in the Jamfile, https://github.com/boostorg/test/blob/develop/test/Jamfile.v2#L145 I guess it would be a hard error on b2 if the files were not found. What should I do such that those workers find the test files? I recently added one file to the previous 2 existing files. Thanks, Raffi

1 0

[Graph] Min Cut with float weights
by Phil Endecott 16 Apr '20

16 Apr '20

Dear Experts, I am attempting to use stoer_wagner_min_cut for the first time. Using float as the edge weight type seems to be problematic for non-trivial graphs. I think this is possibly because it adds an edge weight to the cut weight and then later subtracts the same value, but doesn't get back to exactly the previous value due to loss of precision. The errors accumulate and eventually the reported cut weight is nonsense. I am now trying with integer weights but I worry that this could suffer overflows. If my edge weights are in the range 0...W, for a graph with E edges the largest cut weight would be < W*E. But does the algorithm ever use larger values internally? Also, I'd be interested if anyone has tried to break a graph into subgraphs by recursively breaking at the min_cut until the min_cut weight is below some threshold. I have a graph with of the order of 10^4 vertices and 10^6 edges and this would be tractable if the min_cuts broke the graph into roughly equal pieces; instead, they tend to remove a small number of vertices each time, leaving almost as much work for the next recursion. So I think I want to find a cut whose weight is below a threshold and that is in some sense locally minimal and that leaves two largish subgraphs. Any ideas? Cheers, Phil.

1 0

Reminder: 1.73.0 master branch closes one week from today
by Marshall Clow 15 Apr '20

15 Apr '20

22-Apr Boost 1.73.0 closed for release ASAP Boost 1.73.0 release -- Marshall

1 0

Re: [boost] MySQL ASIO library
by Andrey Semashev 14 Apr '20

14 Apr '20

[Sending this reply to list as opposed to personal email] On Wed, Mar 4, 2020 at 3:39 PM Richard Hodges <hodges.r(a)gmail.com> wrote: > On Wed, 4 Mar 2020 at 13:25, Andrey Semashev <andrey.semashev(a)gmail.com> wrote: >> >> On Wed, Mar 4, 2020 at 1:50 PM Richard Hodges via Boost >> <boost(a)lists.boost.org> wrote: >> > >> > > Why just MySQL? >> > >> > Getting something useful released is more important than getting something >> > perfect released. >> > >> > If Ruben has a ready-to-go solution for MySQL, why not make it available to >> > users? >> >> Making it available to users is not the same as making it part of >> Boost. Boost is known for general purpose libraries, as well as more >> domain-focused solutions, but it is not a place for wrappers around >> specific other libraries. Let alone, when the said libraries already >> have C/C++ API. > > Boost also has mpi, regex, asio::ssl and python. What are these if not wrappers around common c libraries? I'm not sure about Boost.MPI, but I thought it was not a wrapper of a single library, but of a standard API that can be implemented by different libraries. Boost.Regex is not a wrapper at all; it implements regular expressions from scratch. asio::ssl is not a library but a plugin for Boost.ASIO that provides one small piece of functionality compared to the rest of the library. Boost.Python is probably closest to an exception, although it is a binding to another language (not a library), which arguably only has one C API and implementation. Yes, there is CPython, but I don't believe it offers a C API. >> > It can always be complemented or extended with Oracle, SQLite, ODBC etc etc >> > later. >> >> If the proposed library offers a stable and flexible API that can be >> backed by multiple implementations then by all means - that would be a >> very interesting proposal indeed. But the author has to demonstrate >> that the proposed user API can in fact be supported by more than one >> backend, so at least two backends need to be presented, and preferably >> with guidelines and infrastructure for adding more. > > Mpi, regex and python would dispute this arbitrary restriction. I don't think so, as per above. > Boost suffers from a lack of contribution. Is there any value in making contribution difficult? I don't think the amount of contributions by itself is the goal. There has to be value associated with the contribution. I just don't think a C++ wrapper of a specific library has enough value.

11 28

Code coverage tests
by Edward Diener 14 Apr '20

14 Apr '20

A number of libraries have code coverage/project tests in Github. I am not against such tests but I am against the idea that "failing" such a test, whatever that means, should prevent a PR from being merged into a Boost library. To me it is nonsense that a perfectly logical change to software should lead to some code coverage "failure", and that therefore the change should be deemed incorrect. I admit I do not know what the criteria are for code coverage but I do not see code coverage determining whether any change to a library is incorrect or not.

11 19

[release] Boost 1.72.0 Beta 1
by Marshall Clow 12 Apr '20

12 Apr '20

Boost release 1.73.0 beta 1 is now available at: <https://dl.bintray.com/boostorg/beta/1.73.0.beta.1/source/> The SHA256 checksums are as follows: 44f323b42c4375ab3751b67ac5ce53ba5267af20cf375be75675d8952d3cca4e ./boost_1_73_0_b1.7z 5270fa89243a3508331bd3773800de6d2f98d1f160b95e362fa8269d9cd58773 ./boost_1_73_0_b1.tar.bz2 82ffcd4a2e558a31f1ddd6a54ef6c00dae28b95c2ddee575c285544085dcb004 ./boost_1_73_0_b1.tar.gz 910b7560ee239472cc69e6a0c680dc4d9d7ea234faad807738ec98e4811c63d4 ./boost_1_73_0_b1.zip For details of what's in the release, see <https://www.boost.org/users/history/version_1_73_0.html>. Please download the beta, give it a try, and report any problems you encounter. Thanks, -- The Boost Release Team

1 0

[release] Boost 1.73.0 Beta 1 Release Candidate 1
by Marshall Clow 10 Apr '20

10 Apr '20

The release candidates for the first 1.73.0 beta release are now available at: https://dl.bintray.com/boostorg/beta/1.73.0.beta.1/source/ The release notes are not yet available. The SHA256 checksums are as follows: 44f323b42c4375ab3751b67ac5ce53ba5267af20cf375be75675d8952d3cca4e ./boost_1_73_0_b1_rc1.7z 5270fa89243a3508331bd3773800de6d2f98d1f160b95e362fa8269d9cd58773 ./boost_1_73_0_b1_rc1.tar.bz2 82ffcd4a2e558a31f1ddd6a54ef6c00dae28b95c2ddee575c285544085dcb004 ./boost_1_73_0_b1_rc1.tar.gz 910b7560ee239472cc69e6a0c680dc4d9d7ea234faad807738ec98e4811c63d4 ./boost_1_73_0_b1_rc1.zip As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. -- The Boost Release Managers

4 6

Re: [boost] [Boost-users] 404 GMane link in Boost.FileSystem doc
by Glen Fernandes 09 Apr '20

09 Apr '20

On Thu, Apr 9, 2020 at 6:15 AM Dominique Devienne wrote: > > Over at > https://www.boost.org/doc/libs/1_72_0/libs/filesystem/doc/reference.html#pa… > (and older version of the doc too) there's a link to > http://permalink.gmane.org/gmane.comp.lib.boost.devel/199744 > which is no longer so permanent :). According to https://en.wikipedia.org/wiki/Gmane > the website is no longer available. I guess any GMane link in docs should be updated > to another ML archive. Yes, the link should be updated to: https://lists.boost.org/Archives/boost/2010/02/162028.php Created https://github.com/boostorg/filesystem/commit/aaf54ada48b8da2bfc22b87d2890a… Glen

1 0

[release] 1.73.0 closed for Beta
by Marshall Clow 09 Apr '20

09 Apr '20

The master branch is now closed for all changes except by permission for the Beta release. Also, remember to add your libraries' changes to the release notes at: < https://github.com/boostorg/website/blob/master/feed/history/boost_1_73_0.q… > Thanks, -- The Boost Release Team

1 0

1.73.0 Beta Deadline this Wednesday 4/8
by Marshall Clow 09 Apr '20

09 Apr '20

The deadline for major changes has passed. Upcoming dates: 8-Apr Boost 1.73.0 closed for beta ASAP Boost 1.73.0 beta 22-Apr Boost 1.73.0 closed for release ASAP Boost 1.73.0 release "ASAP", in this list, means "As soon as possible after the preceding milestone" -- Marshall

6 16

boost [math] excessive warnings via [lexical_cast] from [date_time] (and others) for clang 3.4?
by Jeff Garland 08 Apr '20

08 Apr '20

In the regression tables the following warnings are coming out of math config. I'm trying to understand what this means given that 1) the tests compile and execute fine, 2) the deadline is up, and 3) several of the cases are compiled in c++11 mode (is it pre conformance bc it's clang3.4?). I've seen this warning in other places that include lexical_cast as well. So sure I could go and define the macro to quiet this, but seems like that should be done closest to the source. In other words maybe math should only tell us that in headers that have a real issue? Or will this soon be a real issue? ../boost/math/tools/config.hpp:42:9: warning: CAUTION: One or more C++11 features were found to be unavailable [-W#pragma-messages] ../boost/math/tools/config.hpp:43:9: warning: CAUTION: Compiling Boost.Math in pre-C++11 conformance modes is now deprecated and will be removed from March 2021. [-W#pragma-messages] ../boost/math/tools/config.hpp:44:9: warning: CAUTION: Define BOOST_MATH_DISABLE_DEPRECATED_03_WARNING to suppress this message. [-W#pragma-messages] Full examples https://www.boost.org/development/tests/develop/developer/date_time.html https://www.boost.org/development/tests/develop/output/teeks99-dkr-dc3-4-98…

5 23

Gsod20 interest
by Damian Vicino 08 Apr '20

08 Apr '20

Hi, I'm wondering if there is interest in submitting boost as a potential org for Google season of docs (https://developers.google.com/season-of-docs) Also, if someone would like to be mentor on it, that would be great to know too. Best regards, Damian

2 1

Boost local unix domain example for IPC
by Jupiter 08 Apr '20

08 Apr '20

Hi, I am doing boost local unix domain for IPC, I midified the code based on sample code from boost_asio/example/local/stream_server.cpp, I am a little bit puzzled for errors calling different async_read, if I call original code using shared_from_this() it works fine: boost::asio::async_read(this->mSocket, boost::asio::buffer(this->mData), boost::bind(&session::HandleRead, shared_from_this(), boost::asio::placeholders::error, boost::asio::placeholders::bytes_transferred)); But if I tried to run a following lambda function which works in in my other boost asio TCP socket, it got an error "Operation canceled", what I could be missing here? Or do I have fundamontal problems in the lambda function I used for other TCP socket programs? boost::asio::async_read(this->mSocket, boost::asio::buffer(this->mData, sizeof(this->mData)), [=](const boost::system::error_code &status, const uint32_t size) {this->HandleRead(status, size);}); Thank you. Kind regards, - jh

2 2

[xpressive] Where are the names in the c_ctype.h file coming from
by Edward Diener 07 Apr '20

07 Apr '20

In the xpressive header file c_ctype.h there are names such as _ALPHA, _UPPER, _LOWER, _DIGIT etc. Where are these names declared or defined ? I searched through all the Boost libraries and did not find any of these names declared or defined anywhere. Are they supposed to be part of some C++ standard header file ?

1 0

Asio, gcc and -fconcepts
by Richard Hodges 07 Apr '20

07 Apr '20

Dear all, With the upcoming Boost 1.73 release imminent, I felt it was worthwhile pointing out that latest gcc has a problem with Asio if the `-fconcepts` command line flag is set. There is an issue in the Boost.Asio repo here relating to the manifestation of the bug in MSVC: https://github.com/boostorg/asio/issues/312 and an issue here in the Boost.Beast repo: https://github.com/boostorg/beast/issues/1884 It seems that the file boost/asio/detail/config.hpp was written when concepts support was not widespread and still in the concepts.ts stage. The syntax and capabilities of concepts were subtly changed during standardisation, with gcc and MSVC only supporting the C++20 dialect. Thus, compiling an Asio-based program with concepts enabled in either of gcc or MSVC fails unconditionally. I'm wondering if anyone has Chris' ear and might ask him to indulge us with a fix prior to the 1.73 release. I fear that by the time Boost 1.73 is in mainstream use, C++20 will be upon us we'll see an increase in issues and a loss of reputation as a result. Thanks for your time, Sincerely, -- Richard Hodges hodges.r(a)gmail.com office: +442032898513 home: +376841522 mobile: +376380212

3 4

[Performance of circular_buffer vs Queue][Multithreading may be broken]
by Jan Hafer 04 Apr '20

04 Apr '20

Dear Boost developer, I found the circular buffer to be slower than std::queue for multithreading except in the case of a single thread (where it is notably faster). I am using resize() to have the expected size filled as in vector. Is this behavior expected or documented anywhere? What kind of speedup is to be expected against the std::queue implementation? If there is none, then what is the purpose of circular buffer? I do also have broken code on a multithreaded application that worked fine before. I do pass the circular buffer as reference via functions from file scope, which in combination with the threads (initially starting elsewhere) somehow broke the code. Do you do regular benchmarks against other implementations? I dont see linked graphs on your homepage. Regards, Jan

7 10

[1.73][thread] Merge to master and apply PRs
by Andrey Semashev 04 Apr '20

04 Apr '20

Hi, There are a number of fixes in Boost.Thread develop that I would like to see in 1.73, but they are not merged to master. The last commit to develop was in Dec 2019, so plenty of time has passed for testing. I'd like to ask someone to merge develop to master. https://github.com/boostorg/thread/issues/311 Also, there are two PRs hanging for quite some time that I would also like to see in 1.73: https://github.com/boostorg/thread/pull/309 https://github.com/boostorg/thread/pull/310 I'd like to ask someone with merge permissions to have a look and merge them (first to develop, and then to master, after testing). I tried pinging Vicente, but he is not responding. Most of the changes in develop and the PRs are aimed to resolve various warnings generated by Boost.Thread, including using deprecated features of Boost.Bind, Boost.WinAPI and C++. Thanks.

1 0

Re: [boost] Linking libboost_python.so to libpython
by Peter Dimov 03 Apr '20

03 Apr '20

> That's why you weren't getting the error before 1.72, but not the reason > why libboost_serialization ends up with the different property sets. FWIW, my Travis build/install of --with-mpi works: https://travis-ci.org/github/boostorg/boost_install/jobs/669821455 and I can't find the place that's setting <dll-path>/usr/lib <dll-path>/usr/lib/python3.8/config.

2 1

Linking libboost_python.so to libpython
by Jonathan Wakely 03 Apr '20

03 Apr '20

tools/build/src/tools/python.jam says: # On *nix, we do not want to link either Boost.Python or Python extensions # to libpython, because the Python interpreter itself provides all those # symbols. If we linked to libpython, we would get duplicate symbols. So # declare two targets -- one for building extensions and another for # embedding. Why would that give duplicate symbols? Wouldn't ELF symbol interposition mean that only one is used? Why would it be a problem to link to libpython? In Fedora's Boost RPM packages we *do* link libboost_python.so to the system libpython (and we don't get any problems). But to do this, we have these two local patches: https://src.fedoraproject.org/rpms/boost/blob/master/f/boost-1.57.0-python-… and then to make it link to libpython3.7m.so (rather than libpython3.7.so) we have this patch to pass the "m" into the Boost build: https://src.fedoraproject.org/rpms/boost/blob/master/f/boost-1.66.0-python-… I'd prefer not to need these local hacks. Would the upstream Boost.Python consider making changes so that libboost_python.so can be (optionally) linked to libpython? Is there a cleaner way to do this than those patches?

5 12

Regarding GSoC 2020 Proposal for uBLAS Dataframes
by Tom Kwok 02 Apr '20

02 Apr '20

Hi everyone, I have submitted a final PDF version of my GSoC 2020 Proposal for uBLAS Dataframes, just before the deadline yesterday. I would be looking forward to receiving feedback from potential mentors. Today I read my final proposal again and I noticed a bunch of typos, such as incorrectly stating “heterogenous” columns for a data frame (which should be “homogeneous” columns since they are single-typed), and a few others. I am very sorry for the typos due to rushed drafting and submission. I am aware that it would be unfair to other participants to make corrections after the deadline, and please take the final PDF version submitted for review. Here I am only trying to let reviewers know, when they give comments, that I am already aware of some of the minor typos, which are fixed in a patched version of my proposal accessible via the submitted link to “draft” that points to a Google Drive document that I can update at any time (with document creation date in the heading generated by my Latex template). Best regards, Tom

2 1

[gil] Review of move assignment operator for image class
by Mateusz Loskot 02 Apr '20

02 Apr '20

Hi, We're adding move semantics to some of GIL classes [1] and we'd like to receive feedback on the move-assignment operator for the image class [2] (copied below) that we've worked out so far if there are any major blunders to correct or gaps to fill for C++11 compliant implementation: image& operator=(image&& img) { if (this == std::addressof(img)) return *this; auto const exchange_memory = [](image& lhs, image& rhs) { lhs._memory = boost::exchange(rhs._memory, nullptr); lhs._align_in_bytes = boost::exchange(rhs._align_in_bytes, 0); lhs._allocated_bytes = boost::exchange(rhs._allocated_bytes, 0); lhs._view = boost::exchange(rhs._view, image::view_t{}); }; constexpr bool pocma = std::allocator_traits<Alloc>::propagate_on_container_move_assignment::value; if (pocma) { // non-sticky allocator, can adopt the memory, fast destruct_pixels(this->_view); this->deallocate(); this->_alloc = img._alloc; exchange_memory(*this, img); } else if (_alloc == img._alloc) { // allocator stuck to the rhs, but it's equivalent of ours, we can still adopt the memory destruct_pixels(_view); this->deallocate(); exchange_memory(*this, img); } else { // cannot propagate the allocator and cannot adopt the memory if (img._memory) { allocate_and_copy(img.dimensions(), img._view); destruct_pixels(img._view); img.deallocate(); img._view = image::view_t{}; } else { destruct_pixels(this->_view); this->deallocate(); this->_view = view_t{}; } } return *this; } One thing that is still missing is the noexcept with expression evaluated based on something like this template <class _Alloc> using is_noexcept = std::conditional_t < std::allocator_traits<_Alloc>::is_always_equal::value, _Equal_allocators, typename std::allocator_traits<_Alloc>::propagate_on_container_move_assignment::type >; but we there is no is_always_equal in C++11, so there are gaps to fill. Any comments are appreciated. [1] https://github.com/boostorg/gil/pull/457/ [2] https://github.com/boostorg/gil/blob/7d8df1c105e81070e30ef68ea7abb8e39111d6… Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

1 1

Request to review my GSoc Proposal[Boost multiprecision
by suyashtava 01 Apr '20

01 Apr '20

Dear Sir/Ma'am, It would be great if you could review my GSOC proposal for [Boost multiprecision]: New Big-Double Backend Types Doc link: https://docs.google.com/document/d/1xznSxg1XcAiQMnVXSMG_NwxuUeGmkI5iXhabSXe… I deeply regret and apologize for the late submission, but I request you to review it once as it will surely help me to update it in required ways. With regards Suyash Srivastava IIT(ISM) Dhanbad -- Sent from: http://boost.2283326.n4.nabble.com/Boost-Dev-f2600599.html

5 6

[GSoC2020][Boost.Real] Greeting
by Firmin Martin 01 Apr '20

01 Apr '20

Hi, Boost community! This mail is not intended to serve as a proposal review (it's too late obviously). Instead, I would want to greet my potential mentors and possible collaborators. Anyway, whether or not my proposal is retained, I will probably still contribute after GSoC 2020 since I've got familiar enough to the codebase by dint of reading blog posts, references and code sources. I made a small PR involving BBP formula to compute the n-th binary digit of pi and already submitted my final proposal to GSoC. Best regards, Firmin

2 1

Download links all broken?
by John Maddock 31 Mar '20

31 Mar '20

All the download links from www.boost.org appear to be currently broken - which is to say no one can download Boost right now. Ideas or fixes anyone? Thanks, John. -- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

10 21

[test][program_options] Avoid deprecated bind placeholders in global namespace
by Mateusz Loskot 31 Mar '20

31 Mar '20

Hi, I have a shy request to maintainers of boostorg/test and boostorg/program_options Would it be possible to merge these trivial patch to both: https://github.com/boostorg/test/pull/259 https://github.com/boostorg/program_options/pull/92 Thanks in advance. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

2 2

Proposal Review
by Kishan shukla 31 Mar '20

31 Mar '20

Hello everyone, I have prepared the draft proposal for the boost.Real project. It involves adding new mathematical functions and operators into the library. I have also planned on optimizing a few algorithms and addressing previously unresolved issues. The proposal is the result of my discussion with my mentor Damian Vicino. Sorry for being late. Please review the proposal and provide your valuable feedback. Proposal link: https://docs.google.com/document/d/1oXAaaiqgtC2bTCfADPwXUY4ItYw-C8EMOLr2Bhu… Regards, Kishan Shukla

2 2

GSoC 2020
by Sachin Saw 31 Mar '20

31 Mar '20

Dear Developers, I am Sachin, a third year undergraduate student at Indian Institute of Technology Kharagpur, I have been using C++ for around three years and have a good experience in it. I like to contribute to boost on Boost.Geometry during GSoC’20. I went through https://www.iis.sinica.edu.tw/page/jise/2012/201205_10.pdf and found a great explanation of algorithm during GSoC period I would like to work on above algorithm (in the link) and concave hull using k-nearest neighbours approach so that one would act as a test for other. If would love to have suggestion from you Thanks,

2 3

[gsoc20] Proposal review for Boost.Real
by Vikram Chundawat 31 Mar '20

31 Mar '20

Hello everyone, I have prepared my draft proposal for Boost.Real project on improving the base, adding new number types and adding a method to calculate powers. Here is the link to the proposal https://docs.google.com/document/d/10Hy87Ok7UTzqPvzD35BkrlL-Sx4G8HfSCzchwYa… I have been in touch with this project's potential mentor Damian Vicino and this proposal is the result of my discussion with him. Please kindly provide your valuable feedback on the proposal. Thank you Regards Vikram Singh Chundawat

2 2

[gsoc20]Proposal for general robust predicates for Boost.Geometry
by Tinko Bartels 30 Mar '20

30 Mar '20

Hello Boost-Community, I have prepared a draft proposal for general robust predicates for Boost.Geometry. The ideas are described in more detail in the proposal, but I will briefly describe them here: A number of geometric algorithms, such as the triangulation of a point set, employ geometric predicates (implemented as strategies in Boost.Geometry). One example for such a predicate is the 2d orientation test, which, given three points p1, p2, p3, determines whether p3 lies on the left or right side of the line segment that goes through p1 and p2. Using floating-point arithmetics to answer that question can lead to incorrect and ultimately inconsistent results that may cause the algorithm that employs the predicate to produce nonsensical results or crash entirely for certain inputs. Using algorithms for exact floating-point arithmetics combined with some considerations regarding forward error analysis, a complicated method can be implemented that evaluates such predicates robustly and only adaptively increases the precision if necessary to avoid expensive high precision computations whenever possible. I propose a general, automated approach that generates such robust, adaptive predicates from arbitrary arithmetic expressions. Currently, Boost.Geometry has robust adaptive predicates for the 2d orientation and the 2d incircle test. This work would enable us to easily extend this to 3d orientation, 3d insphere, and generally all predicates that can be evaluated by determining the sign of a polynomial. I want to present my proposal for review publicly now: https://docs.google.com/document/d/19zH9QuSSNWAHm1DP5poxbRxcMXlzRVWfL5Wslbe… Kind regards Tinko Bartels -- Sent from: http://boost.2283326.n4.nabble.com/Boost-Dev-f2600599.html

3 3

[cmake][array][vs] Trying develop and test a single library
by Mateusz Loskot 30 Mar '20

30 Mar '20

Hi, I'm learning about the boostorg/cmake infrastructure offered by Peter. I picked Boost.Array as a library with simple build setup. I replaced the existing (hand-rolled?) CMakeLists.txt files with the generated ones: b2 tools\boostdep\build dist\bin\boostdep.exe --cmake array Then, learning form boostorg/cmake itself how to use it https://github.com/boostorg/cmake/blob/develop/.travis.yml#L228 cd BOOST_ROOT mkdir __build__ && cd __build__ cmake -DBOOST_ENABLE_CMAKE=1 -DBoost_VERBOSE=ON -DBOOST_INCLUDE_LIBRARIES=array .. cmake --build . ctest --output-on-failure -R boost_array Visual Studio solution is nicely generated, all expected .vcxproj files too, but, AFAICT, neither the last two commands nor these do anything: cmake --build . --config Release cmake --build . --config Debug I loaded the Boost.sln in VS 2019 and Build > Build Solution worked. I also noticed this 'unusual' project-as-target called check. I'm back in the CLI mode and run: cmake --build . --target check this time all the tests build and run. Interestingly, if I feed the ctest with the build configuration, then it also builds the tests, and runs them too, of course: ctest --output-on-failure -R boost_array -C Release ctest --output-on-failure -R boost_array -C Debug Is this `cmake --build .` doing nothing specific Boost.CMake? Is that `check` target supposed to be used explicitly? Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

4 8

FW: Request to review my GSoC proposal[Boost multiprecision]
by Kindly review GSOC Proposal [Boost multiprecision]: New Big-Double Backend Types 30 Mar '20

30 Mar '20

Sent from [1]Mail for Windows 10 From: [2]Kindly review GSOC Proposal [Boost multiprecision]: New Big-Double Backend Types Sent: Monday, March 30, 2020 2:14 PM To: [3]boost(a)lists.boost.org Subject: Request to review my GSoC proposal[Boost multiprecision] Dear Sir/Ma'am, It would be great if you coul review my GSOC proposal for [Boost multiprecision]: New Big-Double Backend Types Doc link: [4]https://docs.google.com/document/d/1xznSxg1XcAiQMnVXSMG_NwxuUe GmkI5iXhabSXe_WuQ/edit?usp=sharing I deeply regret and apologize for the late submission, but I request you to review it once as it will surely help me to update it in required ways. With regards Suyash Srivastava IIT(ISM) Dhanbad Sent from [5]Mail for Windows 10 References 1. https://go.microsoft.com/fwlink/?LinkId=550986 2. mailto:suyash.17je003210@cse.iitism.ac.in 3. mailto:boost@lists.boost.org 4. https://docs.google.com/document/d/1xznSxg1XcAiQMnVXSMG_NwxuUeGmkI5iXhabSXe… 5. https://go.microsoft.com/fwlink/?LinkId=550986

1 0

feedback on litpton-tarjan separator
by Jeff Linahan 30 Mar '20

30 Mar '20

Hello BGL users, after 5 years I'm almost ready to start writing documentation for my lipton-tarjan planar separator algorithm and finally submit my first implementation for formal peer review for inclusion in BGL. But one last question I have is feedback on how people would like the public interface for how a function like this will work (especially the template part which I'm not as good at). The internals will be easier to change as I continue to develop the implementation. This is essentially what I have now: struct Partition { std::set<vertex_t> a, b, c; }; Partition lipton_tarjan_separator(boost::adjacency_list<boost::vecS, boost::vecS, boost::undirectedS, boost::property<boost::vertex_index_t, uint>, boost::property<boost::edge_index_t, uint>> const&); I'd like to make it more generic eventually, but is that good enough for inclusion in BGL as is? Full code here: https://github.com/jeffythedragonslayer/lipton-tarjan Thanks, Jeff

1 1

Google Code Summer Challenge
by Calvin Green 30 Mar '20

30 Mar '20

Dear Boost C++, Hello, my name is Calvin Green Jr. I am a sophomore Computer Science major from Chicago, IL. I was emailing you to see if you can send me your guy's Google Challenge mentor's emails or assign me to one for the Summer challenge. Sincerely, Calvin Green

2 1

[GSoC 2020] Extraordinary circumstances and early birds
by madhur4127 29 Mar '20

29 Mar '20

Hi Boost Community, I am Madhur, an active contributor to Boost.Multiprecision. I am from India and am observing that summer internships (for students in the penultimate year) are being canceled because of COVID-19. This is a huge loss to brilliant and enthusiastic students as they will not be able to gain experience. This could be an opportunity for Boost to mentor these students who don't have prior experience with open source or with a rich C++ background. If a student is ready to devote himself/herself then I guess there's enough time to learn (till Jun 1) about C++/Project to get things rolling. > FYI, you are late. Mateusz posted in other thread about the student being late (as of today) but the GSoC application deadline is due March 31, which I would wholeheartedly agree in case of normal circumstances. The point I'm trying to make here is that in these extraordinary circumstances: - should Boost neglect the "early bird" and treat all applicants equally? - should Boost compensate for the lack of work samples with the history of the student (like academic records, academic projects, research papers)? - should Boost consider other factors too while selecting the student this year like the education level (seniority level: 4th/5th year of study or PhD)? For example, if a student had taken a course in numerical algorithms/computational algorithms then that applicant's insights could be beneficial to Boost.Multiprecision than other applicants. If a student performs well in the competency test then it indicates that the student would do the job and I think the selection criteria should be tweaked so as to consider that students who lost internships and otherwise who could be a great value to the library (even for a short time - GSoC) don't get neglected. Well, these are my views as a student. Eagerly waiting for your thoughts! Thank you for having time to read this unusually long message :) -- Sent from: http://boost.2283326.n4.nabble.com/Boost-Dev-f2600599.html

7 7

[GSoC20] Seeking mentor
by Martin Carrasco Castaneda 29 Mar '20

29 Mar '20

Hello, I am seeking a mentor for the GSoC program for this year. I have some experience with DSP and just submitted a very basic PR with a filter implementation. I find this topic very interesting and have some general ideas for available mentors. I'd like to work in implementing features for deblurring such as the Weigner filter or the Least Square filtering. I am also interested in working in feature extraction filters such as the Hough transform or related subjects. I am pretty much open to any subject relating to GIL. Thanks for the responses in advance, Regard, Martin -- La información contenida en este e-mail y sus anexos es confidencial, privilegiada y está dirigida exclusivamente a su destinatario, en consecuencia, solo puede ser utilizada por aquel. Si usted no es el destinatario original, no deberá examinar, usar, copiar o distribuir este mensaje o la información que contiene. Si lo recibe por error, por favor reenvíelo a la persona que se lo envió y elimínelo. Cualquier retención o uso total o parcial no autorizada de este mensaje está estrictamente prohibida y sancionada por ley.

2 1

[gil][GSoC20] Proposal review
by Laxmikant Suryavanshi 29 Mar '20

29 Mar '20

Hi Boost Community, I have prepared a proposal for GSoC-2020 for Boost.GIL project `Implementation of Image Processing Algorithms`. I would like to review it and hear comments from you. https://docs.google.com/document/d/1qSYC_94ia28xutmW_qrC3pcSXJ8opfdxW514xRF…

2 2

Regarding PCT (boost astronomy , coordinate transformation/conversion)
by GOPAL RAMESH DAHALE 28 Mar '20

28 Mar '20

I have written a class to transform cartesian_representation vector with the help of the affine matrix(3x3). My problem is that I am not able to work with boost::unit:: quantity. I work with the quantity values but later on not able to assign it to the resulting cartesian_represtentaion(res). Any help is appreciated. Thank You.

2 1

[boost.multiprecision] Request to review GsoC proposal.
by Abhay Yadav 28 Mar '20

28 Mar '20

Hello, I have prepared the GsoC proposal. Please provide your valuable feedback. Proposal link : https://docs.google.com/document/d/1j9avtkQALwnesyKAq40wFtPaA1Adp2RUf3FUGCP… Thank you Regards, Abhay Singh Yadav

1 0

Fwd: new toolset in b2
by Grzegorz Konopko 28 Mar '20

28 Mar '20

Dear I am thinking about make automatic test for boost, but with not supporting toolset yet. Is there any tutorial or template for b2: how to add new toolset support? I was looking documentation already, in my opinion no simply way due lack of kind of "easy tutorial". Best regards Grzegorz Konopko

1 0

Hiring mentors for Google Summer of Code 2020
by David Bellot 28 Mar '20

28 Mar '20

Hi Boost community, we are recruiting the mentors for the Google Summer of Code 2020. If you wish to be a mentor, please contact me directly and I'll send you an invite. We need at least 10 mentors this year. Obviously, a mentor comes with ideas of projects and proposals for this Summer. Best regards, David

8 10

Looking for Boost.uBlas data frames project GSoC mentors
by Tom Kwok 28 Mar '20

28 Mar '20

Hi everyone, May I know if there are any potential mentors for my Boost.uBlas data frames project proposal besides Mr. David Bellot? He has not been responding to messages lately. Not sure if it is because of the recent Covid-19 situation. Best regards, Tom

6 12

[geometry] Global Boost documentation for master not refreshed?
by Mateusz Loskot 27 Mar '20

27 Mar '20

Hi, A long while ago there was a problem in Boost.Geometry [1] that caused addition of unwanted sections to the global docs: https://www.boost.org/doc/libs/1_70_0/#lib-geometry-extensions https://www.boost.org/doc/libs/1_70_0/#lib-geometry-index and the problem [1] has been fixed a while ago in the Geometry, in both branches develop and master. [1] https://github.com/boostorg/geometry/issues/585 The global docs for the develop branch look fixed, no unwanted sections, just the one we want: https://www.boost.org/doc/libs/develop#lib-geometry The global docs for the master branch still lists one of the two unwanted sections https://www.boost.org/doc/libs/master#lib-geometry-extensions Why is that? Are we still waiting for the rebuild or something had not cleaned up correctly before the last rebuild? Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

1 0

Boost Astronomy gsoc
by GOPAL RAMESH DAHALE 27 Mar '20

27 Mar '20

I want to contribute to boost astronomy in gosc and I have read that I have to find a mentor who is an experienced boost developer and then write the proposal. What should I do? I am not able to understand the procedure for contributing to boost. Please help. I appreciate that. Thank you.

2 1

uBlas and Google Summer of Code 2020
by David Bellot 27 Mar '20

27 Mar '20

Hi Boost community, I've added new projects for the Google Summer of Code 2020 for the Boost uBlas library (matrix computations, tensors and linear algebra). If you're a student and wish to candidate, please contact me as soon as possible. The list of projects is here: https://github.com/boostorg/wiki/wiki/Google-Summer-of-Code%3A-2020 Cheers, David

4 5

[GSoC 2020] Proposal Review
by deb 27 Mar '20

27 Mar '20

Here is my proposal for GSoC 2020. It takes into account the new timeline announced today. I do not ask for a full review (which can be done after the final submission) just a glance from the potential mentors to provide feedback on any section I might have missed or needs to be modified. Link to docs - https://docs.google.com/document/d/1qZZSuTF2xQoZVnkVeahDDIMlIJ5iiSUn0BMJxo7… Thanks in advance. Debabrata Mandal -- Sent from: http://boost.2283326.n4.nabble.com/Boost-Dev-f2600599.html

2 1

1.73.0 Release process has started!
by Marshall Clow 26 Mar '20

26 Mar '20

The deadline for new libraries and breaking changes has passed. Upcoming dates: 1-Apr Boost 1.73.0 closed for major changes 8-Apr Boost 1.73.0 closed for beta ASAP Boost 1.73.0 beta 22-Apr Boost 1.73.0 closed for release ASAP Boost 1.73.0 release "ASAP", in this list, means "As soon as possible after the preceding milestone" -- Marshall

1 0

[geometry] Planning switch to C++11
by Mateusz Loskot 26 Mar '20

26 Mar '20

Hi, We are planning to switch Boost.Geometry to C++11 https://github.com/boostorg/geometry/issues/590 Is the following procedure sensible: 1. Warn users on the Boost mailing lists about the planned switch to C++11 2. Make the switch (update the codebase) 3. Release the Boost.Geometry as C++11 e.g. with Boost 1.75 4. Announce on the Boost mailing lists that Boost.Geometry requires C++11 Are there any recommendations or requirements on how we should proceed? Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

7 16

[GSoC 2020] Proposal Review for Boost.Multiprecision
by aman mahansaria 26 Mar '20

26 Mar '20

Hello Boost Team, I have prepared my draft proposal for Boost.Multiprecision project on Extending and optimizing the library for thousands of bits. The link for the same is: https://docs.google.com/document/d/1BgDtR2VCoxq0FFPCyK50l6crG9GMrTKkDYDCRoi… Please kindly provide your valuable feedback on the same. I had also submitted the same for review on the GSoC site as well. Let me know in case there is any issue with viewing of the document. Thanks and Regards, Aman Mahansaria First Year M.Tech CSE, NIT Trichy

2 1

[GSoC 2020] Proposal Review for Boost.Multiprecision
by Ram Nad 26 Mar '20

26 Mar '20

Hello Everyone, I have prepared my draft proposal for Boost.Multiprecision project on Extending and optimizing the library for thousands of bits. Here is the link, https://docs.google.com/document/d/1C0GkLYGuBjLvIdp-NvGJAjxwtUvY7xfNGxOlaOW… I have been in touch with the potential mentors of this project for quite some time now. This proposal is result of my discussions with them. Please kindly provide your valuable feedback on the same. P.S. I have also submitted the same for review on the GSoC site as well. Also, please let me know if there are some visibility issues or comment access is not working. Thank you Ram Nad Second Year CSE Undergraduate Indian Institute of Information Technology, Sri City

2 2

[gsoc20] Proposal review for extending Boost.Multiprecision to higher precision
by dim131 26 Mar '20

26 Mar '20

Hi Boost community, I have prepared a draft of my proposal for extending and optimising Boost.Multiprecision to higher precision, after an initial discussion with Christopher Kormanyos: https://docs.google.com/document/d/100he6gJnUCilhsEiRWaL7PYi0IZaAL4tJfu-D3y… Any feedback will be greatly appreciated. Thank you, Dim131 -- Sent from: http://boost.2283326.n4.nabble.com/Boost-Dev-f2600599.html

3 3

[lightweight_test] cpp_main convention
by Mateusz Loskot 25 Mar '20

25 Mar '20

Hi, I noticed this as popular convention across Boost libraries (e.g. endian) to deal with test cases that may throw or leak exceptions: int cpp_main( int argc, char* argv[] ) { test(); return ::boost::report_errors(); } int main( int argc, char* argv[] ) { try { return cpp_main( argc, argv ); } catch( std::exception const & x ) { BOOST_ERROR( x.what() ); return boost::report_errors(); } } Is there any reason to prefer that one over this one? int main( int argc, char* argv[] ) { try { test(); } catch( std::exception const & x ) { BOOST_ERROR( x.what() ); } return boost::report_errors(); } Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

2 2

Preliminary release schedule for 1.73.0
by Marshall Clow 25 Mar '20

25 Mar '20

We missed the start of the release cycle for 1.73.0. Bad release managers. No biscuit. Here's my preliminary schedule for the 1.73.0 release: 25-Mar Boost 1.73.0 closed for new libraries and breaking changes 1-Apr Boost 1.73.0 closed for major changes 8-Apr Boost 1.73.0 closed for beta ASAP Boost 1.73.0 beta 22-Apr Boost 1.73.0 closed for release ASAP Boost 1.73.0 release "ASAP", in this list, means "As soon as possible after the preceding milestone" Please let me know if you see any problems with this. -- Marshall

2 2

Strange failure in regression matrix
by Alexander Grund 24 Mar '20

24 Mar '20

Hi, I got a failure of Boost.Nowide develop (and master) for msvc-14.0 in the regression matrix although that configuration is tested as far as I can tell. Furthermore there isn't any indication WHAT failed, see https://www.boost.org/development/tests/develop/developer/output/teeks99-09… Am I missing anything or is this a quirk of the regression tester? Thanks, Alex

1 0

Bug in Boost.Asio strand(strand<OtherExecutor>&& other)
by Niklas Gürtler 24 Mar '20

24 Mar '20

Hello, there is a bug in the Boost.Asio strand::strand(strand<OtherExecutor>&& other) move constructor as it tries to do an invalid cast on the wrong object. A friend declaration is also required to access the private members of the other strand. I submitted a PR https://github.com/boostorg/asio/pull/333 to address this issue. Regards, Niklas

1 0

[gsoc] Example of exceptional project proposal
by Mateusz Loskot 24 Mar '20

24 Mar '20

...as it is not Dear students, if you aim to submit proposals like this, then please don't bother polluting the GSoC space with such rubbish. Please, let's display some minimum of professionalism and respect to each other. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

1 0

[GSoC 2020] Proposal Review
by Ayush Bansal 24 Mar '20

24 Mar '20

Hi Boost Community, I have prepared a draft of my Proposal for Boost.GIL's Project on Implementation of Image Processing Algorithms. I'd love to hear your comments on the same. Link to Proposal - https://docs.google.com/document/d/1JwHOxS6DG0c0GgvBnpSmvxz1PtgMMlrga9FJOyO… Please let me know you reviews :) Thank you and Regards Ayush Bansal Fifth Year Undergraduate Student Department of Computer Science and Engineering IIT Kharagpur LinkedIn <https://www.linkedin.com/in/ayush-bansal-b0727a116/>

4 5

[Optional] Merge to master
by Alexander Grund 24 Mar '20

24 Mar '20

Hi, can Boost.Optional be merged to master? There is even a CI failure on develop with a PR fixing this. So would be great if those could be merged shortly. Thanks

1 0

[config] Merging 'develop' to 'master' before the 1.73 release
by Edward Diener 23 Mar '20

23 Mar '20

Are the changes in config's 'develop' branch going to be merged to the 'master' branch before the 1.73 release ? The reason I ask is that a config 'develop' PR which I authored is a dependancy of the tti library, ans I can not merge the 'develop' changes of tti into 'master' unless those config changes also are merged to 'master'.

2 2

Re: [boost] Looking for Boost.uBlas data frames project GSoC mentors
by Tom Kwok 23 Mar '20

23 Mar '20

Hi CB, Thank you for your suggestions. I will continue with my proposal and start solving the competency test. David as of now still has not replied though. So I might need to request for mentorship for Boost uBlas data frame GSoC project here. Is anyone interested in offering mentorship and reviewing my proposal and questions? Best regards, Tom > On 19 Mar 2020, at 3:00 PM, boost-request(a)lists.boost.org wrote: > > Date: Wed, 18 Mar 2020 18:26:43 +0100 > From: Cem Bassoy <cem.bassoy(a)gmail.com <mailto:cem.bassoy@gmail.com>> > To: boost(a)lists.boost.org <mailto:boost@lists.boost.org> > Subject: Re: [boost] Looking for Boost.uBlas data frames project GSoC > mentors > Message-ID: > <CADrR+Fv8r8GrNFs-w_bvy2VBmDP6w0w+FOOOeDh0Rax02-gBEw(a)mail.gmail.com <mailto:CADrR+Fv8r8GrNFs-w_bvy2VBmDP6w0w+FOOOeDh0Rax02-gBEw@mail.gmail.com>> > Content-Type: text/plain; charset="UTF-8" > > Hi Tom, > > probably David will be the only mentor for the data frame project. I > suggest that you continue with your proposal and solve the competency test. > You can find the data frame code at > https://github.com/BoostGSoC19/data_frame <https://github.com/BoostGSoC19/data_frame> > > Last year I mentored two great students for the Tensor project > <https://github.com/BoostGSoC19/tensor/wiki <https://github.com/BoostGSoC19/tensor/wiki>>. This year I can only mentor > one student. > > Good luck, > CB

2 1

[GSOC] [boost.multiprecision] Regarding test cases.
by Abhay Yadav 23 Mar '20

23 Mar '20

Hello, In the project of Multiprecision Big Number Types I have completed programming competency test but I want to know how test cases for higher precision will be generated? Is there any platform where we can compare desired output with my output? It will be more helpful.for me for proceeding in this project.. Thank you Regards, Abhay Singh Yadav

3 3

[parameter][1.73] Library broken and unattended. Regressions and unmerged PR.
by Andrey Semashev 22 Mar '20

22 Mar '20

Hi, I'd like to draw attention to Boost.Parameter state. Since 1.71, it seems to be broken as described in these issues: https://github.com/boostorg/parameter/issues/91 https://github.com/boostorg/parameter/issues/97 The latter one was actually reported to me in Boost.Log, as this Boost.Parameter bug affected its users in a rather nasty way (the user's code silently compiles and has the wrong effect). For the latter issue I created a PR with a fix: https://github.com/boostorg/parameter/pull/99 which got no reply so far. The person who assumed Boost.Parameter maintenance and made the problematic changes, Cromwell D. Enage, is not responding, so the library is basically broken and unmaintained. I really don't want 1.73 to be released with a bug like the one affected Boost.Log, so I would appreciate if someone with merge permissions could merge my PR. If not, I will be forced to fork the library internally in Boost.Log for 1.73 (which I also really don't want to do). This would take care of my immediate concern. The other issue seems to be affecting users as well and I don't have the solution for it. Given that the library is unmaintained, it might be better to: 1. Move the current state of develop to a separate branch. 2. Revert master and develop to a state prior to Cromwell's commits that went into 1.71 (i.e. to the 1.70 state). This should take care of the Boost.Log issue as well, so it would be fine with me as well. Thanks.

2 2

github pull request process on non-owned submodule
by Jeff Garland 22 Mar '20

22 Mar '20

Sorry if this is obviously documented somewhere, but searches of mailing list aren't helping. I'm looking to submit a pull request for the icl library to remove dependencies on date_time compiled library -- in conjunction with changes to date_time on develop now. I've basically followed the cheat sheet on the wiki: https://github.com/boostorg/wiki/wiki/Getting-Started%3A-Cheat-Sheet but when I try to push my branch I get permission errors. Is there something I did wrong or is the icl repo setup wrong? Thx, Jeff jeff@jeff-mint193:~/dev/boost/libs/icl$ git push origin dt_nolib Username for 'https://github.com': JeffGarland Password for 'https://JeffGarland@github.com': remote: Permission to boostorg/icl.git denied to JeffGarland. fatal: unable to access 'https://github.com/boostorg/icl.git/': The requested URL returned error: 403

2 2

Fwd: Projects for GSoC 2020
by degski 20 Mar '20

20 Mar '20

---------- Forwarded message --------- From: degski <degski(a)gmail.com> Date: Sun, 1 Mar 2020 at 17:00 Subject: Re: [boost] Projects for GSoC 2020 To: David Bellot <david.bellot(a)gmail.com> Yes. On Sun, 1 Mar 2020 at 04:26, David Bellot <david.bellot(a)gmail.com> wrote: > It sounds a good idea to me. Would you like to propose a project and be a > mentor? > It would be great! > > David > > On Thu, Feb 27, 2020 at 8:19 AM degski via Boost <boost(a)lists.boost.org> > wrote: > >> On Wed, 26 Feb 2020 at 14:39, David Bellot via Boost < >> boost(a)lists.boost.org> >> wrote: >> >> > Hi Boost community, >> > >> > so far we received a few good contributions for projects for GSoC 2020. >> The >> > proposals are from our usual mentors but I'm surprised we don't have >> more >> > projects in data structures and algorithms. Most of what we have concern >> > numerical problems. It's great but I wish to see more diversity in the >> type >> > of projects we propose. >> > >> >> Maybe the suggestions put forward do solicit few 'other' proposals. For >> containers, f.e. there are many 'entertaining' and useful things to >> consider, segment tree, spaghetti stack, trie, binary index tree, beap, >> kd-tree, bkd-tree, disjoint-set, n-ary tree, etc etc, etc. >> https://www.geeksforgeeks.org/advanced-data-structures/ presents many >> different data structures, there also a section on algos. >> >> degski >> -- >> @realdegski >> https://brave.com/google-gdpr-workaround/ >> "We value your privacy, click here!" Sod off! - degski >> "Anyone who believes that exponential growth can go on forever in a finite >> world is either a madman or an economist" - Kenneth E. Boulding >> "Growth for the sake of growth is the ideology of the cancer cell" - >> Edward >> P. Abbey >> >> _______________________________________________ >> Unsubscribe & other changes: >> http://lists.boost.org/mailman/listinfo.cgi/boost >> > -- @realdegski https://brave.com/google-gdpr-workaround/ "We value your privacy, click here!" Sod off! - degski "Anyone who believes that exponential growth can go on forever in a finite world is either a madman or an economist" - Kenneth E. Boulding "Growth for the sake of growth is the ideology of the cancer cell" - Edward P. Abbey -- @realdegski https://brave.com/google-gdpr-workaround/ "We value your privacy, click here!" Sod off! - degski "Anyone who believes that exponential growth can go on forever in a finite world is either a madman or an economist" - Kenneth E. Boulding "Growth for the sake of growth is the ideology of the cancer cell" - Edward P. Abbey

3 7

binomial distribution setter function
by Kemin Zhou 18 Mar '20

18 Mar '20

This is my first time posting in this mailing list. Not sure how to post to the developer only mailing list after reading the document for mailing list for a good half an hour. If I posted in he wrong mailing please let me know and kindly provide the developer mailing list. I am looking at the binomial.hpp file. I need to use the binomial object in a loop which requires to have high performance. I am thinking constructing the binomial object each time in the loop would be less efficient than if I construct a single object, the each time reset the p parameter and use the object. I am not sure why the setter method was not provided. 296 RealType success_fraction() const 297 { // Probability. 298 return m_p; 299 } 300 void set_success_fraction(RealType p) { 301 m_p=p; 302 } Line 296 is the getter method, I added the setter method at line 300. -- Kemin Zhou 858 366 8260

4 4

Boost.Nowide Ready for release
by Alexander Grund 16 Mar '20

16 Mar '20

Hi all, after the discussion in January this year I took over maintenance of Boost.Nowide. First goal: Integrate all changes and requests that came up during review and as Github Issues including the docs. Second goal: Get extensive CI running with coverage especially on Windows (it is a mainly Windows library) Third goal: Iron out bugs, performance issues and incompatibilities. Of great help was my fork I prepared (and announced here) earlier but it was still an incredible amount of work. I can now say I'm done! I invite everyone to test it, (re-)review the code or check the docu for anything that's missing: https://github.com/boostorg/nowide One of the bigger changes was to make the library "less header-only" (it already required compilation on Windows when using iostreams). This was due to some required functions being considered extensions by e.g. MinGW/Cygwin and hence failing for consumers build with `-std=c++98` (or similar). This now works! Final note for those interested: The standalone (non-Boost) version and converter will be available later. Happy poking!

3 3

[gil] Broken bit-aligned pixel locator on MSVC++ 64-bit optimized builds only
by Mateusz Loskot 14 Mar '20

14 Mar '20

Hi, Over the last few months, intermittently I've been chasing a peculiar bug that has been revealing itself in failing checksum tests in GIL's test/legacy/image.cpp [1] since we started testing GIL with MSVC++ (VS2017, VS2019) with b2 toolset=msvc variant=release address-model=64 [1] https://github.com/boostorg/gil/blob/2ff2d31895dae665ef3e05d0496bc082470e22… The peculiarity of this bug is that it has not been observed using any of these compilers: - GCC: 4.8, 4.9, 5, 6, 7, 8, 9 - Clang: 3.9, 4.0, 5.0, 6.0, 7, 8, 9, 10 - XCode: 8.3, 9.0, 9.1, 9.2, 9.3, 9.4, 10 There is complete report [2], but I also decided to reach the list looking for any insights that may help me to understand what may be causing the bug. Complete repo [3] has GitHub Actions to build and run minimal_test.cpp test. [2] https://github.com/boostorg/gil/issues/447 [3] https://github.com/mloskot/boost-gil-checksum-bug This minimal_test.cpp (at the bottom) leaves out the checksum calculation and narrows the scope of the bug down to the `xy_locator` and advances of the iterators. The test basically is this: 1. Create 3x3 image based on bit-aligned BGR or RGB pixel (e.g. bgr121_image_t) 2. Fill image with red 3. Draw blue diagonal ``` bgr121_image_t img(3, 3); // ... fill img with `bgr121_red` pixels // draw blue diagonal auto v = view(img); auto loc = v.xy_at(0, v.height() - 1); for (std::ptrdiff_t y = 0; y < v.height(); ++y) { *loc = bgr121_blue; // set blue pixel value ++loc.x(); // INCREMENT X FIRST --loc.y(); } ``` If the loop like this is compiled using either - `b2 toolset=msvc variant=release address-model=64 optimization=space` (/O1 /Ob2) - `b2 toolset=msvc variant=release address-model=64 optimization=speed` (/O2 /Ob2) then pixels of the blue diagonal are messed up. If the loop is compiled without optimization using either - `b2 toolset=msvc variant=debug address-model=64` (/Od /Ob2) - `b2 toolset=msvc variant=release address-model=64 optimization=off` (/Od /Ob2) then pixels of the blue diagonal are correct. Now, if the `for` loop above is modified, that is, lines incrementing the `x_iterator` and `y_itertor` are reordered: ``` for (std::ptrdiff_t y = 0; y < v.height(); ++y) { *loc = bgr121_blue; // set blue pixel value --loc.y(); ++loc.x(); // PRE-INCREMENT X SECOND } ``` or ``` for (std::ptrdiff_t y = 0; y < v.height(); ++y) { *loc = bgr121_blue; // set blue pixel value --loc.y(); ++loc.x(); // POST-INCREMENT X SECOND } ``` then the blue diagonal is drawn correctly regardless of the MSVC++ optimizations. If the loop is manually unrolled, see minimal_test.cpp below, the blue diagonal is correct too. I'm yet to try the CE to see compare the generated code, as far as my limited assembly fu goes, but currently Boost for MSVC++ on CE is broken (https://github.com/mattgodbolt/compiler-explorer/issues/1816) If anyone would have any insights on what may be causing the problem, or any suggestions what else to test, I would greatly appreciate that. Obviously, I'm getting suspicious about the MSVC++ optimizer, but I do know blaming a compiler is last+1 resort :) Thanks Mateusz ``` // minimal_test.cpp #include <boost/version.hpp> #include <boost/core/lightweight_test.hpp> #if BOOST_VERSION < 106900 #include <boost/gil/gil_all.hpp> #else #include <boost/gil.hpp> #endif namespace gil = boost::gil; #if BOOST_VERSION > 107200 using channel_sizes_t = boost::mp11::mp_list_c<int, 1, 2, 1>; #else using channel_sizes_t = boost::mpl::vector3_c<int, 1, 2, 1>; #endif using bgr121_ref_t = gil::bit_aligned_pixel_reference < std::uint8_t, channel_sizes_t, gil::bgr_layout_t, true > const; using bgr121_image_t = gil::image<bgr121_ref_t, false>; using bgr121_view_t = typename bgr121_image_t::view_t; using bgr121_pixel_t = typename bgr121_view_t::value_type; bgr121_pixel_t bgr121_red(0), bgr121_blue(0); void fill_image_red(bgr121_image_t& img) { gil::rgb8_pixel_t red8(255, 0, 0); gil::rgb8_pixel_t blue8(0, 0, 255); gil::color_convert(red8, bgr121_red); gil::color_convert(blue8, bgr121_blue); auto v = view(img); std::fill(v.begin(), v.end(), bgr121_red); for (auto it = view(img).begin().x(), end = view(img).end().x(); it != end; ++it) BOOST_TEST(*it == bgr121_red); } void test_draw_with_xy_locator_loop_fail(std::ptrdiff_t w, std::ptrdiff_t h) { bgr121_image_t img(w, h); fill_image_red(img); { auto v = view(img); auto loc = v.xy_at(0, v.height() - 1); for (std::ptrdiff_t y = 0; y < v.height(); ++y) { *loc = bgr121_blue; // OPTION 1 FAILS ++loc.x(); // PRE-INCREMENT X FIRST --loc.y(); // OPTION 2 FAILS TOO //loc.x()++; // POST-INCREMENT X FIRST //loc.y()--; // OPTION 3 FAILS TOO //auto& x_it = loc.x(); // PRE-INCREMENT NAMED X FIRST //++x_it; //auto& y_it = loc.y(); //--y_it; } } { auto it = view(img).begin().x(); // row 0 BOOST_TEST(*it == bgr121_red); ++it; BOOST_TEST(*it == bgr121_red); ++it; BOOST_TEST(*it == bgr121_blue); ++it; // row 1 BOOST_TEST(*it == bgr121_red); ++it; BOOST_TEST(*it == bgr121_blue); ++it; // FAIL BOOST_TEST(*it == bgr121_red); ++it; // row 2 BOOST_TEST(*it == bgr121_blue); ++it; BOOST_TEST(*it == bgr121_red); ++it; BOOST_TEST(*it == bgr121_red); } } void test_draw_with_xy_locator_loop_good(std::ptrdiff_t w, std::ptrdiff_t h) { bgr121_image_t img(w, h); fill_image_red(img); { auto v = view(img); auto loc = v.xy_at(0, v.height() - 1); for (std::ptrdiff_t y = 0; y < v.height(); ++y) { *loc = bgr121_blue; // OPTION 1 WORKS --loc.y(); ++loc.x(); // PRE-INCREMENT X SECOND // OPTION 2 WORKS TOO //loc.y()--; //loc.x()++; // POST-INCREMENT X SECOND } } { auto it = view(img).begin().x(); // row 0 BOOST_TEST(*it == bgr121_red); ++it; BOOST_TEST(*it == bgr121_red); ++it; BOOST_TEST(*it == bgr121_blue); ++it; // row 1 BOOST_TEST(*it == bgr121_red); ++it; BOOST_TEST(*it == bgr121_blue); ++it; BOOST_TEST(*it == bgr121_red); ++it; // row 2 BOOST_TEST(*it == bgr121_blue); ++it; BOOST_TEST(*it == bgr121_red); ++it; BOOST_TEST(*it == bgr121_red); } } void test_draw_with_xy_locator_step_good(std::ptrdiff_t w, std::ptrdiff_t h) { bgr121_image_t img(w, h); fill_image_red(img); { auto v = view(img); auto loc = v.xy_at(0, v.height() - 1); *loc = bgr121_blue; // red red blue ++loc.x(); --loc.y(); *loc = bgr121_blue; // red blue red ++loc.x(); --loc.y(); *loc = bgr121_blue; // blue red red ++loc.x(); --loc.y(); } { auto it = view(img).begin().x(); // row 0 BOOST_TEST(*it == bgr121_red); ++it; BOOST_TEST(*it == bgr121_red); ++it; BOOST_TEST(*it == bgr121_blue); ++it; // row 1 BOOST_TEST(*it == bgr121_red); ++it; BOOST_TEST(*it == bgr121_blue); ++it; BOOST_TEST(*it == bgr121_red); ++it; // row 2 BOOST_TEST(*it == bgr121_blue); ++it; BOOST_TEST(*it == bgr121_red); ++it; BOOST_TEST(*it == bgr121_red); } } int main() { test_draw_with_xy_locator_loop_fail(3, 3); test_draw_with_xy_locator_loop_good(3, 3); test_draw_with_xy_locator_step_good(3, 3); return boost::report_errors(); } ``` Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

1 1

[website] Update notes of historic releases
by Mateusz Loskot 11 Mar '20

11 Mar '20

Hi, Is this possible to update release notes of historic releases? I'd like to update notes of GIL for 1.69 which, as I found, have been never collected and are completely missing https://github.com/boostorg/gil/commit/2ff2d31895dae665ef3e05d0496bc082470e… Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

2 2

C++ Deflate (zlib-like) library
by Janson R. 11 Mar '20

11 Mar '20

Hello everyone, I have recently been working on a C++ compression library very similar to zlib after trying to implement some HTTP compression support over Boost.Beast and realizing after some discussion with sir Falco that while it would be a nice builtin feature for Beast, it would possibly be a better idea to have zlib-like compression be a separate library in order to be properly maintainable and likely more useful. The current working version can be viewed at https://github.com/ryanjanson/Deflate however the API could still be helped in terms of modern C++ usability, and what I currently have in mind can be found annotated here: https://gist.github.com/AeroStun/687ec9ca69404e26f8e02e5084926036 Do you thing that this could be useful to have as its own entity in the Boost environment? Any kind of feedback on the idea and the library is warmly welcome. Regards, Janson

14 58

boost thread strange behaviour
by Adham Sabry 08 Mar '20

08 Mar '20

hi , i am trying to learn executors and executors thread pools using with boost::async but i found strange behabiour when i make thread pool adaptor ea and submit tasks to it and make ea00 and submit tasks to it if i started ea with async , it automatically starts ea00 the attached file has the code i thought that async will only start the passed thread pool"adaptor" But i think there is underlying thing which gather all threads of different pools into single entity and starts them with any call to boost::async is this a bug??? i run this from windows 7 64 by visual studio 2017

3 7

[GSoC20] [Boost.Geometry] Seeking mentor for project 1
by João Tavares 07 Mar '20

07 Mar '20

Hello, I am a third year undergraduate student from IST - University of Lisbon in Applied Mathematics and Computer Science. I am very interested in the project 1 on the Boost.Geometry library. Having dealt with this sort of problem both on my university courses and on my own, in the context of competitive programming, I feel like I could contribute to this project during GSoC 2020. Regarding the competency test I have not been able to understand how or where it should be submitted. I am sending this e-mail to know whether there is someone willing to mentor me for this project. Thanks for the replies in advance. Best regards, João Tavares IST - University of Lisbon

2 1

ublas GSOC'20 Project
by Mrityunjay Tripathi 07 Mar '20

07 Mar '20

Hi everyone, I am Mrityunjay Tripathi, a 3rd-year Computer Science & Engineering undergraduate. I have been getting familiar with the boostorg/math and boostorg/ublas repositories for quite a few weeks. I find it quite interesting in terms of the functionalities they provide. But I see that the tensors section of uBLAS can be more improved by parallelizing the code using OpenMP and providing support for cuBLAS. I also wanted to add flexible NumPy/PyTorch tensor features such as autograd on tensors. Any feedback or suggestions are most welcome. Best Regards, Mrityunjay Tripathi

1 0

Hello!
by Kishan shukla 07 Mar '20

07 Mar '20

Hello Everyone! My name is Kishan Shukla, and I am a third-year undergraduate student of mathematics at IIT Kanpur. I am interested in contributing to Boost.real and have already sent two PR's https://github.com/BoostGSoC19/Real/pull/40 and https://github.com/BoostGSoC19/Real/pull/41, which are yet to be reviewed. Currently, I am stuck at a problem that I want to discuss with the mentors. Can I ask the project-specific issues here, or are there project-specific channels?

2 1

[build] ERROR: rule "[[bbv2.builtin.features.warnings]]`warnings`::" unknown in module "warnings-feature"
by Mateusz Loskot 06 Mar '20

06 Mar '20

Hi, (CC'ed to boost and boost-build) Two of Boost.Geometry users reported that peculiar error, [1] and [2] ``` /home/digu_j/boost/tools/build/src/tools/features/warnings-feature.jam:27: in load ERROR: rule "[[bbv2.builtin.features.warnings]]`warnings`::" unknown in module "warnings-feature". ``` and I'm having a hard time understanding what is going wrong here and what causes this issue, on Linux. The line 27 is a typical Jam line: ``` feature.feature warnings : on all extra pedantic off : incidental propagated ; ``` but this refers to something that puzzles me most ``` ERROR: rule "[[bbv2.builtin.features.warnings]]`warnings`::" unknown ``` a bit of comment block? ``` #| tag::doc[] [[bbv2.builtin.features.warnings]]`warnings`:: ``` Is this a parsing issue? Is this related to potentially existing system-wide installation of Boost.Build? If yes, why none of the dumps in [1] and [2] refer to any files in /usr? [1] ./b2 headers attempt https://github.com/boostorg/geometry/pull/667#issuecomment-584794370 [2] b2 attempt to build a program in libs/geometry https://github.com/boostorg/geometry/pull/665#issuecomment-595595900 Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

2 2

[date-time] USE_DATE_TIME_PRE_1_33_FACET_IO to be removed in next release
by Jeff Garland 06 Mar '20

06 Mar '20

//crosspost from users list In case you've not checked the calendar (see below) it's 2020 and a the c++ world has moved on from the issue this macro solved. boost date-time also needs to move forward into the decade with a modernized all header code base . If you're dependent on this macro for any reason I'd like to hear about it. Thanks, Jeff using namespace boost::gregorian; date today = day_clock::local_day(); cout << today.year() << endl; //2020 ;)

1 0

Help: [Boost.GIL] setup
by R Rajiv 06 Mar '20

06 Mar '20

Hi I am Rajiv, a student whose looking to contribute to Boost's GIL library this year for GSOC 2020. I have read through the contribution.md page for setup of the environment for Boost.gil @ https://github.com/boostorg/gil/blob/develop/CONTRIBUTING.md. As I do not have cloning rights for the repo boost.git, I have forked and cloned my fork with --recurse-submodules.This leads me to the following issue: _______ fatal: repository 'https://github.com/rRajivramachandran/accumulators.git/' not found fatal: clone of 'https://github.com/rRajivramachandran/accumulators.git' into submodule path 'libs/accumulators' failed ________ I have been unable to proceed due to this issue. -- Thanks Rajiv

3 2

[program_options] Codecov failing on Travis CI for long time
by Mateusz Loskot 06 Mar '20

06 Mar '20

Hi, I've just submitted my first PR [1] to the library and Travis CI failed with: +lcov --gcov-tool=gcov-7 --rc lcov_branch_coverage=1 --base-directory /home/travis/build/boostorg/boost-root/libs/program_options --directory /home/travis/build/boostorg/boost-root --capture --output-file all.info Capturing coverage data from /home/travis/build/boostorg/boost-root Can't locate PerlIO/gzip.pm in @INC (you may need to install the PerlIO::gzip module) (@INC contains: /etc/perl /usr/local/lib/perl/5.18.2 /usr/local/share/perl/5.18.2 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.18 /usr/share/perl/5.18 /usr/local/lib/site_perl .) at /usr/local/bin/geninfo line 62. BEGIN failed--compilation aborted at /usr/local/bin/geninfo line 62. The command "ci/codecov.sh" exited with 2. I see this failure has been happening for a year now affecting all PRs from that period. I think it's desirable to keep the CI-s green, especially if there is no huge potential of breaking it as the library has not seen much activity. I can't offer a solution myself, but it may ring a bell to maintainer or someone else who knows how to fix it. [1] https://github.com/boostorg/program_options/pull/92 Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

1 0

yabs: Yet Another Build System, seeking input/micro-team member
by degski 03 Mar '20

03 Mar '20

Hi All, Recently, I have started to get more and more dis-enchanted with Windows. The OS is being dumbed down every step of the way, while the internal complexity keeps going up. The latest and the most fun break-down to date of Windows was last week, the story is long, but in the end in came down to not being able to open the system-settings in the W10-style settings. The W7-style settings are also available, but the API's are overlapping but neither is a super-set of the other, so no way to fix the settings, because the settings themselves are broken (had something to do with display-drivers), way to go MS. In the meanwhile W10 is sorted again, but the whole lot is just getting increasingly fragile, while Fedora is getting increasingly solid (no bt-headphone stuttering, while connected to wifi and look at that brightness/crispness of that Full HD screen I have never seen before under W10!), the latter not upping complexity (2'001 packages to download and install to get from F30 to F31, but that's not complexity). I want to move to Fedora, and for now I'm dual-booting. This involves dumping VS in favor of VSCode (which is flat-packed for Fedora and compadres and is also available on OSX, so there is potentially a large audience), no acceptable other options (other than the one(s) VSCode is based on) are available AFAIKS, gnome-builder seems to have different goals from VS and it appears to be early days. VSCode seems (to me) to be like the best thing since sliced-bread, iff you are writing Python or Rust (Prolog works nicely as well), but C++ is only partially great, the language server works very nicely, code completion, good, but the build-system, proposed, is cumbersome. I would like VSCode to work more like VS, but without the complexity, the endless clicking, drop-down boxes etc etc. It comes down to writing json-files, which is good, but on a per project basis. Having to do this on a per project basis is a problem (that's going backwards from using project-templates in VS, I now in VS can create a new project in 3 seconds flat, and every detailed setting (clang and vc) is set correctly and how **I** want it, and I am running "Hello World!" (the default main in the template) in total 10 secs, this very handy to try things out). I don't want to go backwards. Therefore, I would like to do this on a repo-basis (the only one I have), with, iff required, another json in the project-folder (in the parent repo-folder), i.e.: /repos/ /repos/repo.json /repos/project-one/ /repos/project-one/project.json /repos/project-two/ /repos/project-two/project.json /repos/ ... I (want to) use vcpkg. I structure my projects always the same, all build systems (to my purpose) are basically an over-shoot on the one hand and overly fiddly on the other hand. The task at hand, build the .cpp files in the root of the project folder into one binary. The include files are either in the vcpkg/installed/.../include folder or in a sub-include-folder in the project. Libraries to link are either in vcpkg/installed/.../lib, or vcpkg/installed/.../debug/lib. We are not talking rocket-science here, I presume that many people have simple needs like this/me, or that if building (adopting this structure) becomes easy enough people would adopt such a structure. I would like to have one json to rule them all, and one json to either over-ride the defaults, or to add to the defaults, depending on whether the setting is defined in the repo.json. The repo.json might well be layered itself, to accommodate the various compilers, and/or configuration. For the moment nlohman's json seems perfectly adequate for the job, and it's certainly easy to use (and seems to just use std::maps in a clever way, so it's easy to follow what's going on). It's all about merging, fusing, overlaying those json's as needed (gonna be entertaining, making it smart), and pass that on to some generic API for building. So a new compiler would mean to just add a json-section, or a json-file, fill that with appropriate data (possibly nothing, iff the default-defaults are good), and it should work. The current way VSCode is setup, means that this imaginary build-system can be easily and readily included/used in VSCode (with more json). Yes, just like the working name indicates YABS, it must be as simple as possible, but no simpler. Any input is appreciated, but please refrain from arguing that BS-X does this better (and exists) or BS-Y has a large crowd of followers (and is used for a long period of time), that's water under the bridge, I will pursue this, just to see how far one can get pushing these initial ideas further. As usual my write-ups are a bit messy, I am learning I'm slightly dyslexic, sorry for the endless comma's. Thanks in advance for any ideas submitted. I would not mind partnering with somebody else, ya'll have a nice day, degski -- @systemdeg "We value your privacy, click here!" Sod off! - degski "Anyone who believes that exponential growth can go on forever in a finite world is either a madman or an economist" - Kenneth E. Boulding "Growth for the sake of growth is the ideology of the cancer cell" - Edward P. Abbey

1 0

Fwd: Boost.StaticString (formerly Boost.FixedString) is ready for release!
by degski 03 Mar '20

03 Mar '20

---------- Forwarded message --------- From: degski <degski(a)gmail.com> Date: Mon, 2 Mar 2020 at 23:14 Subject: Re: [boost] Boost.StaticString (formerly Boost.FixedString) is ready for release! To: Alexander Grund <alexander.grund(a)tu-dresden.de> On Mon, 2 Mar 2020 at 09:57, Alexander Grund <alexander.grund(a)tu-dresden.de> wrote: > Because if you use a signed type you have no compile-time guarantee that > the value is unsigned (using "type" and "value" to differentiate those 2). > You have indeed the guarantee that it is non-negative, compile-time, the problem is that, although you now know it is positive, you have lost (compile-time) any means of determining whether this value is correct (at run-time), while the guarantee at compile-time is just tautological. I don't understand really what you have against it, one can always use an int64_t, iff worried about int32_t overflow. Same as with a pointer: It can be NULL. > This value of null in itself is nothing special, it points at the top/bottom of the stack, there's nothing, so we hit UB. I don't think this is a good parallel. Pointers are not numbers, addition is meaningless. Adding up sizes is not meaningless, and we do it every day. Adding (or deducting) up a size and a pointer-difference is not meaningless either, that's why size needs to be signed. > If you want an interface where you want to guarantee at compile-time that > the value passed over an API is never NULL, you use e.g. a reference that > can never be NULL (or not_null<T>) > Herb's most recent post puts another angle on this: http://herbsutter.com/2020/02/23/references-simply/ . > > >> Didn't you argue in the mail before that there will never be anything of >> size 2^32 and hence even not anything like 2^64? How could you overflow >> that then? >> > > If you are manipulating (subtracting, adding differences) pointers, I > thought I wrote that. The pointers might be pointers into Virtual Memory > and can have any value [1, 2^56]. > > Not sure I understand that. Can we agree that a 64-bit unsigned type is > big enough to store any size of any container and hence no overflow is > possible? > Yes, certainly, what about a 63-bit value (the positive part of a signed 64-bit int), is that too small? ... signed type which may be an unsigned value. You'll have to check. > No, a signed value is never an unsigned value in disguise (that would result in overflow), the other way around, yes. I disagree. And as mentioned you can do things like `int difference = > int(obj.size()) - 1` anytime you want to do operations that are not fully > defined on unsigned types (as in: may result in values outside the range) > same as you can't to `int foo = sqrt(integer)` because you may get an > imaginary number (if sqrt could do that, but I think you get the gist). > C++ has questionable math's. How is that any different from `assert(a <= size); return size - a;`? > That's not what you wrote earlier. The you introduced a branch in release and made the function throw. > > all that because it upsets you that something that should not occur in > the first place in correct code can occur iff one is writing code that now > (as one observed it got negative) is known to have a bug. > > Again: How is that different to using a signed type for "size"? You have > exactly the same potential for bugs. You always have to make sure you stay > in your valid domain, and a negative size is outside of that valid domain. > Hence you got to check somewhere or use control flow to make sure this > doesn't happen. So no difference in signed vs unsigned size regarding that > The unsigned cannot overflow, that is not a bonus, that's a problem! > The use of unsigned is false security (actually no security) and serves > nothing. In the end, you still need to write correct code (so the signed > int's WON'T BE negative, there where they shouldn't be), but this practice > makes you're code less flexible, more verbose (the unavoidable casts add to > that) and probably slower than using signed. All that because of this > 'natural' way of looking at sizes. > > It serves as a contract on the API level: "This value is unsigned. > Period." > No, it says, if the value is out of the problem domain, don't worry, I'll cover it up (behind you're back so your app appears to be working, I make sure of that at compile-time). If the type was signed you'd need something else to enforce that the value > is unsigned. So yes you still need to write correct code and passing a > negative value to an API expecting an unsigned value is in any case a bug. > Of course, I never said, quite the opposite, that one not needs to write correct code. > Surely at runtime. How else could you guarantee that your value isn't > negative after you subtract something from it? It can be compile-time if > you only add something to it and ignore overflow but you already do that > when using signed values anyway. > > So, why does it need to be guaranteed positive at compile time? It just needs to be positive (size) at run-time, and as per above, you'll have to check. > But all this arguing doesn't solve much: What piece of code would actually > benefit from having a signed size? > I have already spelt out the reasons in an earlier post in this thread. > And not only the part where you request the size and use it, but also the > part where you give that size back to the object, so you'll need to ensure > an unsigned value. And yes `for(int i=0; i<int(obj.size())-1; i++)` is a > known example that would allow to get rid of the cast if the size was > signed. But again: That is due to operation used. `for(unsigned i=0; > i+1<obj.size(); i++)` is perfectly valid assuming no overflow > Thou shall not compare signed and unsigned values, my compilers insist and keep on telling me that. So now you need a cast to shut the thing up, and I would write: for ( int i = 0, back = static_cast<int> ( obj.size ( ) ) - 1; i < back; ++i ). I would like: for ( int i = 0, back = obj.size ( ) - 1; i < back; ++i ). This is my last post on the subject (bar new arguments). Thank you for the discussion. degski -- @systemdeg "We value your privacy, click here!" Sod off! - degski "Anyone who believes that exponential growth can go on forever in a finite world is either a madman or an economist" - Kenneth E. Boulding "Growth for the sake of growth is the ideology of the cancer cell" - Edward P. Abbey -- @systemdeg "We value your privacy, click here!" Sod off! - degski "Anyone who believes that exponential growth can go on forever in a finite world is either a madman or an economist" - Kenneth E. Boulding "Growth for the sake of growth is the ideology of the cancer cell" - Edward P. Abbey

2 2

Boost.StaticString (formerly Boost.FixedString) is ready for release!
by Krystian Stasiowski 02 Mar '20

02 Mar '20

Hi all, After some post-review polishing, Boost.StaticString is good to go for release! I have been in touch with the review manager, and everything has been checked over. Repo: https://github.com/sdkrystian/static_string Docs: https://sdkrystian.github.io/doc/static_string Here are some things that have been changed post-review: - Library has been renamed from Boost.FixedString to Boost.StaticString. Class template fixed_string has been renamed to basic_static_string, and aliases have been added for common character types, similar to std::string. - constexpr support to the fullest extent supported by available compilers has been added. - Functions that will not throw have been marked noexcept. - Moved to a single header configuration. - std::hash and boost::hash_value support has been added. - It has been decided that functions will throw on capacity overflow. - A specialization for when the capacity is 0 has been added that has no member. Additionally, the type of the member used to store the size of the string is now statically chosen to be the smallest possible width unsigned standard integer type that can hold all the needed size values. - operator+ has been implemented. - Floating point conversion support has been added to to_static_string/to_static_wstring. - Lots of bugs fixed. More behind the scenes, a bunch of optimizations have been added, taking advantage of the fact that the capacity is part of the type and known at compile time. Again, thank you all who participated in the review, and thank you Joaquin for managing it! Regards, Krystian Stasiowski

7 16

Projects for GSoC 2020
by David Bellot 01 Mar '20

01 Mar '20

Hi Boost community, so far we received a few good contributions for projects for GSoC 2020. The proposals are from our usual mentors but I'm surprised we don't have more projects in data structures and algorithms. Most of what we have concern numerical problems. It's great but I wish to see more diversity in the type of projects we propose. We want to attract the best students around the world and push toward new C++ standards and improvements of what we already have. Being a mentor is a great experience and on top of it, without too much effort, you will get someone of quality working for you during all the summer. The wiki page for projects is here: https://github.com/boostorg/wiki/wiki/Google-Summer-of-Code%3A-2020 Please come, edit and contribute. Cheers, David

2 2

What is the right way to close and clean boost::log
by JH 01 Mar '20

01 Mar '20

Hi, I built boost::log in my application library, it created boost::log::sinks::synchronous_sink<boost::log::sinks::text_file_backend> and close it by calling the boost::log::core::get()->remove_all_sinks() in destructor of the Log library, then one of my application link to my log library got Segmentation fault when it exited: Program received signal SIGSEGV, Segmentation fault. 0x00007ffff5fdd961 in boost::log::v2_mt_posix::core::remove_all_sinks() () from /usr/lib/x86_64-linux-gnu/libboost_log.so.1.65.1 If I add boost::log::core::get()->remove_all_sinks() in my application main before it return 0, the segmentation was gong, but it stuck. What is the proper right way to close and clean the boost::log? There is a blog suggested to run boost::log::core::get()->remove_all_sinks() when the main end, but that does not seem work. https://www.boost.org/doc/libs/1_62_0/libs/log/doc/html/log/rationale/why_c… Thank you. Kind regards, - jupiter

2 3

Cryptography for Boost.
by Mikhail Komarov 29 Feb '20

29 Feb '20

Hello! Cryptography for Boost. Again. It’s been some time since I’ve started developing so-called clean C++ cryptography implementation for my organization’s internal purposes. It was intended at first to be a cryptography framework fulfilling special cryptography schemes requirements, but eventually it has evolved into a full-featured suite, actively using and, sometimes, even based on Boost libraries. This turned out to be fine way to serve the Boost (and entire C++) community and to assemble a Boost version of a suite. So this letter is about wether there is still any interest in cryptography library for Boost and is there any sense to show the community what do I have for now? Sincerely yours, Mikhail Komarov nemo(a)nil.foundation

6 22

[gsoc] Encourage original ideas
by Mateusz Loskot 29 Feb '20

29 Feb '20

Hi, I noticed there may be confusion among students regarding project ideas. I sense, students (sometimes) fail to find the GSoC guides [1] ... So, based on the first paragraph of [1], I have updated our wiki [2] placing this note to students: "To any potential students, in addition to the list of project ideas, we don't discourage original ideas proposed by students. " If any mentors here disagree, please let me know and I will remove it (or move it to GIL, which I'm involved with as a mentor). [1] https://google.github.io/gsocguides/student/finding-the-right-project [2] https://github.com/boostorg/wiki/wiki/Google-Summer-of-Code:-2020 Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

2 2

Who's using Boost
by Adam Getchell 28 Feb '20

28 Feb '20

Name: CDT-plusplus [1] Company: University of California Davis CDT-plusplus generates ensembles of quantum spacetimes under the Causal Dynamical Triangulations program using the Metropolis-Hastings algorithm, with other algorithms planned. These ensembles allow calculations of quantities such as the spectral dimension and the overall transition amplitudes from the beginning until the end of time for a simulated universe of given dimension and volume. Many different research problems may be answered with these ensembles, including the existence of a Newtonian limit in CDT [2], renormalization group flow in CDT, [3] and spontaneous dimensional reduction in short distance quantum gravity. [4] Where Boost is used: 82 Boost libraries are used in conjunction with CGAL [5] in order to perform accurate geometric and combinatoric operations on 3 and 4-dimensional Delaunay triangulations. Boost.Optional and Boost.Outcome are used to assist in correctness guarantees for billions of moves permuting triangulations on simulations running for months on High Performance Compute clusters. [6] [1] https://github.com/acgetchell/CDT-plusplus <https://github.com/acgetchell/CDT-plusplus> [2] https://ui.adsabs.harvard.edu/abs/2015APS..APR.X7006G/abstract <https://ui.adsabs.harvard.edu/abs/2015APS..APR.X7006G/abstract> [3] https://arxiv.org/pdf/1405.4585.pdf <https://arxiv.org/pdf/1405.4585.pdf> [4] https://arxiv.org/pdf/0909.3329.pdf <https://arxiv.org/pdf/0909.3329.pdf> [5] https://www.cgal.org/ <https://www.cgal.org/> [6] https://www.hpc.ucdavis.edu/ <https://www.hpc.ucdavis.edu/> Let me know if further information is needed. -- Adam Getchell, M.S. https://adamgetchell.org <https://adamgetchell.org/>

1 0

GSoC, Boost C++ and Slack channel
by David Bellot 28 Feb '20

28 Feb '20

Hi Boost community, we have a dedicated channel on Slack for all the discussions regarding the Google Summer of Code. Please join us on cpplang.slack.com on the channell #boost-gsoc. Cheers, David

5 4

Re: [boost] Cryptography for Boost.
by Kenneth Porter 26 Feb '20

26 Feb '20

--On Friday, February 21, 2020 6:21 PM +0300 Mikhail Komarov via Boost <boost(a)lists.boost.org> wrote: > It's been some time since I've started developing so-called clean C++ > cryptography implementation for my organization's internal purposes. It > was intended at first to be a cryptography framework fulfilling special > cryptography schemes requirements, but eventually it has evolved into a > full-featured suite, actively using and, sometimes, even based on Boost > libraries. This turned out to be fine way to serve the Boost (and entire > C++) community and to assemble a Boost version of a suite. How does it fit in with openssl and SASL? I'd been contemplating dipping my toes into a Windows email client and openssl has a native Visual Studio port but I don't know of one for any SASL libraries. So the available open source email libraries tend to be *nix-oriented and have to be built with a ported *nix toolchain.

8 8

Start with Boost Multiprecision
by Tarun Lahrod 25 Feb '20

25 Feb '20

Hello, I am Tarun Lahrod. An engineering undergrad who's willing to contribute to Boost Multiprecision library in GSoC 2020. Please help me where to start from. Even in the code base from where should I start it. I am very much interested in taking Multiprecision as a project. Please help me start. Thank you. Tarun Lahrod Computer Science and Engineering (CSE) Bharati Vidyapeeth's College of Engineering, New Delhi Linked In: www.linkedin.com/in/tarun-lahrod GitHub: github.com/tarunlahrod

2 1

Related to Boost.Real Project Proposal
by Vikram Chundawat 25 Feb '20

25 Feb '20

Hey everyone, I am Vikram Singh Chundawat. I have a decent programming experience in c++. I am interested in Boost.Real project proposal and I want to work on this project in GSoC 2020. I have good knowledge of data structure and algorithms. I am going through all references and blogs suggested on project site currently. I will prefer giving the competency test after 8 march as I have my exams till then. It will be great if you have any suggestions regarding the prerequisites of this project, till then i will be going through the resources given on the project page. Thank you Regards Vikram Singh Chundawat

1 0

[website] 1.72 Boost.Config docs are missing
by Andrey Semashev 25 Feb '20

25 Feb '20

Hi, On this page: https://www.boost.org/doc/libs/1_72_0/ following Boost.Config link: https://www.boost.org/doc/libs/1_72_0/libs/config/config.htm leads to 404 Page Not Found. I believe the correct link should be: https://www.boost.org/doc/libs/1_72_0/libs/config/doc/html/index.html

2 5

[GSoC] My piece of advice to students
by Mateusz Loskot 24 Feb '20

24 Feb '20

Dear Student, You are planning to participate in GSoC and develop some new features for the Boost libraries. Awesome! So, you want to introduce yourself to the community as soon as possible. Awesome! However, before posting your first question to the Boost mailing list, please, do read the official GSoC student guides [0]. All of it. [0] https://google.github.io/gsocguides/student/ I also recommend to read through other resources dedicated for students, especially this one from Google [1], one from a former student [2] as well as advice from Boost GSoC former student Louis Dionne [3]. [1] https://opensource.googleblog.com/2011/03/dos-and-donts-of-google-summer-of… [2] https://medium.com/@akshikawijesundara/google-summer-of-code-dos-and-do-not… [3] https://github.com/boostorg/wiki/wiki/Google-Summer-of-Code%3A-Advice-From-… Once you get through the general GSoC materials, it's a good idea to start browsing Boost resources, from intro [3] through netiquette [4] to wiki [5]. On [3] and [5] you will find links to past and current project ideas for Boost libraries. Browse it, read it, and learn what kind of projects Boost community develops during GSoC. Start thinking about what interests you, which Boost library, which project, what you'd like to develop as GSoC student. [4] https://www.boost.org/community/gsoc.html [5] https://www.boost.org/community/policy.html [6] https://github.com/boostorg/wiki/wiki Meanwhile, it's a good idea to "Make First Contact" [0]. Subscribe to the boost (developers) and boost-user or library-specific mailing list at https://lists.boost.org join Boost channels on Slack at https://cppalliance.org/slack/ and start discussing your participation, project ideas, etc. Although the student guides [0] use the phrase about "communicating directly with potential mentors", it does NOT mean exchanging private e-mails with mentors asking "Are you interested to mentor me?". GSoC does not work this way. In my opinion, the word "directly" means to interact directly with the community where, obviously, potential mentors are members too. The Boost organization and mentors will have chance to select students and projects they wish to mentor during the selection process - a secret, you can learn about it from GSoC guides for mentors [8]. Yes, the selection is a competitive process. [8] https://google.github.io/gsocguides/mentor/selecting-a-student Next, start discussing project of your interest, start asking questions, investigate ways to contribute to Boost, start working on competency tests Mind you, competency test is Boost way to verify minimum necessary skills. I personally think Boost should also ask for a bug fix [2] explains: "Some organizations make it a must for you to fix a bug in their code base before submitting a proposal but some do not. Your chances are always high if you can fix a bug in the code." Submitting a pull request with a small feature is also a good idea, something to discuss with mentors/maintainers of library of your interest Pull requests will allow you to gain hands-on experience with workflow of peer reviews, continuous communication, addressing problems, testing your solution, using the infrastructure, being exposed to stress of 'annoying' requests from maintainers to fix this, tweak that... :-) For example, it worked well for Boost.GIL (you can PRs at https://github.com/boostorg/gil) "you have to go early even if you go to hell" [2] GSoC IS hard work! Make sure to start early, to take a proactive stance, to do your homework before you start asking questions, to expect no babysitting. Imagine the GSoC runs back in times when there is no StackOverflow, no web archives, no web search,... There really is no excuse for not searching the web first nowadays. Even compilers can do that! https://arxiv.org/abs/1906.11456 "To grow in life, be willing to suffer" ~David Goggins Have a great time during GSoC and good luck! Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

1 0

[static_string] Boost.StaticString (fka FixedString) accepted into Boost
by Joaquin M López Muñoz 24 Feb '20

24 Feb '20

Hello, Boost.StaticString (formerly known as FixedString) was accepted into Boost subject to the resolution of a number of issues I listed as priority 1: https://lists.boost.org/Archives/boost/2019/12/247820.php I've checked with the author that these issues have been already solved, so Boost.StaticString is good to go as an official Boost library (hopefully in time for shipping with 1.73). Thanks to Krystian and Vinnie for their work. Welcome Krystian to the dubious club of Boost authors :-) After the hard work needed to get the lib in, now comes the not less hard part of keeping it updated and generally healthy. Best regards, Joaquín M López Muñoz Review manager for candidate Boost.FixedString (now Boost.StaticString)

4 3

[gsoc2020][Boost.GIL] Advice needed regarding competency.
by sarthak 23 Feb '20

23 Feb '20

Hi everyone, I am Sarthak, a second year undergraduate engineering student. I wish to contribute to boost open source development during gsoc2020, specifically to Boost.GIL. But, I am not sure whether I am competent enough to contribute meaningfully to the organization (see the last point for precise question), I am hoping that someone here can give me advice regarding the same :) First, my reasons to contribute to boost - - I am reasonably proficient in programming (C++ included). I know I will be able to demonstrate it through programming competency test and all. In my day to day programming I normally do not use meta programming techniques which are prevalent in boost, this has made me more excited to work on boost because I will get to use these new fancy constructs :D - I just want to be part of open source community for once, sincerely. I have been using FOSS since forever and as a developer I have been longing to pay back, this is a good chance for me to do the same. - Why boost over any other organization? Largely because C++. I like the multi-resolution philosophy of C++ that you can get as close to machine as possible, or you can do high level manipulations through libraries and generics. More on that in proposal ;) - Why GIL (Project 1)? I want to learn image processing. Now this is where it gets tricky, the thing is that I am passionate about doing image processing, but I am not well versed with its theory. I have done a course on Signals and Systems in my university but that is pretty much it. This means that at the least I would need to learn image processing algorithms as we go on. Not that I hate it (on the contrary in fact) but that I am not really sure if it is possible at all for someone like me to contribute meaningfully during the few months of GSoC. I would love to hear from a mentor's experience of previous students on this. Honestly I would like to be rejected now if at all than after submitting my proposal with false hopes, or worse moving on with GSoC with such false hopes. I can also contribute to boost multiprecision in which I am substantially more experienced, but my first interest is in GIL and therefore if possible I would like to take the project in GIL. Any advice is appreciated. Thanks for reading. -- Sent from: http://boost.2283326.n4.nabble.com/Boost-Dev-f2600599.html

2 1

Fwd: Open Source Hackathon Mentor Invitation
by David Bellot 23 Feb '20

23 Feb '20

A word from our friends doing C++ at Hackillinois Outreach... ---------- Forwarded message --------- From: Advai Podduturi <advai.podduturi(a)hackillinois.org> Date: Wed, Feb 19, 2020 at 7:56 AM Subject: Open Source Hackathon Mentor Invitation To: <david.bellot(a)gmail.com> Hello, My name is Advai Podduturi and I’m reaching out on behalf of the HackIllinois Outreach team. HackIllinois is a 36-hour collegiate Open Source hackathon that takes place annually at the University of Illinois Urbana-Champaign. This year, it will be from February 28th - March 1st, 2020. Our mission is to introduce college students to Open Source, while giving back to the community. We strive to create a collaborative environment in which our attendees can learn from and work with developers to make their own contributions. In past years, we’ve had developers from prominent projects such as npm, Rust, and Apache come to mentor students from our pool of 900+ attendees. We’d love it if you could pass along this message to the Boost C++ community or any individuals you believe would be interested. We will provide meals throughout the event and can reimburse for travel and lodging up to a certain amount depending on where in the US people are coming from. More information on mentorship can be found at hackillinois.org/mentor <http://ec2-52-26-194-35.us-west-2.compute.amazonaws.com/x/d?c=6287904&l=b31…>. You can also visit opensource.hackillinois.org <http://ec2-52-26-194-35.us-west-2.compute.amazonaws.com/x/d?c=6287904&l=360…> to see what kinds of projects were represented at our event last year. Sincerely, Advai Podduturi -- Advai Podduturi HackIllinois 2020 | Outreach Team advai.podduturi(a)hackillinois.org | 630-765-4099

1 0

[GSoC20] logo
by Pranam Lashkari 22 Feb '20

22 Feb '20

Our logo on the GSoC page[1] looks a little pixelated and small fonts are not readable can we replace it? I have attached a boost logo file in the mail and a transparent logo can also be found here[2] [1]: https://summerofcode.withgoogle.com/organizations/6011808097239040/ [2]: https://de.wikipedia.org/wiki/Boost_(C%2B%2B-Bibliothek)#/media/File:Boost.… Thank you, Pranam Lashkari

3 2

Extend and optimize Boost.Multiprecision to higher precision of thousands of bits or more.
by Shubham Agarwal 21 Feb '20

21 Feb '20

Hello, I read the documentation for the Boots.Multiprecision and found it interesting, and I'M willing to work on this for Gsoc. could you please help me to get started.

2 1

Boost. Multiprecision:Multiprecision Big Number Types
by Ashmita Singh 21 Feb '20

21 Feb '20

Hello everyone, I explored about this project and found it interesting and i am interested to work on it for GSOC 2020.Can someone please help me out in getting started? Thank you Ashmita Singh

2 1

GSOC2020
by Damian Vicino 20 Feb '20

20 Feb '20

Hi everyone, Boost is once again in Google summer of code! https://summerofcode.withgoogle.com/organizations/6011808097239040/ Thanks David and everyone participating in the proposal for this year.

2 1

Starting contribution at boost
by Ashmita Singh 14 Feb '20

14 Feb '20

Hello everyone, I am a beginner in open source contribution.I want to start my career in open source contribution with boost organisation.So please help me out with a project to which i can contribute.My preferred language is C++. Regards.

3 2

Boost geometry
by Shiko 13 Feb '20

13 Feb '20

Hello everyone. My name is Ahmed ElShreif and I'm a newcomer to the Boost community. I am willing to apply this year in GSoC with boost. I was accepted in LibreOffice in GSoC'19. I read the Projects and it's really interesting for me. But I have some questions: why this projects exist also in 2019 potential projects? Can I get help in finding some easy issues to solve now to get familiar with the library more and become ready more for the project? Thanks Ahmed ElShreif -- Sent from: http://boost.2283326.n4.nabble.com/Boost-Dev-f2600599.html

2 1

Boost.Astronomy
by Eslam Tarek 13 Feb '20

13 Feb '20

Hello everyone. My name is Eslam Tarek and I'm a newcomer to the Boost community. I am willing to apply this year in GSoC with boost, But Ihave some questions: why this projects exist also in 2019 potential projects? Can I get help in finding some easy issues to solve now to get familiar with the library more and become ready more for the project? Regards, Eslam Tarek -- Sent from: http://boost.2283326.n4.nabble.com/Boost-Dev-f2600599.html

2 1

Boost.Astronomy
by Eslam Tarek 12 Feb '20

12 Feb '20

Hello everyone. My name is Eslam Tarek and I'm a newcomer to the Boost community. I am willing to apply this year in GSoC with boost, I read the Projects and it's really interesting for me. But I have some questions: why this projects exist also in 2019 potential projects? Can I get help in finding some easy issues to solve now to get familiar with the library more and become ready more for the project? Regards, Eslam Tarek -- Sent from: http://boost.2283326.n4.nabble.com/Boost-Dev-f2600599.html

1 0

If one specifies a cxxstd-dialect, one must also specify the cxxstd
by pbristow＠hetp.u-net.com 12 Feb '20

12 Feb '20

https://boostorg.github.io/build/manual/develop/index.html#bbv2.overview.bu… s.features says 5.3. Builtin features cxxstd Allowed values: 98, 03, 0x, 11, 1y, 14, 1z, 17, 2a, latest. cxxstd-dialect Allowed values: iso, gnu, ms. So these work as expected toolset=gcc cxxstd=2a cxxstd-dialect=gnu is OK toolset=gcc-9.2.0 cxxstd=2a cxxstd-dialect=gnu is OK too But if I do NOT specify the cxxstd version - just toolset=gcc cxxstd-dialect=gnu for example: boost\libs\multiprecision\example>b2 float128_snips toolset=gcc-8.1.0 cxxstd-dialect=gnu address-model=64 release > .mp_float128_snips_gcc810_14_gnu.log Iboost/tools/build/src/build\feature.jam:1020: in feature.compress-subproperties from module feature error: assertion failure: [ set.equal "<cxxstd-dialect>gnu" "<toolset-gcc:version>8.1.0" : "<toolset-gcc:version>8.1.0" ] error: Expected: [ "true" ] error: Got: [ ] which had be puzzled for a while. Probably the even more common case of only having one compiler, say gcc, installed, and so not specifying toolset at all, confusingly behaves the same way? This is a perfectly reasonable behaviour, but this requirement might helpfully be documented. Or this more subtle than I understand? Thanks Paul

2 4

[docs] Eclipse Foundation standardising AsciiDoc
by Mateusz Loskot 12 Feb '20

12 Feb '20

FYI ---------- Forwarded message --------- From: Mateusz Loskot <mateusz(a)loskot.net> Date: Wed, 12 Feb 2020 at 09:21 Subject: Eclipse Foundation standardising AsciiDoc To: <boost-docs(a)lists.boost.org> Hi, Number of Boost libraries/tools use AsciiDoc as preferred documentation format, so I think this initiative may be of interest here https://www.eclipse.org/lists/asciidoc-wg/msg00001.html https://www.eclipse.org/lists/asciidoc-wg/msg00002.html Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

1 0

[Boost.Real] Base Change Not Incorporated in Initializer List Constructors
by Jai . 12 Feb '20

12 Feb '20

The base change done during GSoC 2019 seems to have not been incorporated in the initializer list constructors, thus giving incorrect results. Regards, Jai

2 2

No release in calendar for 2020?
by Mateusz Loskot 10 Feb '20

10 Feb '20

Hi, Am I seeing it right that nothing has been scheduled for 2020 at https://www.boost.org/development/index.html or is there a problem with the calendar (or my browser)? What is the schedule of the Boost 1.73.0 ? Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

4 5