- Boost - lists.preview.boost.org

[histogram] Objections against switch to C++14?
by Hans Dembinski 26 Oct '18

26 Oct '18

Dear reviewers of boost.histogram, thank you again for your reviews. I am currently working on the issues raised during the review and some of the requested features would be easier to implement when the library standard is raised from C++11 to C++14. This only affects the implementation side, not the user side. It would make my life easier and the implementation code more readable, because I can emulate `if constexpr` using in-place generic lambdas instead of out-of-place functors in the detail namespace. To make the library more user-friendly, I have to do more and more of these emulated `if constexpr`. Do you object against raising the requirement from C++11 to C++14 for the implementation of boost.histogram? Best regards, Hans

3 3

[smart_ptr] sharable_ptr any interest
by Marc Pawlowsky 26 Oct '18

26 Oct '18

I am working on a idea for a smart pointer called sharable_ptr. A cross between a unique_ptr and a shared_ptr. A sharable pointer has a single definite owner like a unique_ptr, and can be shared to other users similar to shared_ptr as a borrowed_ptr. However unlike a shared_ptr it is an error if the contents of the sharable_ptr go out of scope, by destruction or being reset or assigned, if there are still instances of a borrowed_ptr that reference it. The work is in its infancy at https://github.com/marcpawl/smart_ptr/tree/feature/leased_ptr with the documentation at https://github.com/marcpawl/smart_ptr/blob/feature/leased_ptr/doc/smart_ptr… >From the documentation: Motivation sharable_ptr, and its cohorts: sharable_ref, borrowed_ptr, and borrowed_ref are to help close the raw dangling pointer problem. Along with unique_ptr and shared_ptr, the number of C++ objects that will retain a raw pointer can be reduced. It will allow for easier reasoning of the lifespan of objects, and help catch errors where an object is referenced after it no longer should be. <https://github.com/marcpawl/smart_ptr/blob/feature/leased_ptr/doc/smart_ptr…> Analogy Marc owns a cottage on the lake and is willing to share it with his friends and family. He tells them to drop by anytime they want, even when he is not there. Amanda uses the cottage on a regular basis. Amanda also lets her friend Ava use it. Unfortunately due to a change in financial circumstances Marc has to sell the cottage. At this point neither Marc nor Amanda may use the cottage any more. In C++ terms, Marc has a sharable_ptr<Cottage>. When Amanda is at the cottage she has a borrowed_ptr<Cottage>, which she destroys when she leaves the cottage. When Amanda lets Ava use the cottage Ava gets a copy of the borrowed_ptr. Amanda and Ava must destroy their pointers prior to Marc releasing his. It would be an error for Amanda or Ava to retain a borrowed_ptr to the cottage even if she does not use it. Equivalent to retaining a copy of the keys. ## Alternatives Instead of using `sharable_ptr` and `borrowed_ptr`, you could use `shared_ptr` and `weak_ptr`. The error detection for a dangling pointer gets pushed to when the `weak_ptr` is locked to a `shared_ptr`, instead of when the owned object is freed. A possible advantage is that if the `weak_ptr` is not used then there is no error. The disadvantage is the code may have progressed quite a way before it is realized the referenced object no longer exists. Is there interest in this idea, should I keep working on it? I have so far only been working on Mac clang basement:smart_ptr marcpawl$ clang -v Apple LLVM version 10.0.0 (clang-1000.10.44.2) Target: x86_64-apple-darwin17.7.0 Thread model: posix Thanks Marc Pawlowsky

2 1

interest in a flag library
by Marc Pawlowsky 26 Oct '18

26 Oct '18

You should take a look at https://www.youtube.com/watch?v=1fwbG5TyI18 CPPCON 2018 session https://cppcon2018.sched.com/event/FnKQ/avoiding-disasters-with-strongly-ty… Arno Lepisk <https://cppcon2018.sched.com/speaker/arno_lepisk> Avoiding Disasters with Strongly Typed C++ I think the technique he describes is what you are looking for.

1 0

[c++ question] detecting reference to temporaries
by Raffi Enficiaud 25 Oct '18

25 Oct '18

I have a stupid question related to a bug in boost.test. A piece of code is doing something like: const value& get() { return *internal_iterator; // can be a ref or not to value or another type } The fix is trivial, *but* I want to test it. Is there any technique that would let me test for reference to temporaries? The only option I see would be to promote compiler warnings into error, but maybe there is something there? Thanks, Raffi (complete example here: https://github.com/boostorg/test/blob/90d577a620e008417af79f5caa25e701eef95… )

2 1

[boost.random] Library maintenance
by Nikita Kniazev 25 Oct '18

25 Oct '18

Random library has multiple PRs that hang for a long time already. Some of them address warnings that poisons its usage and maintenance of other libraries. Please consider placing Random under CMT. https://github.com/boostorg/random/pull/35 https://github.com/boostorg/random/pull/26 https://github.com/boostorg/random/pull/31

1 0

Re: [boost] [c++ question] detecting reference to temporaries
by Nikita Kniazev 25 Oct '18

25 Oct '18

> Is there any technique that would let me test for reference to > temporaries? The only option I see would be to promote compiler warnings > into error, but maybe there is something there? AddressSanitizer with -fsanitize-address-use-after-scope https://github.com/google/sanitizers/wiki/AddressSanitizerUseAfterScope

1 0

Boost 2 and build2
by Boris Kolpackov 25 Oct '18

25 Oct '18

I've noticed the discussion on Boost 2 where build2 was mentioned as one of the potential build systems. So I wanted to say that we would be happy to help on our side with any questions, missing features (like exporting targets in a CMake-compatible manner, as mentioned by Niall), etc. Also a couple of additional points about build2 that I think could be relevant to Boost 2 (or 1): 1. It is currently the only build system that I am aware of that has support for C++ modules (currently TS but we are tracking the standardization/implementation progress closely; see [1] for details). Now that modules are likely to be in C++20 I think this should be at least a consideration for Boost 2. 2. We have a public CI service[2] for open source project that I think could be quite useful to Boost. It might not currently be as extensive as Boost's (see [3] for the currently offered build configurations) but we are continuously expanding it plus Boost can run its own build machines with additional configurations. 3. build2 comes with a package manager[4] and Boost could take advantage of that by either publishing to cppget.org or running its own package repository (or both). I am happy to answer any questions here (if appropriate, of course), on the build2 mailing list[5], or on the #build2 slack channel[6]. [1] https://build2.org/build2/doc/build2-build-system-manual.xhtml#cxx-modules [2] https://ci.cppget.org [3] https://ci.cppget.org/?build-configs [4] https://build2.org/build2-toolchain/doc/build2-toolchain-intro.xhtml#guide-… [5] https://lists.build2.org/ [6] https://cpplang.slack.com/app_redirect?channel=build2

1 0

The future and present of Boost
by Robert Ramey 25 Oct '18

25 Oct '18

This was on another thread. Someone mentioned that it should be on it's own thread so here it is (slightly amended for context). For some time I've been concerned about the future of Boost as an organization. Here are the concerns I have: a) With C++11, the standards committee accepted a large portion of Boost into the standard. This left it unclear as to what the future value of Boost to C++ might be. b) The standards committee has ramped up it's efforts to include library proposals directly into the standard - thus side stepping the traditional requirement of "standardizing established practice". So this has left Boost, which helps to evolve "establish practice" outside of the development of the C++. An example of this has been the Ranges library which as been designed and developed totally within confines of the C++ standards committee. This effectively marginalizes Boost - that is, makes it less relevant and important. c) This effort by the committee is basically failing. It's creating the possibility that C++ will evolve into an ever larger and incomprehensible bag of disjoint features than it already is. It makes it much harder to learn C++. This puts C++ on a slow train to oblivion. This is not unusual with successful projects which expand their scope - as the committee has done. It's especially common for organizations run as a committee. Think large corporations: Kodak, Sears, All government organizations, universities - etc. All one has to do to see this is look at the papers list for the San Diego meeting. Also look at P0977r0. Consider that it take the committee 10 years for a proposal to evolve into something that can be delivered to users. It even takes 10 years to include something which is already in use by 100's of thousands of programmers - ASIO. Of course the C++ committee won't address the situation. Committees don't do that. They think they can remain relevant by expanding scope. and lo and behold, now they want to expand scope again to include tooling. Wake up and smell the coffee people. Learn to prioritize and limit the scope of your actions to that which only you can do. This would be better for C++. Do less - get more done! d) Boost can accept, review and deliver a new library in a year. Hence Boost has a reason to continue and exist. But Boost is also a committee - albeit a better designed one. It has to evolve as well. I think it can evolve if we continue to work on the stuff we've been successful at while at the same time experimenting with new ideas. Robert Ramey

23 70

warning: non-free usage requirements <threading>multi ignored
by blubee blubeeme 25 Oct '18

25 Oct '18

Hello I am trying to build boost from git clone I run bootstrap.sh with these flags ```shell ./bootstrap.sh \ --prefix=/usr/local \ --with-toolset=clang \ --with-icu=/usr/local \ --with-python=python27 \ ``` After boostrapping I append ```shell "using mpi ;" >> ./project-config.jam ``` There's two issues with that 1)icu isn't found even though icu headers are in /usr/local/unicode/ 2)I get this this warning ```error warning: non-free usage requirements <threading>multi ignored warning: in main-target boost_mpi_python at libs/mpi/build/Jamfile.v2:144 ``` Which I tracked down to this issue: http://boost.2283326.n4.nabble.com/explicitly-specified-values-of-non-free-… That thread leaves the issue unresolved and just throws a warning instead of failing. ```shell ./bjam \ --prefix=/usr/local \ --layout=system \ -d4 \ --toolset=clang \ --build-dir=./build \ --stagedir=/opt/boost \ -j4 \ include=/usr/local/include/unicode \ link=shared \ threading=multi \ stage \ ``` bjam output ```shell Performing configuration checks - default address-model : 64-bit - default architecture : x86 - symlinks supported : yes - C++11 mutex : yes - lockfree boost::atomic_flag : no - Boost.Config Feature Check: cxx11_auto_declarations : yes - Boost.Config Feature Check: cxx11_constexpr : yes - Boost.Config Feature Check: cxx11_defaulted_functions : yes - Boost.Config Feature Check: cxx11_final : yes - Boost.Config Feature Check: cxx11_hdr_mutex : yes - Boost.Config Feature Check: cxx11_hdr_tuple : yes - Boost.Config Feature Check: cxx11_lambdas : yes - Boost.Config Feature Check: cxx11_noexcept : yes - Boost.Config Feature Check: cxx11_nullptr : yes - Boost.Config Feature Check: cxx11_rvalue_references : yes - Boost.Config Feature Check: cxx11_template_aliases : yes - Boost.Config Feature Check: cxx11_thread_local : yes - Boost.Config Feature Check: cxx11_variadic_templates : yes - has_icu builds : yes warning: non-free usage requirements <threading>multi ignored warning: in main-target mpi at project-config.jam:42 warning: non-free usage requirements <threading>multi ignored warning: in main-target boost_mpi at libs/mpi/build/Jamfile.v2:119 - zlib : yes - bzip2 : yes - lzma : yes - zstd : no - iconv (libc) : yes - icu : no - icu (lib64) : no - xlocale supported : yes - native-atomic-int32-supported : yes - native-syslog-supported : yes - pthread-supports-robust-mutexes : yes - compiler-supports-ssse3 : yes - compiler-supports-avx2 : yes - gcc visibility : yes - long double support : no warning: non-free usage requirements <threading>multi ignored warning: in main-target boost_mpi_python at libs/mpi/build/Jamfile.v2:144 - libbacktrace builds : no - addr2line builds : yes - WinDbg builds : no - WinDbgCached builds : no - BOOST_COMP_GNUC >= 4.3.0 : no Component configuration: - atomic : building - chrono : building - container : building - context : building - contract : building - coroutine : building - date_time : building - exception : building - fiber : building - filesystem : building - graph : building - graph_parallel : building - iostreams : building - locale : building - log : building - math : building - mpi : building - program_options : building - python : building - random : building - regex : building - serialization : building - stacktrace : building - system : building - test : building - thread : building - timer : building - type_erasure : building - wave : building ``` I do have a working installation of openmpi installed in /usr/local and mpicxx is in my path from following the directions here: https://www.boost.org/doc/libs/1_64_0/doc/html/mpi/getting_started.html#mpi… in the end the build errors out ```shell 0.003049 sec system; 0.000000 sec user; 3.078255 sec clock Using shell: /bin/sh -c argv[0] = '/bin/sh' argv[1] = '-c' argv[2] = ' ln -f -s 'libboost_wave.so.1.69.0' '/wrkdirs/usr/ports/devel/boost-devel/work/stage/lib/libboost_wave.so' ' ln-UNIX /wrkdirs/usr/ports/devel/boost-devel/work/stage/lib/libboost_wave.so ln -f -s 'libboost_wave.so.1.69.0' '/wrkdirs/usr/ports/devel/boost-devel/work/stage/lib/libboost_wave.so' 0.001905 sec system; 0.000000 sec user; 1.957884 sec clock ...failed updating 86 targets... ...skipped 17 targets... ...updated 1147 targets... *** [do-build] Error code 1 make: stopped in /usr/ports/devel/boost-devel 1 error ``` two questions: 1) How do I solve the non-free usage requirements warning 2) Why isn't icu being picked up? github issue:: https://github.com/boostorg/boost/issues/210

1 0

Library devs only: Boost v2.x distro design questions
by Niall Douglas 24 Oct '18

24 Oct '18

Splitting this off from the other thread, can I get feedback from Boost library maintainers ONLY. Not users, not non-maintainers. Q0: Are you willing to do the work to adapt your library for any Boost v2.x distro if it were to happen? Q1: Would you prefer a new, separate Boost v2.x distro in parallel to the v1.x distro, or to keep everything within one v1.x distro? Q2: Would you be intending to keep your library inside Boost v1.x, move it exclusively to Boost v2.x, or have it exist in both Boost v1.x and v2.x but with different defaults configured? Also, would the version in v1.x be hard forked from any v2.x edition i.e. the v1.x edition would get orphaned? Q3: What C++ standard should Boost v2.x's master build system be defaulted to? C++ 11, 14, 17 or 20? Q4: Should Boost v2.x use a boost2 namespace, or namespace boost { inline namespace v2 { }}? (This affects whether Boost v2 and v1 editions of your library can be used within the same translation unit) Q5: What master buildsystem should Boost v2.x use? Boost.Build, cmake, Build2, something else? Q6: Should Boost v2.x's libraries auto integrate individually into some package manager? If so, which ones do you intend to support? Q7: Should Boost v2.x have official release versions done by release managers, or should it be a rolling release of "whatever last passed the CI @ 100%"? Note that you can have this, and have official release versions of "especially known good" editions too. Q8: Should Boost v2.x use a local HTML server to serve documentation, and the static HTML docs be dispensed with as a requirement? Q9: What are your feelings towards the use of Python to script infrastructure and tooling in any Boost v2.x? For example, Python to run a local HTML server to serve documentation locally, or Python to build a release etc Q10: What parts of core Boost are you utterly dependent upon, and would absolutely need ported to any Boost v2.x as no STL alternatives exist? I could go on, but let's stop there for now. Niall

2 4

Re: [boost] [release] 1.69.0 deadline for new libraries approaching
by Peter Dimov 24 Oct '18

24 Oct '18

> Robert Ramey wrote: > > On 10/22/18 10:19 AM, Peter Dimov via Boost wrote: > > > Marshall Clow wrote: > > > > > >> * 24-Oct: Boost 1.69.0 closed for new libraries and breaking changes > > > > > > OK... do we want CMake config files installed by 1.69 or not, then? > > > > I'd like to know this as well. If so, I presume that we can consider > > the Boost/CMake issues resolved and we can just move on from this? > > I doubt it. The CMake issue is much bigger than this. To expand on that: The Boost/CMake issues concern four scenarios: 1. CMake users who want to use a pre-built Boost from CMake, after installing it either with `b2 install`, as usual, or via some other mechanism; 2. CMake users who want to use Boost (or an individual Boost library) from CMake without building it with b2 and installing it, but as a subproject, built by CMake; 3. Building and installing Boost with CMake, replacing the current Boost.Build building/installing infrastructure; 4. Testing Boost with CMake, replacing the current Boost.Build testing infrastructure. Installing CMake config files as part of `b2 install` falls into scenario number 1. Boost is still built with Boost.Build as always, it's just that in addition to libboost_foo.a, the user also gets libboost_foo.cmake, which allows him to do `find_package(boost_foo)` from his CMakeLists.txt file. Nothing more than that. This doesn't affect, doesn't target, and doesn't address, scenarios 2-4 at all.

8 25

boost-cmake and quickbook
by Raffi Enficiaud 23 Oct '18

23 Oct '18

On 23.10.18 21:29, Edward Diener via Boost wrote: > On 10/23/2018 2:36 PM, Robert Ramey via Boost wrote: >> On 10/23/18 11:17 AM, Peter Dimov via Boost wrote: >>> Robert Ramey wrote: >>> >>>> And I place the html and pdf versions into the repo so users don't have to build it. >>> >>> Placing the .html/pdf files into the repo is one - unquestionably modular - way to do it, but it does have its downsides. >> >> Both true. >> >> downside >> - "wastes" a lot of space >> - redundant - docs could get out sync with the code. >> >> >> upside >> >> - current documentation is always available to the user. In the two libraries of mine - documentation is an important part and I don't think the either would be usable without them. >> - only needs to be built on one machine no hassle for users >> - document build doesn't have to be "portable" >> - potential users can easily browse the documentation before they clone/download the package. This works well with github. I think this is very valuable - especialy for safe_numerics which most people don't actually see the need for. Call it a sales tool. > > I am sure you know that github already has support for viewing the documentation via the github io mechanism, so your last '-' item is not really applicable to your argument. > > My argument is simply that lots and lots of libraries use Boost Build to generate the docs, very often through the quickbook -> docbook -> pdf/html mechanism and unless we are going to continue to do it that way when Boost uses CMake we will eventually need a way to duplicate the Boost Build mechanism for creating the docs in CMake. > > Nonetheless I continue to believe that the move to CMake by Boost should be achieved in small steps, so that we can assure success in one step for all libraries before we even think about attempting the next. I still have the same fear that trying to accomplish everything at one time will mean that nothing really will ever get done. I only added item 5) to Peter's list because that is something we will eventually have to decide about. [sorry for multiple posting] Talking about small steps, feel free to copy paste this wherever you need it: https://github.com/raffienficiaud/boost-cmake/blob/master/boost-cmake/quick… I compiled Boost.Test documentation with this, this is fully cmake and it does the catalog generation on the fly. This is a small step, usually this is where collaboration starts, since I do not have all the knowledge of quickbook/docbook nor the bandwidth ATM. *But* if somebody is kind enough to assist me on this, in particular explaining me if we would want --stringparam chunk.first.sections "1" --stringparam chunk.section.depth "4" --stringparam generate.section.toc.level "3" --stringparam html.stylesheet "boostbook.css" --stringparam toc.max.depth "3" --stringparam toc.section.depth "10" to be exposed when compiling a documentation, or how to run the doxygen part, then porting things to cmake will be definitely faster. Raffi _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

[preprocessor] vc++ using the experimental preprocessor
by Edward Diener 23 Oct '18

23 Oct '18

I have updated on the 'develop' branch Boost PP code that will use the vc++ C++ standard conforming preprocessor in VS2017 15.8 and above, as explained at https://blogs.msdn.microsoft.com/vcblog/2018/07/06/msvc-preprocessor-progre…. The code essentially treats vc++ in this mode as a strictly standard conforming preprocessor. There is the switch of /experimental:preprocessor which turns on the new preprocessor for the end-user, else the normal non-standard vc++ preprocessor is still the current default. BTW I tried to post a comment to the link above, explaining that the test posted in the article for the new preprocessor was wrong, but for whatever reason it never was actually posted as a comment. Nonetheless I got it right for myself in the Boost PP code in its config.hpp, so I am not going to worry about the fact that others may use the erroneous test in the article in their code. The change I made to Boost PP does not affect any other compiler, including vc++ in normal non-standard preprocessor mode. I have no idea if any regression tests for msvc-14.1 are made with this /experimental:preprocessor switch, but I will wait for 'develop' to cycle through before merging to 'master' in Boost PP. My preprocessor tests show four failures with the new vc++ preprocessor. Two of the failures are based on the fact that the test code expects a macro called with the wrong number of arguments to produce a compiler error and not just a warning. But since I have been told, vis-a-vis the same situation occurring for the Oracle C ++ compiler, that compilers are allowed under the C++ standard to produce a warning and just "chug" on, even if producing macro output that is certainly not what the programmer intended, rather than produce a compilation error maybe I just need to eliminate those tests, as important as I think they are. The other two failures are with the BOOST_PP_ITERATE macro and corresponding structures. The new preprocessor also erroneously continues to give a number of argument mismatch warnings in cases where it does not really exist, similar to the non-standard preprocessor, but since it "chugs" on despite the false warnings it ends up producing the correct output anyway. I have already posted a bug report about the fact that the new preprocessor gives a warning and continues when a macro is called with the wrong number of arguments. The other problem with BOOST_PP_ITERATE will be harder to determine because the iterate mechanism in Boost PP is fairly complex and I will need to figure out what is causing it and reduce the failure to a much simpler form in order to report it. As far as the compiler warnings of the wrong number of arguments when they do not exist, again I will have to try and figure out why and report the bug(s) to Microsoft. If anyone wants to try this out on Boost PP 'develop' feel free to do so. You will need to invoke the msvc-14.1 toolset in Boost Build with the /experimental:preprocessor switch and you will need to upgrade VS2017 to 15.8 or above. You can tell whether you have succeeded invoking the Boost PP tests with the new preprocessor by looking at the run output of the config_info test. If the BOOST_PP_CONFIG_FLAGS() is 0x0001 it is the new preprocessor, else it is the default non-standard preprocessor (0x0004).

6 13

Invitation to join the C++ chat community!
by Vinnie Falco 23 Oct '18

23 Oct '18

All: Hi there. I would like to personally invite all of the Boost authors, participants on the mailing list, and interested parties to join the most popular C++ Slack workspace, where many lively technical discussions related to C++ and its ecosystem take place. There are channels for everyone, especially the #boost channel, but also channels for WG21 committee discussions such as #future_standard and #wg21. There's even an #sg14 ! You can learn more and request a free invitation here: <http://slack.cpp.al> This workspace is sponsored by the C++ Alliance, a non-profit organization which promotes and advances the C++ language and provides educational resources. Find out more about the Alliance here: <http://cpp.al> Regards

3 5

Development Calendar is empty
by James E. King III 23 Oct '18

23 Oct '18

When is the next freeze or release? https://www.boost.org/development/index.html - Jim

5 5

[histogram] Finalising version for submission
by Hans Dembinski 22 Oct '18

22 Oct '18

Hi all, I have a general question regarding the submission process on how to deal with extensions of the library. I am currently working on the points raised in the review. Clearly, the bugs need to be fixed and the documentation improved where it was lacking. So the procedure is clear in that regard, but the final version to be included in Boost will also have more features, the main ones are: - support for profiles and in general arbitrary accumulators as bin "counter" types - in particular any Boost.Accumulator - allow arbitrary metadata (or no metadata at all) to be associated with the builtin axes types, instead of just supporting a string label (the metadata type will be a template parameter) - use axis types through a traits-interface to make adding custom axis types really easy (a minimal axis only needs to implement `int operator()(something) const` and `unsigned size() const`, everything else is optional) - use storage types through a traits-interface to allow arbitrary STL and Boost containers as storage backends - add a support library for typical calculations done with histograms, like reducing a high-dimensional histogram to a lower-dimensional histogram, shrink an axis, etc - growing axes that increase the number of bins while the histogram is filled I started working on these features and switching to C++14 would simplify the implementation a lot, thanks to generic lambdas and return type deduction. So I would like to raise the requirement for the final library from C++11 to C++14. Since these are substantial changes, is another formal review of the final version required? In any case, I will request informal feedback on the final version on the list before histogram is released with Boost for the first time. Best regards, Hans

5 10

[all] Hidden visibility is on by deafult
by Antony Polukhin 22 Oct '18

22 Oct '18

Good news everyone! I'd like to announce that now Boost libraries are build with hidden visibility by deafult. Many thanks to Andrey Semashev for providing the required patches and PR to fix some builds, and to Glen Fernandes for merging. Separate thanks to all the Boosters who reported/fixed visibility related issues.

3 2

[review][histogram] Histogram Review Results
by Mateusz Loskot 22 Oct '18

22 Oct '18

Hi Everyone, Please, welcome the Histogram library to the Boost collection! Thank you Hans for submitting a high-quality library for review. Thank you to the reviewers as well as those who just exchanged their comments on numerous aspects of the library and participated in the fruitful discussions. Among reviewers, we can recognise veteran Boost contributors and authors as well as experts in the fields of statistics, raster analysis, including authors of histogram-oriented software packages. ---------------------------------------- Official reviews and votes: ---------------------------------------- 1. Klemens David Morgenstern - ACCEPT 2. Jim Pivarski (off-list) - ACCEPT 3. Bjorn Reese - ACCEPT conditionally 4. Steven Watanabe - ACCEPT conditionally 5. Alex Hagen-Zanker - ACCEPT Non-review participations: 1. Andrea Bocci (off-list) 2. degski 3. Glen Fernandes (off-list) 4. Gavin Lambert 5. Seth 6. Mateusz Loskot ---------------------------------------- Acceptance conditions ---------------------------------------- Two reviews stated conditions which are important fulfilled: Bjorn Reese - Reference documentation is finalized Steven Watanabe - Various exception safety and memory issues must be fixed. - The reference documentation must be completed. Specifically, various preconditions, requirements, and assumptions must be made explicit. I believe those are not controversial at all and Hans is also interested in addressing those requests. ---------------------------------------- Concerns and comments ---------------------------------------- Jim Pivarski mentioned importance of profile plots as fundamental enough that they should be part of the feature set. In short term, the profile plots can be implemented as a new storage type, using the extension capabilities. Similarly, some concurrent applications would need atomic-valued bins, but these, too, can be storage types. Bjorn Reese pointed out some aspects of the design that makes the library not work very well with STL algorithms. Bjorn strongly recommended that the default storage policy is changed to remove some of those limitations. Steven Watanabe provided Hans with large number of very detailed comments and fixes (eg. do not call destructor which has been fixed), suggestions how to improve run-fail tests and serialization tests. Alex Hagen-Zanker commented that range-based for-loops support could be improved, suggested to provide separate ranges or views for certain histogram access scenarios. Another important theme of Alex' review was Histogram applicability for moving window type analysis. Then, Alex requested clarification on choosing variance based on the Poisson distribution instead of the binomial distribution. degski suggested to look for some "low hanging fruits" in C++14 and/or C++17, the library could potentially benefit from, pushing the 'modern C++' trait of the library even further. Gavin Lambert suggested to allow use of quantity types like Boost.Units. Glen Fernandes mentioned he would raise allocator model support issues or relaxing the requirement that the pointer must be a raw pointer of type value_type*. Glen mentioned he may even be available to help. Hans has already addressed many of the suggestions and issues or planned related features for future releases of the library. Issues resulting from the feedback received during the review can be tracked and further discussed on GitHub, labelled with boost-review: https://github.com/HDembinski/histogram/labels/boost-review ---------------------------------------- The Upsides ---------------------------------------- There were lots of great things said about the Histogram library: - design: excellent, clean, simple and extensible in principle - useful and well-designed features - geared towards readability and performance - very good documentation ---------------------------------------- Final Thoughts ---------------------------------------- Reviewers are worth their weight in gold nowadays. Once again, I'd like to thank all participants for great amount of quality feedback that already led to important improvements in the Histogram library in very timely manner - thank you Hans! The Histogram library is a valuable addition to Boost. Best regards, -- Mateusz Loskot Review Manager for the proposed Boost.Histogram

2 1

Re: [boost] Mail List Migration - Update
by Tom Kent 21 Oct '18

21 Oct '18

> > The Boost mail lists are now migrated to a new set of servers. > This change affected all mail lists and web resources (signing up, > changing passwords, moderator access, archives...) that were associated > with the domain lists.boost.org . > If you are having difficulties, please drop me an email. (Oh the irony) > Happy coding! > michael > -- > Michael Caisse > Ciere Consulting > ciere.com Michael- I've tried to send e-mail to a couple lists with boost over the past few days. On Tuesday, Oct 16, I sent an e-mail at 19:21 CDT to the boost(a)lists.boost.org list, "Non-ASCII Path Names in Repo" [1]. It seemed to take the better part of a day to be received by the list. I remember it taking a long time (>24hrs), but I can't prove that. However, if you click the previous message/next message links on [1], you'll see that both of those messages (including the one previous!) are timestamped several hours after mine. Now, as of Friday, Oct 19, at 06:59 CDT I had sent another e-mail, this time to boost-testing(a)lists.boost.org. As of writing this e-mail (07:35 CDT, Sunday Oct 21), it still hasn't shown up on the testing list [2], and I haven't received an e-mail saying that it was received by the list. Any thoughts as to what might be happening here? In the past (including earlier this month for boost-testing), I was able to post without issue from this address (lists(a)teeks99.com) to both of these lists. Thanks, Tom [1] https://lists.boost.org/Archives/boost/2018/10/243784.php [2] https://lists.boost.org/boost-testing/2018/10/index.php

1 0

Allow LICENSE file per a library repository (PR #374)
by Mateusz Loskot 21 Oct '18

21 Oct '18

Hi, I'd like to bring this proposal to the community's attention: https://github.com/boostorg/website/pull/374 BTW, from time to time, while I looking at various requirements I try to refresh those outdated and catch up with the reality. I take baby steps. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

1 0

Re: [boost] Fwd: Installing CMake configuration files
by Peter Dimov 20 Oct '18

20 Oct '18

Steven Watanabe wrote: > Just a couple comments: ... > * I'm not fond of the ROOT parameter for boost-install.boost-install. > * Dependencies can be referenced with /boost/$(deps)//[stage|install] > * You can find the full path to the boost-install.jam with > [ path.root [ modules.binding $(__name__) ] [ path.pwd ] ] > This avoids hard-coding the location of boost_install relative > to the superproject. Actually, [ modules.binding $(__name__) ] seems to return an absolute path, so path.root/path.pwd may not be needed here? boostcpp.jam does BOOST_ROOT = [ modules.binding $(__name__) ] ; BOOST_ROOT = $(BOOST_ROOT:D) ; which kind of implies that it relies on getting the absolute path. > * That just leaves the stage directory, which is tied to the > project root, and should perhaps be calculated in Jamroot > instead of in boost_install. The stage directory needs to be retrieved from boostcpp, but boostcpp just sets it to "stage", which only works from top-level. It should probably use $(BOOST_ROOT)/stage, and then other modules can peek for it. There are other things that are needlessly replicated - install-header-subdir, install-default-prefix. All of these need to be peekable from a canonical location. > * This seems to handle --layout=versioned, but I'm not clear on > how well it handles --layout=system where we expect to use a > single compiled library for all configurations. It worked when I tried it. Note that you can have two libraries with --layout=system, not just one; libfoo.a and foo.so. > * Are the error messages that you get from CMake when there > isn't a configuration that matches the request intelligible? Not very. There's Boost_DEBUG, which tells you why something was skipped, but ideally, it needs to detect the case when no variant matched, and _then_ tell you why things were skipped without your having to set Boost_DEBUG beforehand. I haven't gotten that far yet; usability can be improved once we have it working. > It looks like the target will exist but will silently do nothing? Yes, you get a link error. > What if something goes wrong and there are multiple matches? I haven't encountered this so far :-) although it's possible in principle because at the moment I ignore some "non salient" properties. > * If generate-cmake-config takes the library as a source, > then it's possible to derive both the library dependencies > and the exact library name from the library target. The > dependencies can be found at the virtual target level in > generate-cmake-config, and the exact file name will appear > as the source in generate-cmake-config-. Doing it this way > also has the side effect that the CMake configuration won't > be installed if the library fails to build, which may be a > good thing. These may take me a while to figure out. :-)

3 15

[asio] Issues piling up
by Vinnie Falco 20 Oct '18

20 Oct '18

There are issues which are years old which have been lingering in the Boost.Asio repository, and there are also old issues in the stand-alone Asio repository. It seems like these are being ignored, is there any strategy for addressing this? Examples: This one is going on a year: <https://github.com/boostorg/asio/issues/77> Two years: <https://github.com/chriskohlhoff/asio/issues/124> Thanks

10 16

Re: [boost] Fwd: Installing CMake configuration files
by Peter Dimov 20 Oct '18

20 Oct '18

> Yeah, I haven't been able to figure this part out. How do I pass the > $(sources) from generate-cmake-variant to generate-cmake-variant-'s > sources? The sources - in this case $(lib-target) go here, after `non-scanning-action`: local a = [ new non-scanning-action $(lib-target) : boost-install.generate-cmake-variant- : $(property-set) ] ; :-)

1 0

Installing CMake configuration files
by Peter Dimov 19 Oct '18

19 Oct '18

I've taken another stab at installing CMake configuration files along with the libraries in `b2 install`. CMake configuration files are .cmake files, typically installed into $prefix/lib or $prefix/lib/cmake, that allow f.ex. `find_package(boost_system)` in a CMakeLists.txt file to find the installed Boost.System library and declare a CMake target Boost::system that refers to it. CMake targets can then link to Boost::system and all is well. The work in its current state is available on the feature/cmake-config branch of the superproject: git clone --recursive -b feature/cmake-config https://github.com/boostorg/boost cd boost bootstrap b2 --prefix=... install After that .../lib should contain the libraries and .../lib/cmake - the config files. Then from CMake cmake -DCMAKE_INSTALL_PREFIX=... .. as usual. See for example the test scripts at https://github.com/boostorg/boost_install/blob/master/.travis.yml#L60 and https://github.com/boostorg/boost_install/blob/master/appveyor.yml#L40 Since `b2 install` installs more than one library variant, the CMake configurations need to pick the correct one and to do so look at (a subset of) the FindBoost-compatible variables as described at: https://github.com/Kitware/CMake/blob/master/Modules/FindBoost.cmake#L122 Boost_USE_DEBUG_LIBS, Boost_USE_RELEASE_LIBS, Boost_USE_STATIC_LIBS, Boost_USE_STATIC_RUNTIME, Boost_COMPILER, Boost_DEBUG are honored and have the same meaning as in FindBoost. Boost_USE_MULTITHREADED and Boost_USE_DEBUG_RUNTIME are presently ignored, but probably shouldn't be. :-) The default of Boost_USE_STATIC_LIBS being OFF is a bit inconvenient on Windows, where without `--build-type=complete` our installation only gives you static libraries, and there are suggestions to respect it being ON or OFF, but when not set, to look at BUILD_SHARED_LIBS instead. Under the hood this represents a refactoring of the current centralized installation approach in which the superproject staged and installed the libraries on `b2 stage` and `b2 install`. Now the top level stage and install targets just delegate to each library's stage and install targets, which are responsible for staging/installing that particular library, its CMake config, and its dependencies. These library-level stage and install targets are created by the helper b2 rule boost-install, which already existed (in Jamroot), but is now much enhanced and lives in its own module tools/boost_install. In addition, a metalibrary libs/headers is introduced, which corresponds to the headers as present in a release (in subdirectory boost/) or as installed by `b2 install`. Its install target, in fact, installs the headers, and its stage target, currently empty, should probably assume the function of linking the headers (which at the moment also lives in Jamroot.) At some future point, when we decide to switch to releasing the headers in their original libs/$lib/include locations, the install target of a library will just copy that library's headers; but we aren't there yet. The header-only libraries are used from CMake by finding the package boost_headers and linking to the target Boost::headers. I've deliberately not done anything about Boost::boost and find_package(Boost), to allow FindBoost.cmake to delegate to the config files if present (when Boost 1.69/1.70 or higher is installed), while preserving backward compatibility (when 1.68 or lower is installed.)

6 13

test message - please ignore
by Robert Ramey 19 Oct '18

19 Oct '18

just to see if my newsgroup interface is working. Robert Ramey

1 0