- Boost - lists.boost.org

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