- Boost - lists.boost.org

[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