- Boost - lists.preview.boost.org

Variant2 review
by Phil Endecott 11 Apr '19

11 Apr '19

Dear All, Here is my brief review of Peter Dimov's proposed Boost.Variant2. Sorry that this is not a particularly thorough review. I have read the docs, scanned the code, and followed the discussion on the mailing list; I have not tried to compile or use it. I have recently been using the original Boost.Variant for the first time. I actually started writing code based on std::variant, but then realised that I don't have support for it on one C++14-only platform, so changed to Boost.Variant. It's unfortunate that Boost.Variant has a somewhat different interface from std::variant, so it would be useful to have a Boost variant that is (more) compatible with std::variant. It would also be useful if it were somewhat backward compatible with the old Boost.Variant. The proposed Boost.Variant2 is compatible with std::variant; could some thin layer of compatibility be added to make it possible to port from Boost.Variant code? Specifically, the differences I have noticed are apply_visitor vs. visit and get(V*) vs. get_if. In my case, my stored types are typically raw pointers or small POD structs; none of these can throw during construction/assignment so the complicated arguments about exception guarantees are not applicable. Personally for my current application I'd be happy with a simpler variant that requires noexcept types, or disables assignment for types that might throw, or just doesn't offer an exception safety guarantee. Ideally, perhaps a Boost.Variants *library* should provide a selection of different variants with different features? That leads to the question of naming; we have boost::variant, boost::variant2 and std::variant and those names tell us nothing about how they differ. I'm unsure how or if this can be improved; I'm not suggesting that variant2 should be renamed variant_never_empty_maybe_double_size! But maybe the long-name of the library, i.e. what people will see when they look at the list of Boost libraries, could say "Never empty variant" rather than "Variant 2"? Prior to the review I was familiar with the issue of dynamic allocation, the fact that is is needed in some cases by some variant implementations, and the desire to avoid it. However I was not aware of the alternative of storing two copies of the union, doubling the size of the variant. Much of my work is with memory-constrained systems and unknowingly using twice as much memory as expected would be very undesirable. (I noticed Niall Douglas' comment earlier today "There is nothing wrong, *whatsoever*, with a variant which is sized the largest of its possible states multiplied by two" - I strongly disagree with that.) I'd like to at least get a warning if that were going to happen. A specific concern is that I might accidentally get this fallback due to forgetting to write "noexcept" somewhere (e.g. when using types from older code). On the subject of size, I note that the index is stored in an int, while virtually all uses would surely need fewer than 256 (or certainly 2^16) alternatives. Of course changing the index to uint16_t would not actually help on many platforms due to structure alignment requirements. This makes me wonder about a specialised variant for pointers that uses the spare bits in (most/some) 64-bit pointers to store the variant index. This could usefully be part of a variants *library*. I read Andrzej Krzemienski's comments about the documentation and largely agree with them - though I would say that this library is close enough to std::variant that perhaps the right thing to do is simply to say "go and read about std::variant and then come back here to see the differences". Peter posted a link to some benchmark results last week; those numbers are encouraging and it is also good to know that Peter actually made the effort to measure them! I do wonder how a "trivial" variant supporting only noexcept types would compare, though. Boost.Variant has something called polymorphic_get. I am unclear whether Boost.Variant2 (and/or std::variant) somehow support this functionality. The situation re. expected is unfortunate. I believe really the review should have waited for it to be completed. Peter's comment that if it is decided that it needs to be reviewed then he would remove it and never resubmit it was ... surprisingly undiplomatic? I have always found it a bit odd that Boost requires a thorough review of an initial library submission but nothing at all for later additions. In summary: - I believe the library should be accepted. - It would be great if some compatibility features with Boost.Variant could be added, to make it possible for users of that older library to transition more easily. That is not a condition for acceptance. - I would love to have some way to get a warning or error if the double storage mode had been triggered, or to disable that mode (with an error). - It would be great to see some alternative variants, with different features / trade-offs, included in the library. Ideally, naming of types and headers should allow for that. I'm not suggesting that Peter should be personally expected to supply these alternatives, but perhaps he would accept offerings from others. - I think we should allow Peter to "slip in" his expected when it is ready; I say this largely because Peter has a long history with Boost. Future review managers should try to avoid situations like this arising. Regards, Phil.

7 18

[release] Boost 1.70.0 Release Candidate 2 available
by Marshall Clow 11 Apr '19

11 Apr '19

The second release candidate for the 1.70.0 release are now available at: <https://dl.bintray.com/boostorg/release/1.70.0/source/> Changes since rc1: * Boost.Config changes to work better with msvc-14.2 * Boost.Beast bug fixes * Boost.Move bug fix * Boost.Math non-ascii characters removed from header file The SHA256 checksums are as follows: 882b48708d211a5f48e60b0124cf5863c1534cd544ecd0664bb534a4b5d506e9 ./boost_1_70_0_rc2.tar.gz 430ae8354789de4fd19ee52f3b1f739e1fba576f0aded0897c3c2bc00fb38778 ./boost_1_70_0_rc2.tar.bz2 48f379b2e90dd1084429aae87d6bdbde9670139fa7569ee856c8c86dd366039d ./boost_1_70_0_rc2.zip ae2bb1b35d1f238e72e3f819b42336f4bd27c9ed2092aab5d87818ccb0c9161a ./boost_1_70_0_rc2.7z 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

3 5

Problem with generating file_descriptor suing existing pipe file descriptor
by Russell West 10 Apr '19

10 Apr '19

Our program just installed version 69 of Boost and I am running into a compile issue that I am not sure how to resolve. Following is the associated section of C++ code that I am unable to figure out the changes to get it to compile. int filedes[2]; if ( pipe(filedes) == 0) { using namespace boost::iostreams; stream<file_descriptor> results(filedes[0], close_handle); .... .... } The last provided line of code does not compile with a no matching function for call to 'boost::iostreams::file_descriptor::file_descriptor(int&, file_descriptor_flags&)' error. I noticed in the version of the boost file_descriptor.hpp loaded and being used the following exists: #ifdef BOOST_IOSTREAMS_WINDOWS file_descriptor(int fd, file_descriptor_flags); #endif The associated application attempting to be built and deployed is only for servers running the Linux operation system so BOOST_IOSTREAMS_WINDOWS is not enabled, causing the above constructor not to be available. The other constructor available is file_descriptor(handle_type fd, file_descriptor_flags); but I can not figure out how to generate a detail::file_handle from the available int file descriptor generated from above pipe command. Will it cause any issues enabling BOOST_IOSTREAMS_WINDOWS so the required constructor will be available? Thanks ahead of time for your time and feedback. Russell West

2 1

Re: [boost] [Boost-GIL] Image Processing Algorithms
by Mateusz Loskot 10 Apr '19

10 Apr '19

On Wed, 10 Apr 2019 at 18:54, Amir Ali <amirqadir(a)live.com> wrote: > > I really want to do this project even if I am not considered for GSOC. > I am still willing to do it on my own with guidance and supervision from any mentor. There are two mentors who will mentor three students in total. So, we can not offer any supervision to more projects. You are welcome to post your questions to the boost or boost-gil lists, or ask on Gitter room or the Slack channels as any user of / contributor to Boost libraries can do. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

1 0

[Boost-GIL] Image Processing Algorithms
by Amir Ali 10 Apr '19

10 Apr '19

Hi, I am looking for someone to mentor me for my project that is to implement image processing algorithms in Boost-GIL. Here’re some of the algorithms I am aiming to make. Mathematical Morphology (Dilation, Erosion, Opening, Closing) Filters (High pass Filters, Low Pass Filter which includes Gaussian etc) And Other Image enhancement basic algorithms. Regards Amir

2 1

[variant2] Andrzej's review -- documentation
by Andrzej Krzemienski 10 Apr '19

10 Apr '19

Hi Everyone, This is the review of the documentation of variant2. First, the docs assume that the user is already familiar with std::variant or boost::variant, and the introductory part only highlights the difference from std::variant. It does not even mention that variant<X, Y> always stores either X or Y. "Type-safe discriminated union (variant) type," sounds arcane to novices. Notation variant<T…> is also confusing to someone who encounters variant for the first time. There is no initial example. No mention of visit() which is the most important part of the interface. Compare this with Boost.Variant docs: https://www.boost.org/doc/libs/1_69_0/doc/html/variant.html I do not think the library should assume this. Boost libraries are characteristic of documentation that introduces potential users to the problem domain and gives a sort of tutorial that shows how to use the library. I recommend doing the same for variant2. This library does a lot of contortions to avoid the valueless state, but does not describe what the motivation for it is. The docs also do not give a sense of what performance (spacial and runtime) trade offs this library does. For instance, we do not know if the double-buffer scenario th second buffer is within variant's storage or on the heap. Or we do not know about secret moves that the library does internally, which gives surprising behavior to the users that store non-movable types in variant. Consider the following example: ``` struct X {}; struct Guard { explicit Guard(int) {} Guard(Guard&&) = delete; }; variant<X, Guard> v {}; v.emplace<Guard>(1); ``` This works fine with std::variant, but fails to compile with variant2::variant, because the latter requires all the alternative types, at least in one implementaiton of the never-empty trick, to be move-constructible. But this requirement is never listed in either global requirements for alternative types stored in variant, or in the specification of functions `emplace()`. Here's a wandbox example: https://wandbox.org/permlink/hGbRtgzpUrpF0ODy The Reference part of the docs is really good and detailed. Some minor "bug reports" follow. In the specification of functions types `T0` and `Ti` are used, but `T0` or `Ti` are never defined. Wording in the C++ Standard also refers to `T0` and `Ti`, but also provides a definition: In the descriptions that follow, let i be in the range [0, sizeof...(Types)), > and Ti be the ith type in Types. > <http://eel.is/c++draft/variant.ctor#1.sentence-1> > See http://eel.is/c++draft/variant.ctor#1 A similar definition should be put in variant2's documentation. Noexcept specifications use mp_all. this assumes that users of variant2 must be familiar with Boost.mp11. I recommend removing the reference to mp_all and instead use something similar to what the Standard does: http://eel.is/c++draft/variant.ctor#11 Specification of function `emplace<I>()`: It says: > > On exception: If the list of alternatives contains monostate, the > contained value is either unchanged, or monostate{}; > In what situation on exception is the contained value left unchanged? This question applies to the next bullet as well. The specification also doesn't mention that `.emplace<I>()` requires Ti to be move-constructible in some cases. It also says: Throws: Nothing unless the initialization of the new contained value throws. Which sounds strange, because it does throw something. In other places you use "Throws: Any exception thrown by the initialization of the contained value.", which makes more sense. Also, the Standard uses, "Throws: Any exception thrown during the initialization of the contained value. <http://eel.is/c++draft/variant.mod#11.sentence-1>": http://eel.is/c++draft/variant.mod#11 swap(): What does it throw and when? Other functions specify it but this one does not. get<I>(): Specification says, > > If v.index() is I, returns a reference to the object stored in the > variant. Otherwise, throws bad_variant_access. > This means that if I provide an index that is far greater than `sizeof...(T)`, the program should compile fine and throw an exception at run-time. This is not what the implementation does: I get a compile-time error, which is good, but inconsistent with the docs. They need an additional "Requires:" clause. visit(): I think it is underspecified. It is not immediately clear that the first parameter is the visitor and the remaining ones are variants. Parameter names F and V do not convey this clearly. Either use Visitor and Variants... or provide a longer description, even if informal. The docs really should contain an example of `visit()` somewhere. According to the specs, the following should work: ``` void f() {} variant2::visit(f); ``` which is not incorrect, but strange. The std::variant also provides a second overload of `visit` that explicitly defines the return type: http://eel.is/c++draft/variant.visit This overload is not present in variant2. But this fact is not listed in the initial section of the docs that lists the differences between the two libraries. Regards, &rzej;

2 6

[variant2] Comments on documentation
by Bjorn Reese 10 Apr '19

10 Apr '19

The overview states that "variant<T...> is not trivial when all contained types are trivial". Why not? Is this an advantage somehow or an unfortunate limitation? Why is there no tutorial? Why is there no design rationale? Change "variant_npos = -1" into "variant_npos = unspecified" Add a comment about the purpose of valuesless_by_exception(). Without such a comment, the function seems very odd on a "never valueless variant type." The destructor should be marked as noexcept.

4 8

[variant2] Review - Review period extended until April 15
by Michael Caisse 09 Apr '19

09 Apr '19

Hi all - The review period for Boost.Variant2 has bee extended to April 15. Thank you to those who have participated so far. There has been a fair amount of discussion about the merits of never valueless. A core design _feature_ of Variant2 is never valueless. You may have made different trade-offs. Understanding motives makes sense but in this review we are not trying to change this basic design choice. This paper by Peter discusses valueless variants some and may be useful reading: <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0308r0.html> If you haven't started your review yet, you have time! Reviews ranging from detailed discussions of inner workings to a user-perspective of the library and documentation are all helpful. I personally believe we need more user-based reviews in Boost. So, feeling sheepish about reviewing? Don't! Your review is important in the process. Here is one more motivation if you are on the fence ... Peter's code is a joy to read. The library is extremely clean and the code is accessible. There might be all kinds of things you learn from reading the source. Thank you again community for staying involved. We get great libraries when people ask questions, review, and provide input to everything from the docs to the design. Happy coding! michael -- Michael Caisse Ciere Consulting ciere.com

1 0

GSOC 2019 proposal
by Siddhartha Sen 09 Apr '19

09 Apr '19

Once the proposal is ready, where do I officially submit the pdf?

2 1

Re: [boost] [release] Boost 1.70.0 Release Candidate 1 available
by Ion Gaztañaga 09 Apr '19

09 Apr '19

On 07/04/2019 15:07, Rainer Deyke via Boost-users wrote: > On 07.04.19 14:13, Marshall Clow via Boost-users wrote: >> On Sat, Apr 6, 2019 at 10:53 AM Rainer Deyke via Boost-users < >> boost-users(a)lists.boost.org> wrote: >> >>> On 04.04.19 16:27, Marshall Clow via Boost-users wrote: >>>> 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. >>> >>> boost::movelib::adaptive_merge continues to be broken if >>> iterator_traits<RandIt>::size_type != std::size_t. This breaks >>> boost::container::flat_map when cross-compiling for MacOS. I have >>> previously reported this error here. >>> >>> I consider this a critical error - as in, I won't be able to upgrade to >>> Boost 1.70 at all unless this error is fixed for the release. >>> >> >> This is https://github.com/boostorg/move/issues/25, correct? > > Yes. Sorry for note replying earlier, I was on a trip. The fix is not complicated but several files need to be modified. Committed to develop: https://github.com/boostorg/move/commit/bfdfca0b88fe1cf4e67b42fcacd5e126e93… @Rainer: I've checked this fix in several msvc and gcc's locally. The error report does not contain any example for the bug, so I don't know if I've fixed your use case. I don't know if we are still on time for 1.70. Best, Ion

4 5