- Boost-users - lists.preview.boost.org

boost::process
by Chris Rodgers 05 Oct '17

05 Oct '17

Hi, I'm trying to use Boost 1.65.1's boost::process::child in a Windows console program. At the moment, the child process is launched in the same console window as the parent. Is there an option to make a new console window for the child? The pre-boost-incorporation version of boost::process seemed to allow manipulation of the startupInfo struct directly (e.g. https://stackoverflow.com/questions/43582022/boostprocess-hide-console-on-w…) and then a win32_launch call. But this seems to have been removed now? Any tips gratefully received. Thanks, Chris.

1 0

looking for a memory leak in an asio based application
by David Medine 05 Oct '17

05 Oct '17

I know that the answer to this question is /always/ 'no'. But is it possible, just possible that one can leak memory out of boost::asio? Let me explain. I work on an open source client/server data streaming library for multi-modal data streaming called labstreaminglayer (https://github.com/sccn/labstreaminglayer) At the core of the data transmission architecture is boost::asio. Now, to avoid calling collisions, the original author of the library shipped the source code with a name-mangled version of boost. Over the years this has yet to be updated so we are still relying on boost 1.57. The memory leak starts on the server side after a client is connected to it. This went undetected for years because it is very very slow and it depends on the sampling rate of the data stream. LSL (labstreaminglayer) is widely used in the neurophysiological research community (for whom the tool was intended), but normally in that field you are not sending samples faster than 500 Hz or so. But some devices are now available that offer relatively high sampling rates (e.g. Brain Products' actiCHamp can go as fast as 100kHz). The amount of memory that leaks seems to depend on how often data is sent, not how much data is send at a time. So, when the data is flowing quickly, the leak is severe. I am 99.99% sure that the allocation of memory for all the data I am sending is getting deallocated correctly. I don't see any leaking memory according to Visual Studio's diagnostic tools, nor can Deleaker spot anything. However, when I look at a server process in task manager, I can see the memory rising. I tried the asio::io_service::work trick (https://stackoverflow.com/questions/32258890/c-boost-asio-async-send-to-mem…) on my io_services, but this didn't have any effect. I have not gone through the whole pipeline yet, but I've been at this for two harrowing days already. So I just thought I would ask the list if anyone has seen anything like this before or if there has been any slow-leak fixes in boost (particularly asio) since 1.57 (I didn't see anything in the logs, but maybe I missed something). Due to the state of the project at this moment, it is non-trivial to update the name-mangled boost to another version, but it is far less trivial than the needle-in-a-haystack game I am playing right now. So, if someone can say with authority a boost update will fix everything I'll just do that and be happy. It's a long-shot, I know.

2 1

Bost Logging
by Mário Costa 04 Oct '17

04 Oct '17

Hi, I'm havving a bad time trying to figure out how to add and log custom keywords using boost/log. I havent been able to understand how exactly attribute keywords (BOOST_LOG_ATTRIBUTE_KEYWORD) bind with logging e.g. using BOOST_LOG_STREAM_WITH_PARAMS(logger, (??) (??)). For instance, if I define a keyword line_number, BOOST_LOG_ATTRIBUTE_KEYWORD(line_number, "LineNumber", unsigned int) and add it to the formmater logging::formatter formatter = expr::stream << "[" << line_number << "]" How do I use BOOST_LOG_STREAM_WITH_PARAMS(logger, (??)) Tanking an exemple from the severities, I should use a keyword parameter defining something like BOOST_PARAMETER_KEYWORD(sometag, line_number) then I should be able to use BOOST_LOG_STREAM_WITH_PARAMS(logger, (line_number = 10)) But those things just don add up together. I for sure missing the logics of the logging ... Thanks for any help! Cheers, mc

1 0

[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