March 2015 - Boost - lists.preview.boost.org

Fwd: Windows Intel Compiler problem
by Mari Pecha 15 Apr '15

15 Apr '15

Good morning, I try compile boost with Intel Compiler under Windows OS, but I got an error message screen is in attachments. I don't know what I'm doing wrong, can you help me? Thank you Mari --- This email has been checked for viruses by Avast antivirus software. http://www.avast.com

2 1

htmlspecialchars and urlencode?
by Olaf van der Spek 14 Apr '15

14 Apr '15

Hi, Does Boost have functions like htmlspecialchars and urlencode (from PHP)? If not, I think they'd make a nice addition to the string algorithm lib. -- Olaf

4 6

[peer review queue tardiness] Cleaning out the Boost review queue
by Niall Douglas 10 Apr '15

10 Apr '15

I've been reviewing the Boost Formal Review queue as part of preparing my C++ Now presentation and I observe the following things: Observation 1. The following review submissions have not been updated by their authors in over two years and therefore count as unmaintained. Abandoned libraries before peer review are even more undesirable than abandoned official Boost libraries, I therefore suggest they be removed from the review queue until their authors bring them up to date: * Join (last update 2009) * Block pointer (last update: well, it's still in the SVN sandbox) * Singularity (last update 2011) * Extended Complex Numbers (last update 2012) * Array (last update 2012) * Countertree (last update 2012, I see a github import in 2013 but no new commits) * Process (last update 2012). This is a particularly useful library I have used myself in production code, and I see a number of mirrors of it on github each with varying patches and bug fixes. As a minimum, somebody needs to create a canonical github project for Process and merge the fixes from the many github copies. Otherwise, I'm sorry but this library needs to be considered abandoned otherwise, and removed from the review queue. It may be the case that the links on the review queue wiki page are simply out of date. If so, they need to be updated. Otherwise a purge of the queue is very desirable such that the queue accurately reflects ready to use new Boost libraries. Observation 2: Edit Distance (Algorithm) by Erik Erlandson shouldn't be in the queue. What he's done is to add a new algorithm to Boost.Algorithm, so the maintainer for Algorithm (Marshall?) should either merge his contribution or reject it as inappropriate or badly implemented. Failing that, Edit Distance should be spun into a standalone library instead of forking Algorithm. Right now it is supplied quite literally as a fork of the algorithm github. It should be a pull request, yet I don't see it in the pull requests for boostorg/algorithm, neither open nor closed. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

15 43

Is boost.python dead?
by Mikhail Matrosov 08 Apr '15

08 Apr '15

Hello, I made a pull request for boost.python: https://github.com/boostorg/python/pull/15 Two weeks passed since then and I had no reaction still. Did I do something wrong? I see no pulse for the project. Is it alive? Is there a way to find out its status? The last meaningful commit is dated back to 7 Dec 2012. ----- Best regards, Mikhail Matrosov

5 7

[flat_map] Any interest in a flat_map variant that is much faster on insertion/erase at the price of a slower lookup?
by Giacomo Drago 08 Apr '15

08 Apr '15

Hi My library is not ready for a formal review process, and I'd like to ask whether there is some potential interest first, thus saving everybody a lot of time. I have been working on a flat_map (http://www.boost.org/doc/libs/1_57_0/doc/html/boost/container/flat_map.html) variant that keeps some of the distinctive features of the original one (contiguous storage/cache friendliness, zero memory overhead/shrink_to_fit support, vector-based representation, etc...) but makes insertion and erasure of the elements much faster, at the price of a slower lookup and in-order traversal. Explaining how it works requires time and it's not really necessary if there is no interest in the first place (e.g. "thanks, but we have no use for this"). Let's get straight to the benchmarks and to some conclusions. #elems: 50000 std::map: Random insertion: 18.605 ms Random find: 24.382 ms Iteration: 5.658 ms Random erase: 37.166 ms experimental::flat_map: Random insertion: 400.141 ms Random find: 12.352 ms Iteration: 7.099 ms Random erase: 467.051 ms boost::container::flat_map: Random insertion: 611.678 ms Random find: 6.293 ms Iteration: 0.038 ms Random erase: 615.311 ms #elems: 200000 std::map: Random insertion: 146.394 ms Random find: 163.506 ms Iteration: 21.973 ms Random erase: 225.314 ms experimental::flat_map: Random insertion: 5068.93 ms Random find: 65.618 ms Iteration: 34.244 ms Random erase: 6851.09 ms boost::container::flat_map: Random insertion: 10696.9 ms Random find: 43.896 ms Iteration: 0.254 ms Random erase: 10604 ms Of course one doesn't expect the random insertion to have a performance that is comparable to the one of a tree-based map, like std::map. However, my experimental::flat_map provides a better trade-off than boost's flat_map for me, as random insertion is massively faster and in the big picture of the application I am developing this is making a hell of a difference. Am I making any sense? Shall I polish the implementation, publish it, and submit a proposal? I'd really appreciate your feedback. Kind Regards Giacomo

8 37

Re: [boost] [SORT] Parallel Algorithms
by Francisco José Tapia 07 Apr '15

07 Apr '15

Hi , In the file of this link, in my dropbox space, you have the code, the test programs and the benchmarks with GCC. https://dl.dropboxusercontent.com/u/8437476/works/sort/Sort_V0.1.7z *FILE DESCRIPTION* In the root folder of the file you have a INSTRUCTIONS.txt file detailing the content of all the folders of the file, information for to compile the programs, where is each file, and which options and libraries you must link. *Test* Contains the test programs of each class and algorithms. *Src* Contains the source code of all. In the folder *src/boost/sort* there is a file *algorithm.hpp*, which is the only include file needed for invoke the algorithms. The parallel algorithms have a parameter of the NThread type which indicate the number of threads to use. By default use the same number than the HW threads of the machine. it's a very simple structure defined in boost/sort/util/atomic.hpp. *Benchmarks* In this folder are the benchmark code with GCC compiler under Linux x64. In the future I will add benchmarks with other compiler and Operating Systems. The folders *cpp-TimSort-master*, and *parallel_stable_sort* have the C++ code of the TimSort algorithm, found in https://travis-ci.org/gfx/cpp-TimSort, and the code of the sample sort with TBB. The code had been modified, due to the four versions use the same name space and many common names, and was not possible invoke the four versions in the same program. The modification put each version in a different name space. In the folder *GCC*, you can find 3 folders - *algorithm* : Have the code of the benchmark programs - *bin *: have the compiled and static linked version of the benchmark programs. In this folder you have a shell run.sh which run sequentially the programs and collect the results obtained in .txt files with the same name than the program - *Results *: in this folder you can find the result generated by the benchmark programs on different machines. Each machine have a folder where you can find the text files with the same name than the programs with the results, and a description.txt file with the description of the HW where run the benchmarks. The format used in this folder is the suggested for to present the results of all the machines used in the test. Here you have the result of my two computers, and can have a first idea about the results expected in other machines. The benchmarks, like in the old version, have a version with 64 bits numbers, and a version with objects of several sizes. About the memory used for of the algorithms. If you consider M the memory used by the data, the total memory used by the algorithms are : - GCC sort → M - boost sort → M - GCC parallel_sort → M - boost parallel_sort → M - TBB parallel_sort → M - GCC stable_sort → 2 M - boost stable_sort → 1.5 M - TimSort -> 2M - GCC parallel_stable_sort → 2.5 M - TBB parallel_sort → 2 M - boost sample_sort → 2 M - boost parallel_stable_sort → 1.5 M The algorithms use the indirect version when the size of the objects is greater than 128 bytes. I am speaking with several friends, for to run the benchmarks in more powerful machines. I think, the first is to check the speed. If the speed is good, we have something useful , if not, we must decide what must do with this. If something is useful , or we must leave all. If we decide continue, the next steps to do are : Reorganize the benchmark, and include benchmarks with string objects. Your idea about the use of files, I thing is the correct way to follow Finish all the documentation of the code for to generate a Doxygen documentation Generate the web pages of documentation for the Boost project Modify the test programs for to do according the bjam files If you found any problem , error or doubt, please , contact me for to resolve Francisco

7 16

Messages from list marked as spam
by Olaf van der Spek 03 Apr '15

03 Apr '15

Hi, Email from certain people on the list is marked as spam by gmail: "Why is this message in Spam? It has a from address in teamviewer.com but has failed teamviewer.com's required tests for authentication. " Is there a problem with the setup of this mailing list? -- Olaf

9 15

[rational] Can the community maintenance team and/or rational users please review some pull requests?
by John Maddock 02 Apr '15

02 Apr '15

I have a bunch of PR's against Rational, which of course is basically unmaintained. I'd be grateful if a second pair of eyes (at least) could take a look before I start agitating for someone to merge them ;) Each of the four, builds on the previous one(s). Three are basically trivial: https://github.com/boostorg/rational/pull/1/files https://github.com/boostorg/rational/pull/2/files https://github.com/boostorg/rational/pull/3/files The final one is much more complex, and disables "accidental" conversion from float to rational (which otherwise proceeds via truncation to integer first). As you can see from the commit history, I've had quite a few attempts at getting the final one correct. I believe it is now, doesn't break anything in Boost except, as noted in the discussion, Boost.Geometry, which relies on an unsafe float to rational conversion - Geometry's authors are aware of the issue here: https://github.com/boostorg/geometry/commit/c992eb61e8ef9e90fdae403ac6ff1ee…. So.... I'm interested in both eyeball-look-throughs from seasoned Boosters, but also feedback from Rational's users, and verification that it doesn't break end user code - other than unsafe conversions of course. If you just want the updated header to test, you can grab it from here: https://raw.githubusercontent.com/jzmaddock/rational/no-float-convert/inclu… Many thanks! John.

5 8

MPL and MPL core
by Edward Diener 02 Apr '15

02 Apr '15

Were the changes to MPL splitting it between a core and the rest of MPL supposed to be part of the upcoming release ? Because looking at MPL the 'master' branch is at the previous 1.57 release and there have been quite a number of changes to the 'develop' branch since then, much of it relating to the mpl/core split. The 'develop' regression tests for MPL look pretty green. I would like to get bruno Dutra's fix for MPL arity into the coming release as it has been thoroughly tested on 'develop', but I do not know whether or not all the other MPL 'develop' changes should go in 'master' although I suspect not.

11 20

what happened to the "tools/regression" directory - and the stuff in it?
by Robert Ramey 01 Apr '15

01 Apr '15

The tools in the tools/regression directory are critical to the testing of the serialization library on one's local machine. What happened to these. Robert Ramey -- View this message in context: http://boost.2283326.n4.nabble.com/what-happened-to-the-tools-regression-di… Sent from the Boost - Dev mailing list archive at Nabble.com.

9 26