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

[fiber, afio, dl, bindlib, expected, hana, tick, fit, simd, dispatch] Checking my shortlist of upcoming Boost C++ 11/14 librari
by Niall Douglas 10 Apr '15

10 Apr '15

Dear Boost, I've spent the last few days reviewing the shortlist of C++ 11/14 libraries as suggested in this thread http://article.gmane.org/gmane.comp.lib.boost.devel/255548 which appear closest to entering Boost as per the rules in my C++ Now abstract: 1. The library must be C++ 11/14 only. As in, no C++ 03 compilation possible. 2. The order chosen shall be the closest to entering Boost in March/April (i.e. now), so already in Boost, approved to enter Boost, in the formal review queue, approaching the formal review queue. At https://drive.google.com/open?id=1Bizs9xz2dyt1d5GJv-pOCmu1cS67gRd0KNYn sjYK Ji w&authuser=0 you will hopefully find a traffic light dashboard spreadsheet (I tried posting a PNG here, it was refused). In it is shown the current state, as estimated by fallible me from a cursory glance at the library, for various measures of the library. Errors are entirely possible, hence me asking here before I make a fool of myself. List members may be as surprised as I was to learn that most of the upcoming libraries require C++ 14. They are also universally standalone from Boost, being about as weakly dependant as is possible and still be called a Boost library. That was a big surprise to me as well. Another surprise was the dislike of Boost.Test - a lot of libraries don't use it, indeed can't use it. And finally, almost everyone uses Travis CI, though not valgrind memcheck for leak detection nor coveralls for unit test coverage. The first category is libraries already in the formal review queue or better. These are: Fiber, AFIO, Dl. The second category is libraries where the authors have been visible enough for me to review the library and score it onto the dashboard. These are: BindLib, Expected, Hana, Tick, Fit. ... of which BindLib, Expected and Hana are the most "Boost ready" by my estimation. I still haven't reviewed Sqlpp11, SIMD, Dispatch, Range v3, Spirit X3 nor Proto 0x. The main reason why not is that I would never use any of those libraries in any work I expect to do anytime in the next five years. That's quite unfair to those libraries, but I have another big reason: I'm also hesitant to review libraries covered by their authors also present at C++ Now, or have presented on them in the past, as it won't add value plus I probably wouldn't know what I'm talking about compared to them so that removes Expected?, Hana, SIMD, Dispatch, Range v3, Spirit X3 and Proto 0x. Which leaves a shortlist of: Fiber, AFIO, Dl, BindLib, maybe Expected, maybe Tick and Fit. I think SIMD and Dispatch have been presented on before at C++ Now right? Could anyone also very quickly summarise the main differences in their C++ 11 only rewrite? I think I remember it was mainly compilation speed rather than doing anything unusually C++ 11 only? Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

4 4

[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

[AIX6.1] [64bit] [build boost 1.57] Help required to build boost
by 임영운 10 Apr '15

10 Apr '15

hi, I'm newbie. the only one thing that I wanted to ask is building boost 64bit on aix6.1. I try it a number of times. and I failed building 64bit boost objects. It built only 32bit objects. would you tell me how to build boost 64bit on aix6.1 thanks read this msg. 주식회사 테미 임영운(Yeong-woon Im) 305-764 대전광역시 유성구 대학로99 충남대학교 산학연교육연구관 807호 #807, TBI Center, Chungnam University 99 Daehak-ro, Yuseong-gu, Deajeon, 305-764 Korea Home URL : http://www.temee.co.kr Tel : 042-824-7014 Fax : 042-824-7015 Mobile : 010-6266-9960

2 1

Re: [boost] [Boost-users] 1.58.0 rc3 is now available
by Marshall Clow 09 Apr '15

09 Apr '15

On Thu, Apr 9, 2015 at 4:11 AM, Deniz Bahadir <dbahadir(a)benocs.com> wrote: > Building Boost 1.58.0-rc3 succeeded only partially. > > > Success: > > Debian 7 with GCC 4.8.2 (in C++03 mode) with build-command: > b2 -j4 --build-dir=/opt/build/test --build-type=complete > --layout=versioned address-model=64 architecture=x86 install > --prefix="/opt/install/test" toolset=gcc-4.8 cflags="-fPIC" > cxxflags="-fPIC" dll-path="/opt/test/lib/x86_64-linux-gnu" > > > Failure: > > Debian 7 with GCC 4.8.2 (in C++11 mode) with build-command: > b2 -j4 --build-dir=/opt/build/test --build-type=complete > --layout=versioned address-model=64 architecture=x86 install > --prefix="/opt/install/test" toolset=gcc-4.8 cflags="-fPIC" cxxflags="-fPIC > -std=c++11" dll-path="/opt/test/lib/x86_64-linux-gnu" > > > The main-error seems to come from "Boost.Context" and the use of unknown > "std::index_sequence": > > std::index_sequence is a C++14 feature. -- Marshall

1 0

[language] determine sence of language proposal concerning the 'default'-keyword
by Jakob Riedle 09 Apr '15

09 Apr '15

Hello boost community, since this seems to me kind of a proving ground for new C++ library/language features I'd ask this question here. Would you recon' writing a language proposal about: using the 'default'-keyword as some standard way of calling the default ctor of variables. I could imagine the following use-case: void foo( some::very_long_name<some_very_long_template_param> arg = default ){ return; } This would make things shorter, in the way 'auto' does it for types. You could also do it for passing parameters: foo( default ); This could interact very well with boost::optional, make it more intuitive and easier to use: optional<int> bar( optional<some_long_type_name> arg = default ){ return default; } bar( default ); This way, you don't have to write 'optional<some_long_type_name>()', both at the parameter and at the function call. What do you think of such a language proposal? Regards, Jakob Riedle

5 5

[MinGW] [Windows] [build boost 1.57] Help required to build boost
by Abhinav Tripathi 08 Apr '15

08 Apr '15

I had submitted a GSoC application regarding developing a document library for boost and i wanted to do something regardless of the results of selection. . SO, i downloaded boost 1.57 source and tried to build it using MinGW compiler that i downloaded with CodeBlocks IDE which i use. When i ran : bootstrap.bat gcc I got error "Failed to build Boost.Build Engine". . The bootstrap.log file was : ### ### Using 'gcc' toolset. ### E:\Prog Stuff\boost_1_57_0\tools\build\src\engine>if exist bootstrap rd /S /Q bootstrap E:\Prog Stuff\boost_1_57_0\tools\build\src\engine>md bootstrap E:\Prog Stuff\boost_1_57_0\tools\build\src\engine>gcc -DNT -o bootstrap\jam0.exe command.c compile.c constants.c debug.c execcmd.c execnt.c filent.c frames.c function.c glob.c hash.c hdrmacro.c headers.c jam.c jambase.c jamgram.c lists.c make.c make1.c object.c option.c output.c parse.c pathnt.c pathsys.c regexp.c rules.c scan.c search.c subst.c timestamp.c variable.c modules.c strings.c filesys.c builtins.c md5.c class.c cwd.c w32_getreg.c native.c modules/set.c modules/path.c modules/regex.c modules/property-set.c modules/sequence.c modules/order.c E:\Prog Stuff\boost_1_57_0\tools\build\src\engine>.\bootstrap\jam0 -f build.jam --toolset=gcc "--toolset-root= " clean ...found 1 target... ...updating 1 target... ...updated 1 target... E:\Prog Stuff\boost_1_57_0\tools\build\src\engine>.\bootstrap\jam0 -f build.jam --toolset=gcc "--toolset-root= " ...found 159 targets... ...updating 3 targets... [MKDIR] bin.ntx86 'C:\Users\Abhinav' is not recognized as an internal or external command, operable program or batch file. md "bin.ntx86" ...failed [MKDIR] bin.ntx86... ...skipped b2.exe for lack of bin.ntx86... ...skipped bjam.exe for lack of b2.exe... ...failed updating 1 target... ...skipped 2 targets... . . I am NOT any expert but as far as i can guess, it tried to execute "C:\Users\Abhinav" which ofcourse is NOT any valid command... . How can i build boost? Is there a way to use it without actually building the source? Please help! . Regards, Abhinav

2 2

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

1.58.0 rc2 is now available
by Marshall Clow 07 Apr '15

07 Apr '15

Release candidate files for 1.58.0 are available at: http://boost.cowic.de/rc/ Since rc1, the changes that were causing the serialization libraries to fail to build on MSVC have been reverted. As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. This helps ensure the candidates build OK before we push them out to SourceForge. The files (and associated md5s) are: MD5 (boost_1_58_0_rc2.7z) = 43e0d47cc9f5f2a07761808b9da57c0a MD5 (boost_1_58_0_rc2.tar.bz2) = 52147381c97685eb045b5b022ad51a35 MD5 (boost_1_58_0_rc2.tar.gz) = cb33afaa557dea2f700bffec8a91d87e MD5 (boost_1_58_0_rc2.zip) = 412676a9a7d9903eb5a260209ad78f0a Thanks! -- The release managers P.S. Release notes are here: http://www.boost.org/users/history/version_1_58_0.html

6 5

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