- Boost - lists.boost.org

[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