April 2015 - Boost - lists.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

[align] Conflicts during git pull
by Andrey Semashev 06 Apr '15

06 Apr '15

Hi, When updating my local copy 'git pull' failed on Boost.Align with the following error: git pull Auto-merging test/is_aligned_test.cpp CONFLICT (add/add): Merge conflict in test/is_aligned_test.cpp Auto-merging test/aligned_delete_test.cpp CONFLICT (add/add): Merge conflict in test/aligned_delete_test.cpp Auto-merging test/aligned_allocator_test.cpp CONFLICT (add/add): Merge conflict in test/aligned_allocator_test.cpp Auto-merging test/aligned_allocator_adaptor_test.cpp CONFLICT (add/add): Merge conflict in test/aligned_allocator_adaptor_test.cpp Auto-merging test/aligned_alloc_test.cpp CONFLICT (add/add): Merge conflict in test/aligned_alloc_test.cpp Auto-merging test/align_test.cpp CONFLICT (add/add): Merge conflict in test/align_test.cpp Auto-merging test/Jamfile.v2 CONFLICT (add/add): Merge conflict in test/Jamfile.v2 Auto-merging meta/libraries.json CONFLICT (add/add): Merge conflict in meta/libraries.json Auto-merging index.html CONFLICT (add/add): Merge conflict in index.html Auto-merging include/boost/align/is_aligned.hpp CONFLICT (add/add): Merge conflict in include/boost/align/is_aligned.hpp Auto-merging include/boost/align/detail/max_count_of.hpp CONFLICT (add/add): Merge conflict in include/boost/align/detail/max_count_of.hpp Auto-merging include/boost/align/detail/max_align.hpp CONFLICT (add/add): Merge conflict in include/boost/align/detail/max_align.hpp Auto-merging include/boost/align/detail/is_alignment.hpp CONFLICT (add/add): Merge conflict in include/boost/align/detail/is_alignment.hpp Auto-merging include/boost/align/detail/is_aligned.hpp CONFLICT (add/add): Merge conflict in include/boost/align/detail/is_aligned.hpp Auto-merging include/boost/align/detail/alignment_of.hpp CONFLICT (add/add): Merge conflict in include/boost/align/detail/alignment_of.hpp Auto-merging include/boost/align/detail/aligned_alloc_sunos.hpp CONFLICT (add/add): Merge conflict in include/boost/align/detail/aligned_alloc_sunos.hpp Auto-merging include/boost/align/detail/aligned_alloc_posix.hpp CONFLICT (add/add): Merge conflict in include/boost/align/detail/aligned_alloc_posix.hpp Auto-merging include/boost/align/detail/aligned_alloc_msvc.hpp CONFLICT (add/add): Merge conflict in include/boost/align/detail/aligned_alloc_msvc.hpp Auto-merging include/boost/align/detail/aligned_alloc_macos.hpp CONFLICT (add/add): Merge conflict in include/boost/align/detail/aligned_alloc_macos.hpp Auto-merging include/boost/align/detail/aligned_alloc_android.hpp CONFLICT (add/add): Merge conflict in include/boost/align/detail/aligned_alloc_android.hpp Auto-merging include/boost/align/detail/aligned_alloc.hpp CONFLICT (add/add): Merge conflict in include/boost/align/detail/aligned_alloc.hpp Auto-merging include/boost/align/detail/align_cxx11.hpp CONFLICT (add/add): Merge conflict in include/boost/align/detail/align_cxx11.hpp Auto-merging include/boost/align/detail/align.hpp CONFLICT (add/add): Merge conflict in include/boost/align/detail/align.hpp Auto-merging include/boost/align/detail/addressof.hpp CONFLICT (add/add): Merge conflict in include/boost/align/detail/addressof.hpp Auto-merging include/boost/align/detail/address.hpp CONFLICT (add/add): Merge conflict in include/boost/align/detail/address.hpp Auto-merging include/boost/align/aligned_delete_forward.hpp CONFLICT (add/add): Merge conflict in include/boost/align/aligned_delete_forward.hpp Auto-merging include/boost/align/aligned_delete.hpp CONFLICT (add/add): Merge conflict in include/boost/align/aligned_delete.hpp Auto-merging include/boost/align/aligned_allocator_forward.hpp CONFLICT (add/add): Merge conflict in include/boost/align/aligned_allocator_forward.hpp Auto-merging include/boost/align/aligned_allocator_adaptor_forward.hpp CONFLICT (add/add): Merge conflict in include/boost/align/aligned_allocator_adaptor_forward.hpp Auto-merging include/boost/align/aligned_allocator_adaptor.hpp CONFLICT (add/add): Merge conflict in include/boost/align/aligned_allocator_adaptor.hpp Auto-merging include/boost/align/aligned_allocator.hpp CONFLICT (add/add): Merge conflict in include/boost/align/aligned_allocator.hpp Auto-merging include/boost/align/aligned_alloc.hpp CONFLICT (add/add): Merge conflict in include/boost/align/aligned_alloc.hpp Auto-merging include/boost/align/align.hpp CONFLICT (add/add): Merge conflict in include/boost/align/align.hpp Auto-merging include/boost/align.hpp CONFLICT (add/add): Merge conflict in include/boost/align.hpp Auto-merging example/make_aligned.hpp CONFLICT (add/add): Merge conflict in example/make_aligned.hpp Auto-merging example/aligned_vector.hpp CONFLICT (add/add): Merge conflict in example/aligned_vector.hpp Auto-merging example/aligned_ptr.hpp CONFLICT (add/add): Merge conflict in example/aligned_ptr.hpp Auto-merging doc/align.qbk CONFLICT (add/add): Merge conflict in doc/align.qbk Auto-merging doc/Jamfile.v2 CONFLICT (add/add): Merge conflict in doc/Jamfile.v2 Auto-merging README.md CONFLICT (add/add): Merge conflict in README.md Automatic merge failed; fix conflicts and then commit the result. This is on the master branch. I didn't modify my local copy of Boost.Align, so there must have been some weird change upstream that cannot be merged automatically. Does anyone know why this happens? For now I just reset my local branch to be equal to the remote master, but this kind of problem happened before and it breaks my update scripts.

2 1

Call for Papers for Meeting C++ 2015 ends on Wednesday
by Jens Weller 05 Apr '15

05 Apr '15

Hello Boost & Qt Community, the call for papers for this years Meeting C++ Conference got extended and ends on Wednesday(April 8th) next week! Especially talks about libraries have still a good chance to get voted into the conference, and also the embedded theme track! CfP announcement: http://meetingcpp.com/index.php/newsreader/items/call-for-papers-for-meetin… The voting will begin shortly after the end of the CfP and run ~10 days, this will give me guidance to select the right talks for this years conference! thanks, Jens Weller

1 0

Equivalent of boost-commits?
by Steven Watanabe 05 Apr '15

05 Apr '15

AMDG I used to subscribe to boost-commits under svn. I couldn't find any way to set this up under github. Also, does anyone know how to subscribe to all repositories, without having to handle each repository individually? In Christ, Steven Watanabe

1 0

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

[sync] Needs a 'master' branch
by Edward Diener 03 Apr '15

03 Apr '15

I created a Github issue that the sync library needs a 'master' branch, even if its just the current 'develop' branch. Please let's get this done. It is more than just irritating that: git submodule foreach --recursive git checkoout master stops and fails because a Boost library does not have a 'master' branch.

2 1

[where to start][got work for me?][newbee][can I help with something?]
by vivek dhiman 03 Apr '15

03 Apr '15

Hello all So I am not sure what's gonna happen to my GSoC application. But as this is my last sem(probably last chance to learn), I guess I can start doing some work anyways. May be 1 to 2 hours per weekday and 3-4 during the weekends. Is there some work that someone wants me to do? I am new to this. So I actually have no idea how to ask/start. But I am happy to be involved. Sorry if it is considered as spam. I am ready to learn and make mistakes. Thanks Vivek

2 1

[VS++ 2015 CTP 6] [build] Workaround for Visual Studio 2015 CTP 6 Preview breaking Boost.Build
by Beman Dawes 02 Apr '15

02 Apr '15

If you have previously been running Boost.Build on toolset=msvc-14.0 (Visual Studio 2015 Preview), installing CTP 6 causes some bjam/b2 builds to fail because of missing include files. What's happening is that Boost.Build caches several files in C:\Users\<name>\AppData\Local\Temp. For my installation these files are: b2_msvc_14.0_vcvarsall_x86.cmd b2_msvc_14.0_vcvarsall_x86_amd64.cmd b2_msvc_14.0_vcvarsall_x86_arm.cmd but the introduction of the new universal runtime stuff in CTP 6 added some additional paths to vcvarsall, so the cached files are no longer correct. The workaround is to simply delete the b2_msvc_14.0_vcvarsall* temporary files. The next time bjam/b2 is run correct versions of the files will be regenerated. --Beman

1 0

[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

questions regarding GCC visibility
by Robert Ramey 02 Apr '15

02 Apr '15

I made a few changes to simplify code in the serialization library. This entailed eliminating support for borland compilers, workarounds for compilers which fail to support partial specialization of template function and some general clean up. In the course of this effort, I had occasion to simplify the code which supports Auto linking - and by extension visibility. Things seemed to go pretty well. Feeling frisky, I added the switch -fvisibility=hidden to the gcc compile of library. Now applications won't link for lack of certain symbols. Well, they link and run fin on my machine here at home- but fail in the test matrix. http://www.boost.org/development/tests/develop/developer/output/Debian-Sid-… Funny thing is: doesn't seem to be a problem on my machine doesn't seem to occur with all exported symbols - only select ones - often but not always desctructors I can switch Jamfile back so it doesn't specify -fvisibility=hidden, but it seems that I'm really close to being able to generate a smaller, cleaner DLL which I would prefer to do. Any constructive suggestions would be appreciated. On a related note, it seems to me that http://www.boost.org/development/separate_compilation.html should be updated to explain BOOST_SYMBOL_EXPORT and BOOST_SYMBOL_IMPORT which are convenient for simplifying the auto-linking and visibility functionality. Robert Ramey -- View this message in context: http://boost.2283326.n4.nabble.com/questions-regarding-GCC-visibility-tp467… Sent from the Boost - Dev mailing list archive at Nabble.com.

5 10

Boost 1.58.0rc1 release delayed
by Marshall Clow 01 Apr '15

01 Apr '15

Due to some problems in Boost.Test, and some unexpected doctor's visits (which delayed said problems getting fixed), the boost 1.58.0rc1 scheduled for today has been delayed until Friday. As a result, the "master" branch in git is still open for bug fixes (if they have been successfully tested on develop) and documentation fixes until 11:59 PM PDT Thursday night (4/2). Sorry for the delay. -- Marshall

2 1

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

[boostorg/regression] Build instructions updated for developers local test reporting
by Beman Dawes 01 Apr '15

01 Apr '15

A README file has been added and index.html updated to aid developers wishing to use these tools for local testing. While these tools are not worthwhile for a small number of tests run against a single variant of a single compiler, they are invaluable for large test matrices. See develop branch at https://github.com/boostorg/regression HTH, --Beman

2 1

Test message testing gsoc-admin@boost.org, please ignore
by Niall Douglas 01 Apr '15

01 Apr '15

Second attempt at getting this to work ... --- Boost C++ Libraries Google Summer of Code 2015 admin https://svn.boost.org/trac/boost/wiki/SoC2015

1 0

[log] [asio] Conflicting default configs
by Andrey Semashev 01 Apr '15

01 Apr '15

Hi, In Boost.Log I'm using Boost.ASIO to implement network-based syslog backend. Boost.ASIO is used in the compiled part of Boost.Log and, obviously, can be used in the user's code as well. By default Boost.ASIO is header-only, so we basically have a copy of Boost.ASIO in Boost.Log and another copy in the user's app. In Boost.Log I have the option to enable compiler-based TLS at the library build stage (BOOST_LOG_USE_COMPILER_TLS macro), which is by default not enabled. In Boost.ASIO there is a similar option (BOOST_ASIO_DISABLE_THREAD_KEYWORD_EXTENSION macro) but the feature is enabled by default. I want Boost.Log built libraries to actually respect the BOOST_LOG_USE_COMPILER_TLS option, so I define BOOST_ASIO_DISABLE_THREAD_KEYWORD_EXTENSION internally when BOOST_LOG_USE_COMPILER_TLS is not defined. The problem is that Boost.ASIO changes implementation in an incompatible way when BOOST_ASIO_DISABLE_THREAD_KEYWORD_EXTENSION is defined. It is further worsened by a recent change that makes all of Boost.ASIO symbols externally visible. Basically, this means hard to debug trouble on user's end, when different versions of Boost.ASIO (one from Boost.Log binaries and the other used by the user's code directly) are used at the same time. I'd like to ask community what is the preferred resolution of this situation (and possibly similar ones in the future). I can see several ways of tackling this: 1. Introduce an inline ABI namespace in Boost.ASIO, much like the one I have in Boost.Log. The namespace name would depend on BOOST_ASIO_DISABLE_THREAD_KEYWORD_EXTENSION and other macros that affect binary compatibility. This would be my preferred solution, although I'm not sure how fast and easy it can be implemented. 2. Remove symbol visibility enforcement from Boost.ASIO, or at least make it optional. That way I could encapsulate my private copy of Boost.ASIO in Boost.Log binaries. 3. Change the defaults, either in Boost.Log or in Boost.ASIO, so that they are aligned by default. When the user changes Boost.Log config he would be expected to know that Boost.ASIO config also needs to be changed accordingly. If he doesn't, Boost.Log is still built consistently with its own config. Note, however, that since Boost.Log is a built library and in most distributions it is built with default options, the choice for Boost.Log is more significant and because of that should probably be more conservative. 4. Same as 3 but also remove the enforcement of Boost.ASIO config by Boost.Log. Whenever the user wants to change the default, he would have to define macros for the both libraries, otherwise Boost.Log can be built inconsistently. 5. Do not change the defaults but remove the config enforcement. BOOST_LOG_USE_COMPILER_TLS becomes Boost.Log-local and as such does not guarantee that the resulting binaries do not in fact use compiler-based TLS. Users can get surprised. 6. Do not change anything, let the users suffer because of ODR issues. Maybe document this somewhere... Opinions?

5 11