- Boost-users - lists.boost.org

[geometry] Get points within certain radius?
by Florian Lindner 03 Oct '17

03 Oct '17

Hello, first of all thanks for the repliest to my previous geometry question! What is the best, especially fastest way to get all points within a certain radius of a point? Using the iterator method with nearest(pt, X) highly depends on X. Since I don't know this number, I have to guess it rather high. for (auto it = rtree.qbegin(bgi::nearest(point, results)) ; it != rtree.qend() ; ++it) { std::ignore = it; break; } results = 10 => time = 3.0s results = 100 => time = 22.6s results = 200 => time = 71.4s results = 300 => time = 153.2s though I always use just one result. The loop is inside another loop, not depending on results, so of course, the times are multiples of the actual times for that query. But clearly, choosing high numbers for results is not feasible. Another idea is to use the within() query with a circle of a radius. But bg seems to have no circle or sphere model. A workaround would be to use a box instead of a sphere. That means I have to test the results again, whether they are actually contained in th sphere. Alternatively, I could use the satisfies predicate. But wouldn't I give up all spatial information? This predicate needs to compare all vertices, don't it? It does include the knowledge, that when one point is discarded, all other points with a greater distance will discarded too. According to https://stackoverflow.com/questions/22909171/boostgeometry-nearest-neighbor…, the way to go seems to be to combine within(boundingBox) and satisfies(). Any other ideas? Thanks, Florian

2 1

[test] Is standalone use possible?
by Adam Nielsen 02 Oct '17

02 Oct '17

Hi all, I'm in the process of trying to remove the Boost dependency from my project, as it is causing too many difficulties for non-developers trying to run my code. This has been mostly solved by switching to C++11 and using the std:: implementations instead, however rather than rewrite all my unit tests I am hoping I can use a standalone version of Boost.Test, and distribute the code alongside my own. Unfortunately I am not quite sure how to extract the Test library out of the main Boost distribution. I have compiled "bcp" and used it to copy "test" into a new folder, but it seems to copy a huge chunk of Boost as well, including a bunch of libraries (system, thread, date_time, etc.) and I end up with 29 MB of source files, which seems wrong (especially considering my own codebase is barely 500 kB). Am I doing something wrong? I was hoping to use the header-only version of Boost.Test and this does seem to work when I #include the system-wide version of Boost (and don't link to any libraries), so it would seem that I don't need all those libraries that bcp copies. Is there any other way to access a slimmed-down standalone version of Boost.Test? Many thanks, Adam.

6 12

ק
by Ami Tavory 29 Sep '17

29 Sep '17

1 0

Enhancing the boost::asio::connect() socket interface
by martin doc 29 Sep '17

29 Sep '17

(apologies if this should be on -developers...) The connect() interface provided by boost caters to most common use and through access to the socket, various options can be managed without much hindrance. But there's one situation that boost does not handle well - when it is desirable to specify the local address to bind to. Going back to C, the usual program flow in this situation is something like this: fd = socket() bind(fd, local ip address) connect(fd, remote ip address) As boost::asio::connect() closes an open socket passed to it before making the remote connection, it's not possible to pass connect() a prebaked socket. In fact the amount of code required to use boost when binding a socket to a local address is more complicated than simply not using boost. What I'd like the boost community to consider is extending boost::asio to provide one or more variants of connect() that allows for a local endpoint (whether or not as an iterator I'll leave to others to debate but this isn't necessary - and then there's the M*N behavior or paired to decide) to be supplied in addition to the remote endpoint. I suppose I'm open minded as to whether or not the local address is supplied as an Iterator/endpoint as an extra arg or whether connect() is adopted to take endpoint pairs. Thoughts?

5 4

Analogous to DESTDIR for Boos installation
by Leo Cacciari 29 Sep '17

29 Sep '17

Hi, I need to prepare a binary distribution of Boost for deploying on company hosts. For this, I need to configure libraries with a prefix of say /usr/local, doing as per documentation ./bootstrap.sh --prefix=/some/path where /some/path is the actual path where the libraries and header flles will be installed on the various hosts. To prepare the package to be distributed (the actual packaging system used is irrelevant here, simply assuming a tar.gz would do) I need, however, to "install" everything under some other path, say /path/to/package/content. When using gnu packages, I usually do something like ./configure --prefix=/some/path make make DESTDIR=/path/to/package/content install and then I can prepare and distribute my package. I'm unable to find an analogous procedure for Boost. More exactly, I do not found a way to invoke the install phase of b2 with a different prefix than the one specified to the stage phase through the --prefix options to boostrap.sh I solved the problem in a unsatisfactory way by manually copying the files from both the source and the build directory to the content folder, but I'd really like to have an automated way to do it. Is this possible? If yes, how? And if not, does anyone have a better idea than manual copying? Thanks for the help -- Leo Cacciari Aliae nationes servitutem pati possunt. Populi Romani est propria libertas.

2 1

[review] The review period of Boost.DoubleEnded has been extended with one week. Now ends 7th of October.
by Thorsten Ottosen 28 Sep '17

28 Sep '17

Dear users and members of Boost, People have been requesting extra time for the review of Boost.DoubleEnded. We therefore continue one week extra, so the final date will be October the 7th. kind regards Thorsten Original review announcement ------------------------------------------ I'm proud to announce that the formal review of Benedek Thaler's Boost.DoubleEnded library starts today, September 21, and runs through September 30. This library is the result of Benedek's participation in Google Summer of Code 2015. The library may be downloaded from https://github.com/erenon/double_ended and the documentation may be found here: http://erenon.hu/double_ended/ Anyone is welcome to post a review and/or take part in subsequent discussions (see below for review guidelines). Introduction ------------ This is a container library that provides two containers: A. boost::devector B. boost::batch_deque Both containers provides efficient push_front and push_back operations, hence the name DoubleEnded. The boost::devector class can be seen as an extension of std::vector with efficient support for push_front (so boost::devector provides contiguous storage). In addition, it provides a customizable small buffer optimization like boost::small_vector(*). It furthermore allows for customization of the growth factor such that the user can decide if a reallocation should allocate 1.5 or 2 or whatever more memory. And finally it provides new functionality that does not exist in normal vector implementations -- this functionality allow the class to excel in performance in certain situations like serialization or transfer of data from sources that require a preallocated buffer. The boost::batch_deque is similar to std::deque, but with two important twists. Like std::deque, it provides reference stability when calling push_front/push_back. Reference stability is crucial for programs that uses intrusive containers e.g. using Boost.Intrusive (**). boost::batch_deque has the following main advantages: 1. It allows the user to specify the segment size 2. It allows for external iteration over the segments Taken together, they provide a very efficient and flexible basis for intrusive containers. Access to the segments also increases performance for tasks such as serialization. Finally, boost::batch_deque may be seen as an efficient alternative to std::vector if you want to replace a percent-wise memory overhead with a constant memory overhead and have no need for contiguous storage. Review guidelines ----------------- Please provide in your review whatever information you think is valuable to understand your final choice of ACCEPT or REJECT including Boost.DoubleEnded as a Boost library. Please be explicit about your decision. Some other questions you might want to consider answering: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With which compiler(s)? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? More information about the Boost Formal Review Process can be found here: http://www.boost.org/community/reviews.html Kind regards Thorsten, Review manager (*) boost::small_vector: https://tinyurl.com/ycslp4ot (**) http://www.boost.org/doc/libs/1_64_0/doc/html/intrusive.html -- Best regards, Thorsten Jørgen Ottosen, Ph.D. Director of Research +45 23308797 Dezide (www.dezide.com)

1 0

[geometry] Runtime dimensionality
by Florian Lindner 28 Sep '17

28 Sep '17

Hello, I just started yesterday looking into boost.geometry to use on our own legacy system of Vertices (Points) in Meshes. I'm quite impressed how easy it is to adapt to existing code and got it working (with some workarounds) really quick. However, some problems remain. We have a Vertex object, with a dimension determined at runtime. The actual position is saved as VECTOR_T (usually an Eigen::VectorXd (double vector of arbitrary dimension)). One can get the coordinates using "const Eigen::VectorXd& Vertex::getNormal()" I was able to adapt to geometry by adding getters/setts for the dimensions: double getX() and getY() and BOOST_GEOMETRY_REGISTER_POINT_2D_GET_SET(mesh::Vertex, double, cs::cartesian, getX, getY, setX, setY) and it works! But in theory the vertices can be of arbitrary dimension, in practice it's usually 1, 2 or 3. What is the best way to adapt our Vertex object to geometry? - Change our Vertex so that it meets the model::point requirements. It worked so far, for the access I use: template<size_t Dimension> struct access<Vertex, Dimension> { static double get(Vertex const& p) { return p.getCoords()[Dimension]; } static void set(Vertex& p, double const& value) { Eigen::VectorXd vec = p.getCoords(); vec[Dimension] = value; p.setCoords(p); } }; In our code we rarely set the entries of an vector, so the code is a but ugly. Will likely change that to a compile-time get<Dim>() as a member of Vertex. My biggest problem is the dimensionality template<> struct dimension<Vertex> : boost::mpl::int_<2> {}; but I have no idea currently how to get that for an Eigen::VectorXd at compile-time? Do you have any idea? Thanks! Florian

5 8

Problem updating code to boost 1.64
by Tim Burgess 26 Sep '17

26 Sep '17

Hi, I have an application that I'm resurrecting. I originally coded it using Visual Studio 2010 with the boost that was current at the time (not sure what version that was). The following line of code used to build fine: if (CurrentAction[ 0].As <std::wstring>().compare( wstrFunctionName) == 0) With my current boost 1.64, I get the following error: >c:\users\tim\projects\surfacereader\screenreaderfunctionsdlg.cpp(146): error C2039: 'As': is not a member of 'boost::any' The intent of the code is as follows: If CurrentAction[ 0] (which is a boost::any) contains an std::wstring value, compare it to wstrFunctionName. Can anybody offer some guidance, please? Best wishes. Tim Burgess

2 1

[review][Fit] Review Results
by Matt Calabrese 24 Sep '17

24 Sep '17

Hello everyone, It is my privilege to announce that the Boost library count will once again be incremented as Paul Fultz II's library Fit has been accepted into Boost without conditions. Further details about this decision follow, but before that I'd like to thank Paul for all of the hard work he has put into Fit. Thanks also to everyone who participated in the review, with additional thanks to Vicente who was the review manager for the previous Fit review and who also provided a very detailed review and discussion during this review period. //////////////////////////////////////////////////////////////////////////////// Overview //////////////////////////////////////////////////////////////////////////////// Complete Reviews Considered: Zach Laine: Accept Vicente J. Botet Escriba: Accept John P. Fletcher: Accept Robert Ramey: Accept Jason Rice: Accept Barrett Adair: Accept Lee Clagett: Accept Glen Fernandes: Accept Louis Dionne: Accept Partial Reviews/Discussions Considered: Edward Diener Andrea Bocci Further Discussions (Previous Review): Steven Watanabe Peter Dimov Vladimir Batov Gavin Lambert Rob Stewart Bjorn Reese Manu Sanchez Artyom Beilis //////////////////////////////////////////////////////////////////////////////// Summary //////////////////////////////////////////////////////////////////////////////// Though not all responders reviewed every single aspect of the library, the reviews together adequately covered everything that is necessary for a decision to be made. This decision is made with additional confidence coming from usage of the library by some reviewers going back since during or before the initial review in early 2016. //////////////////////////////////////////////////////////////////////////////// Improvements Since Previous Review //////////////////////////////////////////////////////////////////////////////// This time around we received several more complete reviews than in the previous review period making it easier to be confident in a decision. A couple of notable changes since the 2016 review include: * Improved documentation * Default semantics for "capture" no longer try to determine whether to capture by reference or by value based on the argument being an lvalue or an rvalue (users can still get this via basic_capture) * Improved ADL awareness (internal calls are qualified) Throughout all of the discussions in this second review period, there were no explicit rejections of the library as a whole, though there were several recommendations from participants. A selection of those are listed here, though no changes are strictly required for acceptance: //////////////////////////////////////////////////////////////////////////////// Current Concerns //////////////////////////////////////////////////////////////////////////////// ////////// Design concerns: * Inheritance from user-callables has some potential pitfalls * Generated "infix" operators are "gimmicky" and don't add much value/may cause confusion * Placeholders should live in their own namespace ////////// Documentation concerns (not a complete list): * More examples requested * It is not always clear what files need to be #included for certain facilities in early examples * Better rationale for ConstFunctionObjects * Raw code is not linked from the examples ////////// Suggested name changes from reviewers: * Suggested rename of "partial()" to "partial_apply()" or "curry()" * Suggested rename of "conditional()" to "invoke_first()" or "call_first_of()" * Suggested rename of "apply" to "invoke" * Refer to "Callables" instead as "Invocables" (due to C++17 direction) * Library name "Fit" is not indicative of what it provides //////////////////////////////////////////////////////////////////////////////// Regarding the Author //////////////////////////////////////////////////////////////////////////////// Paul has been active in the Boost community for several years now. He is aware of his responsibilities going forward and I am confident that he will be a reliable maintainer for Fit for the foreseeable future (or whatever the library may be called). //////////////////////////////////////////////////////////////////////////////// Comments on the Name Boost.Fit //////////////////////////////////////////////////////////////////////////////// Note that what I say here is my personal opinion as a member of the community and does not necessarily reflect the opinions of others in the community nor of those in the steering committee. A few reviewers voiced that they would like to see a change of the library name "Fit". While multiple people did suggest this, my opinion is that this should be up to the author to choose whether or not he will change the name before it is added to boost and so I do not think it would be appropriate for us to strictly require or encourage such a change. If the author found the arguments against the name compelling, then he is welcome to change the name, but he should not feel obligated to do so. As a quick note on that, we have several high quality and highly regarded libraries in Boost with names that may not directly tell users what the library is for. Based on their popularity, I do not believe that it has significantly negatively affected their usage or ability to be found. A library name also may be important to an author as a creative outlet and I think it would be... poor form us to force such a change in this particular case and in other cases unless there are very strong reasons (i.e. the name is overly or intentionally misleading or there are legal concerns). I am not convinced that the current name is misleading enough to strictly require a change. As for existing precedent, some examples of libraries already in Boost with names that do not directly tell the user what the library is for include some of Boost's most highly regarded libraries such as Boost.Spirit (including Qi and Karma), Boost.Phoenix, Boost.Wave, Boost.Hana, and the recently accepted Boost.Beast. //////////////////////////////////////////////////////////////////////////////// Thanks again to everyone who participated in this review and in the previous review, and once again, congratulations to Paul on his library's acceptance into Boost. -- -Matt Calabrese -- -Matt Calabrese

1 0

[review] The review of Boost.DoubleEnded starts today: September 21 - September 30
by Thorsten Ottosen 21 Sep '17

21 Sep '17

Dear users and members of Boost, I'm proud to announce that the formal review of Benedek Thaler's Boost.DoubleEnded library starts today, September 21, and runs through September 30. This library is the result of Benedek's participation in Google Summer of Code 2015. The library may be downloaded from https://github.com/erenon/double_ended and the documentation may be found here: http://erenon.hu/double_ended/ Anyone is welcome to post a review and/or take part in subsequent discussions on the boost developer list (see below for review guidelines). Introduction ------------ This is a container library that provides two containers: A. boost::devector B. boost::batch_deque Both containers provides efficient push_front and push_back operations, hence the name DoubleEnded. The boost::devector class can be seen as an extension of std::vector with efficient support for push_front (so boost::devector provides contiguous storage). In addition, it provides a customizable small buffer optimization like boost::small_vector(*). It furthermore allows for customization of the growth factor such that the user can decide if a reallocation should allocate 1.5 or 2 or whatever more memory. And finally it provides new functionality that does not exist in normal vector implementations -- this functionality allow the class to excel in performance in certain situations like serialization or transfer of data from sources that require a preallocated buffer. The boost::batch_deque is similar to std::deque, but with two important twists. Like std::deque, it provides reference stability when calling push_front/push_back. Reference stability is crucial for programs that uses intrusive containers e.g. using Boost.Intrusive (**). boost::batch_deque has the following main advantages: 1. It allows the user to specify the segment size 2. It allows for external iteration over the segments Taken together, they provide a very efficient and flexible basis for intrusive containers. Access to the segments also increases performance for tasks such as serialization. Finally, boost::batch_deque may be seen as an efficient alternative to std::vector if you want to replace a percent-wise memory overhead with a constant memory overhead and have no need for contiguous storage. Review guidelines ----------------- Please provide in your review whatever information you think is valuable to understand your final choice of ACCEPT or REJECT including Fit as a Boost library. Please be explicit about your decision. Some other questions you might want to consider answering: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With which compiler(s)? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? More information about the Boost Formal Review Process can be found here: http://www.boost.org/community/reviews.html Kind regards Thorsten, Review manager (*) boost::small_vector: https://tinyurl.com/ycslp4ot (**) http://www.boost.org/doc/libs/1_64_0/doc/html/intrusive.html

1 0