April 2019 - 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

[variant2] request to extend the review period
by Andrzej Krzemienski 08 Apr '19

08 Apr '19

Michael, Peter, Would it be possible to extend the review period? I may only be able to devote more time to the review on Thursday, so if it was possible to extend the review at least till 12th, I might have a chance to get it done. I suspect, I might be not the only one in this situation. Regards, &rzej;

1 0

Re: [boost] variant - off topic
by Bjorn Reese 08 Apr '19

08 Apr '19

On 4/3/19 11:27 PM, Robert Ramey via Boost wrote: > d) insert your own use case here. That is, look at your own usages of > assignment to these types and see if there is not an easy way to > re-factor your code to avoid assignment. Such refactoring is difficult for state machines where you use a variant to denote the current state.

4 9

Enabling spectre mitigation in boost libraries
by Riff J 08 Apr '19

08 Apr '19

Hi everyone, I am a developer from Microsoft and currently using boost in our project. We recently get noticed by our security team, that the boost library we use, are not compiled with spectre mitigation (/Qspectre) enabled. Since boost is super powerful, it might not be a good idea to write our own or maintain our own version, so we are reaching out for help. Could anyone please help see if we could enable /Qspectre option in the official build of boost? And here is the vcblog about the spectre mitigation, if anyone is interested: https://blogs.msdn.microsoft.com/vcblog/2018/01/15/spectre-mitigations-in-m… . And since this is the first time I use this mail list, please let me know, if I didn't use it correctly or anything I should pay attention to. Thanks a lot, Riff

10 22

[gsoc19] Boost.Geometry Delaunay triangulation and Voronoi diagrams
by Georgios Venizelos 08 Apr '19

08 Apr '19

Hello, I would like to undertake the Delaunay/Voronoi project in Boost.Geometry library. I have already shared my proposal on GSoC through Google Docs. I think that Delaunay triangulation is a process that has many applications, so it is useful to have such a process implemented in Boost libraries. Main focus of the program would be to implement Delaunay and Voronoi for Cartesian coordinates in 2 and 3 dimensions. If finished early, this could extend either in higher dimensions or in other coordinate types. Would anyone be interested in mentoring such a GSoC project? With respect, Georgios Venizelos --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

1 0

Re: [boost] Enabling spectre mitigation in boost libraries
by Kenneth Porter 08 Apr '19

08 Apr '19

On 4/6/2019 9:46 AM, John Maddock via Boost wrote: > One thing we could look at for future releases would be to provide > differently-named binaries for /Qspectre. Anyone else have thoughts > on that? I just looked at the libraries available via the Visual Studio installer and I see this in my installation (using atls as an example MS-supplied library): C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.20.27508\atlmfc\lib\spectre\x64\atls.lib C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.20.27508\atlmfc\lib\spectre\x86\atls.lib C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.20.27508\atlmfc\lib\x64\atls.lib C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.20.27508\atlmfc\lib\x86\atls.lib That may give some guidance as to how MS can package the Boost libraries for internal distribution.

1 0

Re: [boost] [variant2] Andrzej's review -- design
by Mike 08 Apr '19

08 Apr '19

> Going back to variant, in one case, we are defining an empty state, which > forces the user to provide explicit handling for that state, *everywhere*. You keep repeating that the user would have to explicitly handle that everywhere. I thought I just showed you that this is not the case. Except for visit, you don't have to explicitly handle the valueless state at all and even in the case of visit, you might be fine with std::visit just throwing an exception, because that is indeed an exceptional circumstance. I don't see this *everywhere* at all. Best Mike

8 18

[release] Master branch now completely closed for the 1.70.0 release
by Marshall Clow 08 Apr '19

08 Apr '19

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

4 7

Regarding Boost.Astronomy GSoC19 proposal review
by sarthak2007 07 Apr '19

07 Apr '19

Hello community, I am Sarthak Singhal, pursuing B.Tech in Computer Science from Indian Institute of Technology, Kanpur. I had submitted the programming competency test to mentor and also got a positive response from her. I had also submitted the project proposal to the mentor and based on her suggestions have improved it also. I have submitted the draft of the proposal to GSoC site. I request you to go through the proposal. I will appreciate your feedback to improve the proposal. Thank you, Sarthak Singhal -- Sent from: http://boost.2283326.n4.nabble.com/Boost-Dev-f2600599.html

2 4

[release] Boost 1.70.0 Release Candidate 1 available
by Marshall Clow 07 Apr '19

07 Apr '19

The release candidates for the 1.70.0 release are now available at: <https://dl.bintray.com/boostorg/release/1.70.0/source/> The SHA256 checksums are as follows: 6e5cba1269225395bb5e78dda48441ccadaf745e42638180015e9e6257068336 ./boost_1_70_0_rc1.7z 35d8e1361e2063f70aa3a6ca0dd8af0877ceb75477ebbd2c726bb1d039658c7a ./boost_1_70_0_rc1.tar.bz2 ec8ddbbee2fd61e2f78a1dfe9a07ad83ca8f6a2f4c704d6f297d89c6afdc4f2c ./boost_1_70_0_rc1.tar.gz ee2c3b97ce10f85a31b6a105ad8edf1c20fb4b936c9a6e6008206059cb98ab1b ./boost_1_70_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 Boost Release Managers

7 14

Re: [boost] [Boost-users] [release] Boost 1.70.0 Release Candidate 1 available
by Marshall Clow 07 Apr '19

07 Apr '19

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? -- Marshall

1 0

[gsoc 19] Review of the proposal draft
by pranay gupta 07 Apr '19

07 Apr '19

Hi list, I have submitted the first draft of my proposal for implementing non-negative matrix factorisation in boost.ublas. It would be really helpful if you could please review it and suggest any improvements. Thanking you in advance. Sincerely, Pranay

2 3

Variant2 review
by Niall Douglas 07 Apr '19

07 Apr '19

I'll firstly apologise for the brevity of this review. It is just before the ACCU conference where I am speaking on a topic I have little knowledge of, and I have done almost no prep due to insufficient hours in the day. I am aware that if I don't make a review now, then I won't at all, so this will have to do. 1. Overall I like the library, it adds significant benefit (primarily removal of dynamic memory allocation) over Boost.Variant. 2. I don't like the lack of propagation of triviality of each individual special member functions. std::variant does this. std::expected does this. I can see Peter's point that for long lists of alternative states, implementing this is a lot of pain for almost no gain. However I do NOT agree with him for Expected. For a two-state variant, it is very highly likely that triviality of special member function will be very important for not a small number of use cases. I personally am happy for Variant2 to implement Expected without review approval here IF that Expected matches exactly std::expected. I am NOT happy if Variant2's Expected breaks conformance on triviality of special member function. If that is the only option on the table, then either please do not include an Expected implementation, or don't include Variant2. This raises a wider point though. What is good for a two-state variant still applies, though less so, to three-state variants, four-state variants and so on. I think there is a fundamental design issue here. If Variant2 can't propagate triviality of individual special member functions for small-number-of-state variants, then there is something fundamentally wrong here. 3. I find the design choice to randomly permute state to avoid an empty state baffling when there is a double buffer based design choice available. I do not like, one bit, the random permutation of state. I think it will lead to buggy code with hard-to-test corner cases. I think it needs to go away in the proposed design. I also don't get the dislike of the double buffer based design. Peter seems to really dislike it, and avoids it whenever possible. I can't understand why. If you can employ a double buffer design in order to eliminate random permutation of state, to me this is an unalloyed good in every way. Nowhere does it say that a variant must be no larger than the largest of its possible states. There is nothing wrong, *whatsoever*, with a variant which is sized the largest of its possible states multiplied by two. So please change the design to that instead. That should be the default design, and design claims. Programmers should write code assuming that design. IF it can be proven that a double buffer is unnecessary e.g. all alternative types are noexcept, a monostate alternative is available etc, THEN you can employ a single buffer implementation as an *optimisation*. That makes thing simple for the end user: add monostate, get single buffer sized. Otherwise assume double buffer sized. With a default double buffer design, most of the other issues which other reviewers have raised go away. Even Robert's concerns about assignment operators, with a double-buffer-by-default design one can always implement the strong guarantee. I badly need to depart, so I'll have to end there by saying that I vote to ACCEPT, conditional on (i) propagation of triviality of special member functions for at least small numbers of alternative states and (ii) removal of ANY POSSIBILITY of random permutation of chosen state under ANY circumstances. Finally, thanks Peter for bringing this library for review. Nice library. Niall

1 0

Proposal for GSoC'19 ( Random Points Generation)
by Mudit Agarwal 06 Apr '19

06 Apr '19

Hi I am submitting my first draft of the proposal for the project, Implementing algorithm for random point generation according to some given distribution in a geometry. I have also implemented competency test for the project https://github.com/Mudit-1999/Random_Points_Generation. It would be really helpful if you could please check if I have fulfilled all the points mentioned to pass competency test. Can you also please review my proposal and suggest any improvement. Hereby attach is my proposal. Thanking you in advance Regards, Mudit Agarwal

1 0

[review][variant2] Variant2 Review Starts April 1
by Michael Caisse 06 Apr '19

06 Apr '19

The Boost formal review of Peter Dimov's Variant2 library will take place April 1 - 10, 2019. Please consider participating in this review. The success of Boost is partially a result of the quality review process which is conducted by the community. You are part of the Boost community. I will be grateful to receive a review based on whatever level of effort or time you can devote. Variant2 is a never-valueless C++11/14/17 implementation of std::variant. >From the README: The class boost::variant2::variant<T...> is an almost conforming implementation of std::variant with the following differences: * A converting constructor from, e.g. variant<int, float> to variant<float, double, int> is provided as an extension; * The reverse operation, going from variant<float, double, int> to variant<int, float> is provided as the member function subset<U...>. (This operation can throw if the current state of the variant cannot be represented.) * variant<T...> is not trivial when all contained types are trivial. To avoid going into a valueless-by-exception state, this implementation falls back to using double storage unless * one of the alternatives is the type monostate, * one of the alternatives has a nonthrowing default constructor, or * all the contained types are nothrow move constructible. If the first two bullets don't hold, but the third does, the variant uses single storage, but emplace constructs a temporary and moves it into place if the construction of the object can throw. In case this is undesirable, one can force emplace into always constructing in- place by adding monostate as one of the alternatives. You can find the source code here: <https://github.com/pdimov/variant2> and the documentation here: <https://pdimov.github.io/variant2/doc/html/variant2.html> Please take an early look at the library and ask questions now. Peter Dimov is very active on the Cpplang Slack #boost channel; however, please consider using the Boost Dev or User Mail Lists so that the entire community might benefit from your conversation. Note: The repository contains an expected implementation also; however, that is not being considered in this review. Thank you for your participation! michael -- Michael Caisse Ciere Consulting ciere.com

5 12

[gsoc19] looking for mentor
by Aziz Mousa 06 Apr '19

06 Apr '19

hi, I have my idea to contribute in boost project, I read the boost libraries list and see that the author of Algorithm is "Marshall Clow" I want to know how to contact with him to tell him about my idea. thanks.

1 0

Call for Speakers: International Conference on Information Society (i-Society 2019)
by International Conference on Information Society 06 Apr '19

06 Apr '19

If you are not able to see this mail, click http://r.confinfosoc.org/mk/mr/qLUGBQMxp4Sjs2NE4YExi3z5lvlWCZKGhXcL8vLsIM2b… for Speakers: International Conference on Information Society (i-Society 2019) [ ]( http://r.confinfosoc.org/mk/cl/f/SUXNTtBZKKIQS3K7XMAgqz2d4gwN08R7QeY-JpBOAY… ) Submission i-Society 2019 Call for Speakers is an open invitation. We sincerely hope that you could give a talk to the diversity of participants. Increase numbers of renowned speakers have confirmed their participation. If you are interested in giving a talk, please complete the form at http://r.confinfosoc.org/mk/cl/f/WcSYgytshsQLNmvIxy3wVH45pNQcePlyBDtX1_3wdq… before or by the 1st of May, 2019. [ Submission ]( http://r.confinfosoc.org/mk/cl/f/-hT6brTC-Gpj8JwZIfXWMoq1tq9fO0kmb4uz_A4rSS… ) This email was sent to boost(a)lists.boost.org You received this email because you are registered with Infonomics Society [ Unsubscribe here ]( http://r.confinfosoc.org/mk/un/IcFogLSqu5RwSkorQ9Mu-bTdNLGBdU-QcdZpGWjlqfqJ… ) Sent by [ ]( http://r.confinfosoc.org/mk/cl/f/3aG3a0Qf4pxEQF2aHlpkSK0PjUVKbrOE2FXQYnchXN… ) © 2019 Infonomics Society

1 0

auto_link.hpp update for Visual Studio 2019 GA release
by Trueman, Chris 06 Apr '19

06 Apr '19

Building boost with the GA release of Visual Studio 2019 names the outputs with v142 (which matches what VS 2019 names its build tools). But auto_link.hpp causes the linker to look for files named with v141. I changed auto_link.hpp to: # elif defined(BOOST_MSVC) && (BOOST_MSVC < 1910) // vc14: # define BOOST_LIB_TOOLSET "vc140" # elif defined(BOOST_MSVC) && (BOOST_MSVC < 1920) // vc14.1: # define BOOST_LIB_TOOLSET "vc141" # elif defined(BOOST_MSVC) // vc14.2: # define BOOST_LIB_TOOLSET "vc142" This corrected the linker errors on my machine. I'm happy to submit this properly but thought I'd check it with folks here first. Chris. INTELLICORP LEGAL NOTICE: This E-Mail message and all attachments transmitted with it are intended solely for the use of the addressee and may contain legally privileged and confidential information. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution, copying or other use of this message or its attachments is strictly prohibited. If you received this message in error, please notify the sender immediately by replying to this message, and then delete it.

1 1

GSoC'19 [Boost.Geometry : Implementing algorithms for the concave hull problem]
by yaghyavardhan singh khangarot 06 Apr '19

06 Apr '19

Hi, I am interested in contributing to Boost.Geometry and would like to work on the Project 1 (Implementing algorithms for the concave hull problem) as my GsoC’19 project. I had some discussion regarding this with Adam Wulkiewicz. I have read the paper ( Moreira, Adriano J. C., and Maribel Yasmina Santos. “Concave hull: A k-nearest neighbors approach for the computation of the region occupied by a set of points.”) and currently going through the paper “A New Concave Hull Algorithm and Concaveness Measure for n-dimensional Datasets*” ( https://www.iis.sinica.edu.tw/page/jise/2012/201205_10.pdf )) . These are the papers given in the project description. I am also searching for any other algorithms (newer or better) for the concave hull problem. Please direct me to any other algorithms related to this project. Regards Yaghyavardhan

2 3

[GSOD19] Mentors registration
by Damian Vicino 06 Apr '19

06 Apr '19

Hi, I started the registration process for Google Season of Docs, please contact me if you want to mentor to do the formalities. Each documentor requires 2 mentors in GSOD, so the work will be collaborative. Best regards, Damian Vicino

2 2

Re: [boost] [Boost-users] [release] Boost 1.70.0 Release Candidate 1 available
by Tom Kent 04 Apr '19

04 Apr '19

On Thu, Apr 4, 2019 at 9:27 AM Marshall Clow via Boost-users < boost-users(a)lists.boost.org> wrote: > The release candidates for the 1.70.0 release are now available at: > <https://dl.bintray.com/boostorg/release/1.70.0/source/> > > The SHA256 checksums are as follows: > 6e5cba1269225395bb5e78dda48441ccadaf745e42638180015e9e6257068336 > ./boost_1_70_0_rc1.7z > 35d8e1361e2063f70aa3a6ca0dd8af0877ceb75477ebbd2c726bb1d039658c7a > ./boost_1_70_0_rc1.tar.bz2 > ec8ddbbee2fd61e2f78a1dfe9a07ad83ca8f6a2f4c704d6f297d89c6afdc4f2c > ./boost_1_70_0_rc1.tar.gz > ee2c3b97ce10f85a31b6a105ad8edf1c20fb4b936c9a6e6008206059cb98ab1b > ./boost_1_70_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. > Windows/Visual Studio (msvc 10.0, 11.0, 12.0, 14.0, 14.1) builds look good. toolset arch compile Link Execute msvc-10.0 32 X X X msvc-10.0 64 X X X msvc-11.0 32 X X X msvc-11.0 64 X X X msvc-12.0 32 X X X msvc-12.0 64 X X X msvc-14.0 32 X X X msvc-14.0 64 X X X msvc-14.1 32 X X X msvc-14.1 64 X X X Compile means that the b2 command completed without errors Link means that visual studio was able to link a sample executable to a library (libboost_thread-vcXXX-mt[-gd]-1_XX.lib) generated Execute means that the linked program executed without errors. Full build logs can be found at: https://gist.github.com/teeks99/798df332c12ec98708e3710da35dd606 Tom

2 1

[variant2] Andrzej's review -- design
by Andrzej Krzemienski 04 Apr '19

04 Apr '19

Hi Everyone, First of all, I wanted to thank Peter for writing this non-trivial library and sharing it with the community. This is not a full review yet. I just wanted to discuss the design first, especially the never-empty guarantee. And I am going to rehash the old argument. The core of variant2 is its never-empty guarantee and the mechanism to achieve it: a number of different algorithms chosen depending on what the potentially stored types permit. In fact this mechanism is not much different than the one present in boost::variant. The issue to solve is what happens in copy/move assignment of variant<X, Y> when we have to change the stored type from X to Y. X has to be destroyed and Y initialized. But if the initialization of Y throws we would be left without either X (already destroyed) or Y (not successfully constructed). (The same problem applies to member function emplace()). Except for the last step boost::variant and variant2 try to apply the same sequence: 1. If all the subtypes have noexcept initialization, no safety measures need to be taken. 2. If sub-types have noexcept move constructor, a temporary local storage is used and the backup value is moved to and from it. 3. If one of the subtypes is a special type boost::blank or std::monostate respectively, in case of a throw this type is default constructed in the variant. 4. If there is any nothrow-default-constructible subtype in the variant, it gets default-constructed upon exception. If neither of the above can be applied, the two libraries apply different approaches. variant2 is big enough to fit two unions of X and Y within its storage. This way it does not have to destroy the X when initializing the Y. boost::variant, for the additional storage uses heap allocated memory. Interestingly, the double storage as in variant2 has been considered in the initial design of boost::variant but rejected by the community, because it added spacial overhead even for use cases that never invoked variant's assignment. This is described in the Rationale section of boost::variant documentation: https://www.boost.org/doc/libs/1_69_0/doc/html/variant/design.html#variant.… In boost.variant, only these programs pay for the overhead that really invoke the assignment operator. Neither of the solutions seems strictly superior than the other. The double storage could be thought as better because it seems to be able to cover use cases where heap allocations are banned altogether. On the other hand, in these applications it is difficult to imagine that X and Y would be throwing exceptions in move constructors or during initialization. One inferiority of boost::variant is that it can fail for its own reasons unrelated to failures of X and Y. Even if no operations on X and Y throw during the assignment of variant, the variant can still throw because it allocates memory. Some people believe that an application cannot recover from bad_alloc anyway, but this is not a universally held view. To me, the important question is, do we really need the never-empty guarantee. It was an unquestionable requirement for the initial design of boost::variant. Now, variant2 is advertised as an allegedly superior solution to std::variant, because the latter does not provide the never-empty guarantee, even though the cost of providing it is significant. But I myself fail to see the *practical* value of the never-empty guarantee. The argument I hear is that, we want to make it an invariant that either X or Y is stored in variant. I agree with this goal in general, but the costs and contortions required to satisfy it outweigh the benefit. Now, I hear that if the invariant is weakened everyone will have to check everywhere if any variant is in a valueless_by_exception state. This seems to be confirmed by the semantics of std::variant::visit(), which requires that valueless_by_exception is checked and an exception thrown on valueless. This last part is indeed strange in std::variant, but I do not agree that the fix is to provide a never-empty guarantee at the cost of compromising run-time performance and complicating the design. I can think of the following alternative design. The invariant of a variant (pun intended) allows for a valueless_by_exception state. There is no way to get to this state other than by throwing form the initialization of Y in variant's assignment or .emplace() operation. Calling .visit() on a valueless variant is UB. The destructor and reset functions such as assignment and .emplace() can handle the valueless state. This is almost what std::variant does except for UB in .visit(). Why I find this superior to variant2. 1. It is simpler, faster and smaller. 2. Observing the valueless state can only happen when somebody is handling exceptions incorrectly. And in that case this is exception handling strategy that needs to be fixed: not the variant's guarantees. It should be noted that variant2 DOES NOT PROVIDE A STRONG EXCEPTION SAFETY GUARANTEE. The never-empty guarantee has a certain negative effect of confusing people so that they are led to believe that they have strong exception safety. But they don't. even expert programmers in this forum expressed their surprise that changing from X to Y in variant<X, Y, Z> can get them a variant storing Z. Sometimes it is even trickier: X may be a container that currently stores 10 elements. You assign Y, and after the exception you get an X that stores zero elements. Because of these problems, the only reasonable thing to do is to follow the advice from Dave Abraham's article: https://www.boost.org/community/exception_safety.html To quote the relevant part, "If a component has many valid states, after an exception we have no idea what state the component is in; only that the state is valid. The options for recovery in this case are limited: either destruction or resetting the component to some known state before further use." If this principle is followed no-one will ever observe the valueless_by_exception state. This also applies to variant2. If this principle from Dave Abrahams is followed, no-one will ever benefit from the never-empty guarantee (but people will still pay the costs of providing it). You cannot do anything meaningful with variant that threw other than destroy or reset it. (But it is probably best to destroy it.) If objects are allowed to survive the stack unwinding, they should either offer a strong exception safety guarantee, or you have to have some very detailed knowledge of a given particular type how its state gets modified under exceptions, but this is usually very difficult and best left to experts. I have started a thread in this list a while ago, requesting for an example of code that *correctly handles exceptions* (does not stop stack unwinding at random places), where the programmer would make use of the never-empty guarantee , and chose something else than destroying or resetting the variant. And although I received some generic statements, referring to the purity of the design, strength of the invariants, and the easiness of thinking or "correctness", none of the proponents of the never-empty guarantee gave such an example. Which might be an indication that the problem we are solving may be nonexistent. I am not sure of this claim, but I have not seen any convincing example either. I believe that we are facing one of this problems where the strong invariants of the type need to be weakened due to practical considerations. I can see no correctness issues with valueless state other than in programs that are already exception-unsafe. Also, I have heard claims that if someone is fine with valueless state they should put std::monostate as one of the types and the same effect without double buffering is achieved. But this is not true. Variant with monostate can get the degenerate state in a correct program; often: in the variant constructor. Now I really have to special-case it whenever I inspect the variant object, which is a nightmare: this is really a weak invariant in an allegedly strong-invariant variant. In contrast, for std::variant you only get the valueless state in the program that incorrectly handles exceptions: no need to special-case the valueless_state when doing visitation.. variant2 is not a replacement for std::variant, as the choice to support never-empty guarantee at the cost of more expensive operations and increased object size is not necessarily superior. Even if my view is not generally held, it has to be acknowledged that the issue is controversial. Variant2 cannot replace boost::variant either. This is not only about supporting pre c++11, but also for different trade-offs in never-empty guarantee, which were deemed inferior in boost::variant design. variant2 is ismply a third point in the multi-dimensional design space of different trade offs for variant-like libraries. On a different subject, one thing that is missing from both: boost::variant, and std::variant, is the narrow-contract observers for the specific stored type, useful when I know by other means what is currently stored in the variant object. This is something the third variant implementation has a chance to change, however it chose to follow its predecessors. This seems somewhat counter to the spirit of C++. We requested a similar thing of Niall's Outcome library, and the narrow-contract observers were added. Below is the comparison between boost::variant, std::variant and variant2. I do not know how to make a table in the email discussion interface, so I will have to make it with a list. 1. Works in pre-c++11 dialects * boost::variant: yes * std::variant: no * variant2: no 2. Size of variant<X, Y> (when X and Y are unfriendly) * boost::variant: sizeof(void*) + SXY (SXY is the size of union{X x; Y y;}) * boost::variant: sizeof(int) + SXY * variant2::variant: sizeof(int) + 2 * SXY 3. Uses heap allocations * boost::variant: yes * std::variant: no * variant2: no 4. Throws its own exceptions in assignment * boost::variant: yes * std::variant: no * variant2: no 5. Fast (narrow contract) access to X alternative. * boost::variant: no * std::variant: no * variant2: no 7. Strong exception-safety guarantee * boost::variant: no * std::variant: no * variant2: no 8. Never-empty guarantee * boost::variant: yes * std::variant: no * variant2: yes 9. Throws its own exceptions in visitation * boost::variant: no * std::variant: yes * variant2: no Regards, &rzej;

5 19

[variant2] Andrzej's review -- design
by Mike 04 Apr '19

04 Apr '19

> Every time you touch a variant object, you must consider the possibility of it being valueless.Â No I don't. It just works and I explained why. Could you please point out specifically where I made a mistake in my reasoning in the mail before where I discussed the behavior of all member functions? And again: I'm not arguing that one is better than the other. I'm saying it doesn't matter, but I'd much perfer a design that is in line with std::variant instead of having yet another slightly incompatible version of variant that doesn't offer any significant benefit (would be a different story if it would always offer the strong exception guarantee).

2 1

Regarding Boost.Astronomy GSoC19
by sarthak2007 04 Apr '19

04 Apr '19

Hello, For the competency test I had used quantity<length> of boost::units in place of double to store the values of coordinates with their units. But in project we have to deal with boost::geometry. One way it can be done is that whenever we use functions for dot product, cross product, etc. directly from boost::geometry then we just pass the values of coordinates in them instead of units. There will be no problem considering units in calculations as boost::units convert the values stored into SI units so all the calculations will be involving coordinates with SI units. But then we will have to change the way of storage of coordinates as boost::geometry can't be used to store coordinates(with units) as it does not support units. Is it the right approach or there is some nicer way to implement this? Thank you, Sarthak Singhal -- Sent from: http://boost.2283326.n4.nabble.com/Boost-Dev-f2600599.html

2 1

[gsoc 19]proposal to project 1 Boost.GIL
by raghuchandra kanakamedala 04 Apr '19

04 Apr '19

Hi my proposal link: https://docs.google.com/document/d/1-BZO0VuIcebe1ZcdyxHGjOEkQL3eeaXwGtKCWyQ… .Please suggest me any changes if required. Thanking you K RaghuChandra

2 2

variant - off topic
by Robert Ramey 04 Apr '19

04 Apr '19

I've been and observer on the discussions regarding variant, expected, outcome, optional, outcome and ?? for sometime. I'm pretty amazed at the amount of controversy each and everyone of these in every forum - here, C++ committee, etc. I'm beginning to wonder this isn't telling us something. It seems natural that when making a new C++ data type, we should want to implement the assignment operator. Why - well every variable needs to be assigned to from time to time. Why is this so? Well ... Suppose we break this assumption and consider the idea that assignment doesn't make sense for every type. A variant is a "meta-type" or "sum type" which "holds" one of a set of other types. Such a variant can take on the character of any one of type types it is holding. When does it make conceptual sense for a variable to change it's type one it has been initially assigned. I've been trying to think of one and haven't been successful. Here are a few of the scenarios I've considered. a) Returning a sum type - the most common scenario for a variant. Doesn't require a assignment. Copy/move may still be required of course. b) looping through a vector of variants as in vector variant<...> v; for( variant<...> v : [](){...} fix with change to vector variant<...> v; for( variant<...> & v : [](){...} c) set according to condition variant<...> r; if(i < 0) r = v<t1>(...) else r = v<t2>(...) fix with change to variant <...> r = (i < 0) ? v<t1>(...) : v<t2>(...); d) insert your own use case here. That is, look at your own usages of assignment to these types and see if there is not an easy way to re-factor your code to avoid assignment. I'll concede that, influenced by functional programming style, with a little experimentation with F# and propaganda from the Haskell community, I've become accustomed to code in the above way. Also I've become afraid to assign anything to these types. The discussion has made me aware of a raft of unintended consequences of doing what on it's surface seems a trivial operation. I've gotten to the point that assignment to a variant type, or "changing the type" of a value at runtime is not code smell to me. Maybe all this could be just eliminated if this became the accepted position. Of course I realize that by engaging in the practice I do, the whole issue becomes irrelevant to me personally. And I can always create variant types as "const". It's not about that. It's about avoiding the creating of vocabulary types which lead to problems. So - simple proposal. Require that sum types have operator= deleted. Robert Ramey

3 5

[variant2] never-empty guarantee, again
by Andrzej Krzemienski 04 Apr '19

04 Apr '19

wt., 2 kwi 2019 o 22:59 Peter Dimov via Boost <boost(a)lists.boost.org> napisał(a): > Andrzej Krzemienski wrote: > > > Can you show a destructor like that, does a visitatoin on a variant, and > > that you wouldn't be ashamed to put in your program? > > The destructor doesn't have to do visitation. It merely needs to call a > function f1, which calls a function f2, which calls a function f3, which > calls a function f4, which does visitation. > > What we've been telling you from the start is that this forces you to > partition your functions into two classes, one allowed to do visitation, > the > other not, then keep track of which is which, never calling the wrong > class > in a destructor, or from a catch clause. > The fact that I have to partition all functions into two categories isn't new or surprising. When defining an operation that needs to provide a strong exception-safety guarantee I need to some use operations that offer no-fail guarantee. So I need to be aware which operations offer no-fail guarantee and use only those. I do the partitioning, and I need to be cautious. When I define the destructor, again I do not have the liberty to use any function I can use in other parts of the code. In destructor I can only use functions that do not signal failure through exceptions if they fail. And not signalling failures is ugly on its own, so I am inclined to also just use functions that cannot fail. I have to do the partitioning again. When I try to go back and recall how the destructors I write look like, they fall into three categories: 1. Some types just aggregate other types. The implicitly defined destructor only calls the destructors of subobjects. 2. Sometimes I need to provide a RAII interface for a system resource or a C component. In that case my implementation uses only ints and pointers and system calls. When defining the destructor, I have confidence that there are no unexpected types hidden by templates, or functions with unexpected types with unpredictable guarantees. 3. When I define a generic component, such as optional<T>, in my destructors the only operation on the unknown type T is to call its destructor. Other operations in the destructor are performed on concrete types with no-fail guarantee such as `bool`. The situation is no different for std containters: for T, they only call destructors, other operations are on concrete types: pointers, memory deallocation. No way a variant or other unexpected type could get there, even indirectly. I know people are using destructors for other things, like committing the DB transaction, but this is what I call bad exception handling. Such implementations are usually incorrect: either you do not report failures in such case, or you are reporting failures when there is none. Your example of a destructor, to me, also falls into this category: template<class T> class monitor > { > char const* file_; > int line_; > T const& v_; > T old_; > > public: > explicit monitor( char const* file, int line, T const& v ): > file_( file ), line_( line ), v_( v ), old_( v ) {} > > ~monitor() > { > if( v_ != old_ ) { > std::clog << file_ << ":" << line_ > << ": monitored value changed from " > << old_ << " to " << v_ << std::endl; > } > } > }; It calls operations on an unknown T that could fail and throw: comparison, streaming. Streams themselves could throw. Such implementation has other problems before we even consider a variant. And, of course, this has nothing to do with visitation, specifically. The > exception safety guarantee is a global thing. Once you lose basic, you lose > it everywhere, not just for visit. > Why are you mentioning "basic" (guarantee) here? In the vision that I propose variant offers basic guarantee. It is just that the invariant is weaker. This is analogous to a (potentially smart) pointer: normally you can call `*p`, but sometimes (on nullptr) it is UB, so you may need to check what state it is in. Regards, &rzej;

2 2

Boost commercial support policy
by SOCIPROJECT 04 Apr '19

04 Apr '19

Hi,Good day.  This is Shuvransu Banerjee, development manager at Ushamartin Technologies. We build software products on Telecom Billing.We are at the planning level and thinking about using Boost in our legacy code. We have the following queries: Can we use Boost commercially? Is there any support available? If yes, then please let us know the various options for support.Thanks & Regards,Shuvransu Banerjee

2 1

B2, transition to C++
by Rene Rivera 04 Apr '19

04 Apr '19

After six months of, slowly, working towards this I can now say that the C++ compiled version of the B2 engine is ready for use. As such I plan, if there are no objections from Steven Watanabe and Vladimir Prus, to merge the result into the develop branch shortly after the 1.70 release. The history note accompanying this "new" engine version goes like this: === Version 4.0.0 After even more years of development the landscape of build systems has changed considerably, and so has the landscape of compilers. This version marks the start of B2 transitioning to a C++ implementation. Initially this means that the engine will be compiled as C++ source but that source is still the base C implementation. Over time it will transform to a C++ code base in both the engine and build system. Some changes in this start: * Requires C++ 11 to build engine. * Simplified build scripts to make it easier to maintain. * Building with C++ optimizations gives an immediate performance improvement. === There will obviously be bumps on the road when that merge goes in. As the C++ 11 requirement might require some changes for testers and users. But hopefully they will be minor. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net

2 1

Re: [boost] [variant2] Review of Variant2 started today : April 1 - April 10
by Peter Dimov 03 Apr '19

03 Apr '19

> Andrey Semashev wrote: > > Also, IMHO, it's better to have libraries more focused and fine grained. > > Why not have `expected` as a separate library? > > expected<T, E...> is basically a variant, with a slightly different > interface. To expand on that a bit... to implement expected<T, E...> you need an underlying variant. You can either implement your own ad-hoc one, which is a duplication of work; or you could use an existing variant, but then you inherit its properties and have to reflect those in the specification of `expected`. For instance, if the variant can be valueless, you need to figure out what to do in `expected` when it gets into that state. For those reasons, it makes most sense to develop `variant` and `expected` in parallel, as parts of the same library.

4 4

Master branch for 1.70.0 closes today!
by Marshall Clow 03 Apr '19

03 Apr '19

We're still in the post-beta phase, so please refer to < https://github.com/boostorg/boost/wiki/Releases%3A-Beta-Merge-Policy> -- Marshall

2 2

[gsoc19] Interested in Boost.Geometry PROJECT 2 (Support for non-cartesian)
by rika 03 Apr '19

03 Apr '19

Hi! I'm Rika from Japan, currently in 4th grade in the University of Tokyo. I'm going to take part in GSoC 2019, and interested in Boost.Geometry PROJECT2 - "Implement support for non-cartesin geometries in convex_hull()" I've already done a competency test, and writing a project proposal. [Competency test] https://github.com/rika77/boost I'm seeking for a mentor for this project. I also have 1 technical question & 1 general: 1. I'm afraid to ask, but what algorithm is currently used in convex_hull()? I read algorithms/convex_hull.hpp carefully, but I couldn't find out. 2. On GSoC GitHub page, there are 4 projects on Boost.Geometry, but are only 2 potential mentors. I guess that only 2 students are chosen, right? I just want to make sure. Thanks, Rika -- Sent from: http://boost.2283326.n4.nabble.com/Boost-Dev-f2600599.html

4 3

Master branch open for merging
by Marshall Clow 03 Apr '19

03 Apr '19

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> -- The Boost Release Team

11 48

[gsoc19] late application for Boost.SafeFloat
by Thomas Ferrand 03 Apr '19

03 Apr '19

Hello, I am a student and I am interested in taking part of GSoC this summer. But I am a little late as the application are due to next week so I was wondering if I could still take part. The project I am interested in is Boost.SafeFloat, mentored by Damian Vicino. As for the competency test, it has already been taken care of as I believe it is the same that last year and I completed it then https://github.com/aTom3333/boost_competency_test/ Thomas Ferrand

4 4

Boost.Python
by Siddhartha Sen 02 Apr '19

02 Apr '19

Boost.Python does not have any added projects as of yet. I have completed my competency test and have a couple of ideas of my own.Need a potential mentor to discuss them with and review my proposal. Thanks.

2 1

[gsoc19] looking for mentor
by Aziz Mousa 02 Apr '19

02 Apr '19

hi, I have my idea to contribute in boost project, I read the boost libraries list and see that the author of Algorithm is "Marshall Clow" I want to know how to contact with him to tell him about my idea. thanks.

1 0

[gsoc][gsoc19] Communication between students and mentors
by Mateusz Loskot 02 Apr '19

02 Apr '19

Hi, Are there any guidelines related to communication between students and mentors during GSoC? Many participating organisations and projects do explicitly recommend that student/mentor communication is conducted via public channels. e.g. https://docs.moodle.org/dev/GSOC """ Note: With regards to the communication culture in the Moodle project: We always prefer transparent communication in public forums and tracker comments over private messages and emails. Please respect this and avoid contacting GSOC admins and mentors directly unless you really need to talk about something sensitive or personal. """ or at least regular/weekly reports to dedicated and project-specific list https://wiki.osgeo.org/wiki/Google_Summer_of_Code_Recommendations_for_Stude… Would it be possible to ask for similar transparent mode during Boost GSoC? I do realise one challenge is that Boost mailing list traffic could increase a lot, too much for some subscribers. Perhaps a solution to that could be setting up dedicated lists: gsoc(a)lists.boost.org or even <library>@lists.boost.org Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

2 2

(no subject)
by Aziz Mousa 02 Apr '19

02 Apr '19

hi, I submit my proposal draft on GSoC and I want to know how to meet a mentor to see my proposal.

3 2

[gsoc19] Seeking a mentor for Boost.GIL project
by Igor Antropov 02 Apr '19

02 Apr '19

DearSir/Madam, My name isIgor Antropov and I would like to participate in GSoC 2019.I amfirst-year undergraduate master majoring in Software Engineering at ITMOUniversity (Saint Petersburg National Research University of Information Technologies,Mechanics and Optics).I aminterested in computer vision and C++. I have made AR-application using Unityand OpenCVForUnity at my third-year of bachelor degree. Unfortunately, thatOpenCVForUnity was based on OpenCV version 2.1 or smaller and was the only onefree to use. There was no algorithm for markers detection, so I had to codeit. At the fourth-year, I have implementobject tracking algorithm with C++ and OpenCV using HOG features and colornames features. Additionally, I havebeen working as programmer with Qt for 1 year. I aminterested in implementation of different algorithms using GIL, so I propose toimplement some image feature detection and matching algorithms. For example,ORB keypoints detector(http://www.willowgarage.com/sites/default/files/orb_final.pdf) and brute-forcematching. Besides, I think Boost.GIL numeric algorithms can have some improvements (add 2D convolution, add convolve_option_extend_reflect as convolve_boundary_options). If Boost.GIL users need some other algorithms to be implemented,please contact me. As my competencytest, I have implement a simple Canny edge detection algorithm using GIL. https://github.com/boostorg/gil/pull/258 Sincerely, IgorAntropov

2 1

[GSOD] Looking for mentors and projects
by Damian Vicino 02 Apr '19

02 Apr '19

Hi, I'm starting preparing the application for Google Season of Docs 2019. I created a wiki page to start collecting project ideas here: https://github.com/boostorg/boost/wiki/Google-Season-of-Docs-2019 Instruction of how to write a project idea are here: https://developers.google.com/season-of-docs/docs/project-ideas Please add any idea you have, even if you are not able to mentor it, someone else may volunteer for it. Best regards, Damian Vicino

4 4

[gsoc19] Seeking a mentor for Boost.Geometry project related to triangulation and random sampling
by Tinko Bartels 01 Apr '19

01 Apr '19

Hi, I am interested in participating in this year's Google Summer of Code with a contribution to Boost.Geometry. I am looking for mentors and I understand that potential mentors for Boost.Geometry-related projects are Vissarion Fysikopoulos and Adam Wulkiewicz. My proposal is a project that is based on project 3 and 4 for Boost.Geometry in the Wiki. I propose to add concepts for triangles, triangulation, and point-generators for random sampling, as well as corresponding models and an algorithm for Delaunay-triangulation with parametrizable geometric predicates. The first draft of my proposal can be found here: https://docs.google.com/document/d/17M44Hpn0KMuECztCbkvTYIeN2EiXbMAUsVni22K… My implementation of the tasks in the competency tests can be found here: https://tinko92.github.io/boost_geometry_GSoC_2019_project_3_4_test/ I'd be thankful for any feedback. Kind regards, Tinko Bartels -- Sent from: http://boost.2283326.n4.nabble.com/Boost-Dev-f2600599.html

3 10