- Boost - lists.preview.boost.org

out_ptr review is extended until Wednesday, July 10
by Zach Laine 29 Jun '19

29 Jun '19

We don't have enough reviews yet, so we're extending the review by two weeks. Please review this small and useful library! >From the original announcement: The formal review of JeanHeyd Meneide's out_ptr library starts Sunday, June 16th and ends on Wednesday, June 26th. out_ptr is a library for making it easy to interoperate between smart pointers and traditional C-style initialization and allocation interfaces. It also enables doing so in a way that allows library authors to opt into speed optimizations for their smart pointers that give them performance equivalent to typical C pointers (see benchmarks ( https://github.com/ThePhD/out_ptr/blob/master/docs/out_ptr/benchmarks.adoc) and the Standard C++ proposal for more details). Online docs can be found here: https://github.com/ThePhD/out_ptr/blob/master/docs/out_ptr.adoc The GitHub repository is available here: https://github.com/ThePhD/out_ptr Also, there is an associated standards proposal: https://thephd.github.io/vendor/future_cxx/papers/d1132.html We encourage your participation in this review. At a minimum, please state: - Whether you believe the library should be accepted into Boost - Your name - Your 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? All issues discussed during this review will be tracked on the library's GitHub issue tracker at https://github.com/ThePhD/out_ptr/issues. Zach

5 7

[accumulators] Offer to help with maintenance
by Cromwell Enage 29 Jun '19

29 Jun '19

Hi, everyone! I'm offering to help maintain Boost.Accumulators and have already e-mailed Eric Niebler regarding my intentions. With the deadline for Boost release 1.71 fast approaching, I can take steps to ensure that Boost.Accumulators is in a usable state. I also have a few ideas on how to update and improve Boost.Accumulators (one of them being to make use of variadic templates), but they can wait until after the release for further discussion. Very respectfully, Cromwell D. Enage

1 0

Re: [boost] [logic] Boost::logic (tribool?) actively developed?
by Jacob Lidman 28 Jun '19

28 Jun '19

> It has resently updated to support a change in gcc compilers. So I > would say it's actively maintained. I never asked if it was actively maintained but rather if the library is actively developed, i.e. are new features added, improvements in documentation... > I would say it seems stagnant because it's always been as close to perfection as a > library can be. The reason why the library appear close to perfect is because it clearly has minimal number of features. Improvements can be made to accommodate new needs, e.g. by including other logics. > see https://github.com/boostorg/logic As I mentioned this is the repo for the tribool library, at least that was the name prior to boost 1.70.0

2 1

Some out_ptr concerns
by Glen Fernandes 28 Jun '19

28 Jun '19

Thanks to JeanHeyd for going through the Boost review process, and to Zach for managing the review. Briefly: I do not have enough reasons to recommend acceptance for out_ptr just yet --- in its current form. (I'd like to see it return for a new review when the feedback from this review shapes the design so that some of these concerns are resolved). Second: This excludes "inout_ptr" (for which I had even more concerns) and just focusing on "out_ptr" - which is the simpler and more common use case of the two. Below comparing out_ptr vs the hand written code that a user would write to use a /typical/ C out-pointer API with smart pointers, this is what I'm comparing: [Typical code user would write]: Type* raw; Result result = TheCApi(args..., &raw); if (!Success(result)) { // failure (e.g. return, or branch and handle error) } Smart<Type, Deleter> smart(raw, etc...); [What happens with out_ptr now]: /* 'smart' already has to exist here before TheCApi is called. Either as Smart<Type, Deleter> smart; or Smart<Type, Deleter> smart(nullptr, etc...); depending on deleter */ /* User writes: Result result = TheCApi(args..., out_ptr(smart)); // or Result result = TheCApi(args..., out_ptr(smart, etc...)); depending on deleter */ Type* raw = nullptr; Result result = TheCApi(args..., &raw); if (raw != nullptr) { smart.reset(raw); // or smart.reset(raw, etc...); depending on deleter } if (!Success(result)) { // failure (e.g. return, or branch and handle error) } Concern 1. Having to materialize the smart pointer before TheCApi is called. Ordinarily this might be fine for some smart pointers and stateful deleters, but it may not be for others. Concern 2. The original user code initializes the smart pointer based on Success(result). The out_ptr version would do so based on whether the raw out pointer was changed to something non-null by TheCApi. This might be fine for some cases, but it may not be for others. That it isn't the same as fundamental logic as the user code bothers me, though. Concern 3. The equivalent of the hand written user code is less overhead. Personally I'm of the opinion that maybe this doesn't matter too, but here the author does say he has users who cannot abide by it, and that this facility needs support from e.g. std::unique_ptr to be viable. (And this leads to concern 4 below). [I'm not a fan of needing unique_ptr implementations to add support for this to make it comparable to some user's hand written code]. Concern 4. The UB optimization that the author wrote because of Concern 3 is a real concern to him. The UB optimization has no place in Boost, and one of which doesn't even work with many C++ library vendors' unique_ptr. [Fortunately the Boost reviews have already echoed this sentiment and I believe this is going away]. Concern 5. Supporting other custom smart pointers requires effectively re-implementing out_ptr_t by specialization. I have come to see this as not viable. [Already mentioned in other reviews] Concern 6. C APIs where the deleter (its state, logic, etc.) are governed by some other result from TheCApi. This is can be worked around in many cases, but the workaround is clumsy. Or insupportable, in other cases. i.e. The stateful deleter is always initialized with 'etc...' either before-hand via Smart<Type> smart(nullptr, etc...) or at call site with: TheCApi(args, out_ptr(etc...)); before analyzing other results of calling TheCApi. (The 7th concern I had made notes about pre-review has already been eliminated, when the unconditionally noexcept destructor is now only conditionally noexcept). Other thoughts: The suggestion by Emil lead to an interesting alternative idea to this problem domain, but I had no time to fully explore it. I don't think it would address all of these concerns. It has some other greater appeal, e.g. a way to call C APIs that materializes the smart pointers as results (along with C API return value) of an "Invoke-style" thing. Or even a way to transform a C API with out-pointers into a C++ callable that returns smart pointers (along with C API return value) via a "Bind-style" thing. Glen

1 0

out_ptr -- alternatives
by Andrzej Krzemienski 28 Jun '19

28 Jun '19

Hi Everyone, This is not a review of out_ptr, but I wanted to share my thoughts about the motivation for this library. I do not recall any time from my programming experience where I was in need of passing a smart pointer to a T** interface, so maybe this is why I cannot appreciate the value of out_ptr. On the other hand, if I need to use a library with a C API, or other non-C++ API (this happens when someone wants to naively port a Java library to C++ and keep the Java interface) the first thing I do is to wrap the API functions into a RAII class. It takes some time up front, but then whenever it is used, I do not have to deal with the problems of the old API. `T**` is only one of the problems. The motivation focuses on only easily passing smart pointers to `init(T**)` functions, but it does not address the problem of adapting the error reporting of `init(T**)`to the error reporting of my program. I would never want to only solve the former problem and omit the latter. Also, I would never want to represent a handle to a resource with a smart pointer, as I do not want to voluntarily inject the null-pointer state that I now have to take care of everywhere. Instead I would prefer a dedicated type that is not default-constructible, where one really needs to try hard to get the special no-resource state (e.g. by moving from and not destroying the object). What I am missing from the motivation of out_ptr is the comparison with a full RAII wrapper solution. You can argue that the scope of out_ptr is just different: provide interpoperation between `init(T**)`functions and smart pointers. But I would argue that this latter goal is wrong. In fact, I am concerned that we might be encouraging a bad programming style: "need to work with init(T**) APIs? use shared_ptr." instead of promoting RAII wrappers that directly wrap the resource. Does anyone else feel the same? Or am I missing something about the problem domain? Anyway, I think that this problem should be covered in the documentation. Regards, &rzej;

6 8

[logic] Boost::logic (tribool?) actively developed?
by Jacob Lidman 27 Jun '19

27 Jun '19

Hi, Is boost::logic actively developed and if so what are the future plans for the library? >From the source/documentation it seems to be dormant since ~2004 and a renaming of the tribool package. The latter is listed as a library on the boost homepage but lack a library repo on github.com/boostorg (?). BR /Jacob

2 1

ASIO TCP connection switch
by JH 27 Jun '19

27 Jun '19

Hi, I have an application using ASIO TCP/IP SSL socket connection in an embedded device, the device has two network interfaces, when one is down, another network interface takes over, which requires application TCP SSL socket connection to be established binding to a new network interface. What will be an appropriate implementation to switch application TCP connection from one to another interface? Option 1: Restart application Option 2: Terminate the old interface socket, create a new socket to start initial connection Option 3: Some reconnection method which I don't know Appreciate you advice. Thank you. Kind regards, - jupiter

3 4

Can boost ASIO socket binding to any interfaces or support QUIC?
by JH 27 Jun '19

27 Jun '19

Hi, I posted a similar question in another email but title was not appropriate, let me try it here using a more accurate clear title. I might need separate it into email questions, I am not quite clear it is boost socket nature or it is NAT issue. I have both client server applications using boost asio TCP socket, the client application is a Linux embedded system IoT device installed in home connect to server via NAT, the embedded system has two network interfaces, WiFi and cellular, in anytime there is only one network interface is up ans signed by an IP address, when one interface is down, another interface is up and signed IP address. The problem for an existing TCP socket connection is it cannot change from one interface to another. When one interface down another interface takes over, the client application continual sends data to the down interface buffered in TCP queue without transmission error but the server would never receive the data. It seems the only solution is to use QUIC, hence I asked here if there is any boost functions to support QUIC I can replace the TCP socket by QUIC. Appreciate your advice and tips. Thank you. Kind regards, - jupiter

1 0

[build] Build errors with gcc - bad argument -mcpu=v7
by Andrey Semashev 26 Jun '19

26 Jun '19

Hi, I'm trying to run tests for Boost.Core with the following command: bjam -j 8 toolset=gcc cxxstd=14 variant=release libs/core/test Compilation fails with the following errors: gcc.compile.c++ bin.v2/libs/core/test/lightweight_test_fail10.test/gcc-8/release/cxxstd-14-iso/threading-multi/visibility-hidden/lightweight_test_fail10.o g++: warning: ‘-mcpu=’ is deprecated; use ‘-mtune=’ or ‘-march=’ instead cc1plus: error: bad value (‘v7’) for ‘-mtune=’ switch cc1plus: note: valid arguments to ‘-mtune=’ switch are: nocona core2 nehalem corei7 westmere sandybridge corei7-avx ivybridge core-avx-i haswell core-avx2 broadwell skylake skylake-avx512 cannonlake icelake-client icelake-server bonnell atom silvermont slm knl knm intel x86-64 eden-x2 nano nano-1000 nano-2000 nano-3000 nano-x2 eden-x4 nano-x4 k8 k8-sse3 opteron opteron-sse3 athlon64 athlon64-sse3 athlon-fx amdfam10 barcelona bdver1 bdver2 bdver3 bdver4 znver1 btver1 btver2 generic native "g++" -std=c++14 -fvisibility-inlines-hidden -fPIC -m64 -pthread -O3 -finline-functions -Wno-inline -Wall -fvisibility=hidden -mcpu=v7 -DBOOST_ALL_NO_LIB=1 -DNDEBUG -I"." -c -o "bin.v2/libs/core/test/lightweight_test_fail10.test/gcc-8/release/cxxstd-14-iso/threading-multi/visibility-hidden/lightweight_test_fail10.o" "libs/core/test/lightweight_test_fail10.cpp" ...failed gcc.compile.c++ bin.v2/libs/core/test/lightweight_test_fail10.test/gcc-8/release/cxxstd-14-iso/threading-multi/visibility-hidden/lightweight_test_fail10.o... I'm not sure where that -mcpu=v7 comes from, but I don't have it in my options, nether do I see it in the Jamfile.

2 2

[release] 1.71.0 closed for new libraries and breaking changes
by Michael Caisse 26 Jun '19

26 Jun '19

The master branch is now closed for new libraries and breaking changes, and will be closing for major changes in a week and closed for the beta in two weeks. Also, if you're ready, you can also add your libraries' changes to the release notes at: <https://github.com/boostorg/website/blob/master/feed/history/boost_1_71_0.q…> Thanks, -- The Boost Release Team

1 0