- Boost - lists.preview.boost.org

[pool] block_ptr
by Phil Bouchard 16 Jul '14

16 Jul '14

Hi Boost... long time, In my memory manager: https://svn.boost.org/svn/boost/sandbox/block_ptr/boost/detail/block_base.h… You will see the usage of: boost::singleton_pool<pool, sizeof(char)> because of a required is_from() function call. But I just came to realize there is a pool::is_from() function: http://www.boost.org/doc/libs/1_49_0/libs/pool/doc/html/boost_pool/pool/int… Is that function new or in 2011 I overlooked it? If so I will make the change ASAP as this is a nice class. Regards, -Phil www.finitetheory.com

1 0

[core] Breaking change to boost::ref in 1.56
by Eric Niebler 16 Jul '14

16 Jul '14

(Repost in a new thread) While investigating a failure[^1] in proto, I discovered the following change to boost::ref: https://github.com/boostorg/core/commit/af629ffa59094048c335609f285afe342fd… This failure was caused by the following change to boost::ref by Agustín Bergé (K-ballo): https://github.com/boostorg/core/commit/af629ffa59094048c335609f285afe342fd… I didn't see any discussion about this change. (Was there one?) I can guess why it was made: to make boost::ref behave like std::ref, which does "reference collapsing" with reference_wrapper (which IMO is broken, and I unsuccessfully argued that in the committee when this was voted in). The problem is, it's a breaking interface change to one of the oldest, most heavily used, and stable pieces of Boost. It pretty massively breaks a major part of Boost.Proto's interface (proto::make_expr). I've hacked around the problem in Proto's tests, but this is going to break end-user code, and I don't know what I'm going to tell people. I don't like differences between boost and std. But I also don't like breaking code. What do we want here? Eric [^1]: http://www.boost.org/development/tests/develop/developer/output/teeks99-03j…

6 29

[chrono] Stopwatches
by Daniel James 15 Jul '14

15 Jul '14

Hi, What's the status for stopwatches? Because it's in chrono's metadata file, it's in the list at: http://www.boost.org/doc/libs/master/ Which will also put it in the release documentation list. But there's no documentation to link to, the headers don't get linked by 'b2 headers', and the tests don't seem to be running. Daniel

2 3

Re: [boost] 1.56.0 beta 1 release candidates available for testing
by Klaim - Joël Lamotte 15 Jul '14

15 Jul '14

Once again with previously attached log available there: https://www.dropbox.com/s/8x7727pxqcs9shg/20140715-0053-build_boost_github_… On Tue, Jul 15, 2014 at 1:22 AM, Klaim - Joël Lamotte <mjklaim(a)gmail.com> wrote: > > Hi, > > I just tried to compile the last master > ( a87533ad69d761536cd395501e09719349fc9173 ) which I suppose is equivalent > to the incoming second beta? > I compiled it with with VS2013 Update 2 in 32 and 64 bits, using the > following script: > > pushd .\boost_github > call bootstrap.bat > call b2 --prefix=../boost --buid-type=complete toolset=msvc-12.0 > architecture=x86 install > call b2 --prefix=../boost --buid-type=complete > --libdir=../boost/lib/x64 toolset=msvc-12.0 architecture=x86 > address-model=64 install > popd > > I found a fatal error: > > .\boost/preprocessor/iteration/detail/iter/forward1.hpp(47) : fatal > error C1083: Cannot open include file: > 'boost/utility/detail/result_of_iterate.hpp': No such file or directory > > It's preventing the thread and coroutine libraries to be compiled but only > in non-debug 32 bit (if I understand the logs correctly). > I attached the full log to this email, in case it helps. > > >

1 1

[git] Releases tags
by Adam Wulkiewicz 14 Jul '14

14 Jul '14

Hi, Is there a global policy regarding the way how/when/by whoom tags are created for releases and release candidates? In each submodule there are tags corresponding to the releases (e.g. boost-1.54.0-beta1, boost-1.55.0, etc.). Are they created somehow globally? When a tag is created for the main module is it automatically a tag of the submodule? Or must tags be created manually/separately in each submodule? Of course not counting some private tags. If the former is true, I'm guessing that private tags should have the names reserved for the releases tags? If the latter is true, are they created by the maintenance team or should the authors handle it themselves? Regards, Adam

2 1

[optional] can I merge a performance bug fix?
by Andrzej Krzemienski 14 Jul '14

14 Jul '14

Hi, Could I still merge this pull request for Boost.Optional for 1.56 release. https://github.com/boostorg/optional/pull/6 It fixes a negative performance impact added since 1.55 in cases like: consumeOptional(*produceOptional()); This code already used to seat in develop before I added a bug) and all tests passed fine. Now, the fix has been there since friday on develop and I have no test failures. Can I merge it to trunk? Regards, &rzej

1 0

[range] Is it conceivable to have it extended?
by Vladimir Batov 14 Jul '14

14 Jul '14

boost::iterator_range is a great concept/class but it does not seem to play efficiently with certain input sequences and seem to be too strong a requirement for certain algorithms. I have an old-fashioned C string in mind (I am sure there are other examples) and traversing algorithms. When I tried deploying boost::iterator_range for string-to-int conversion purposes, I quickly realized that I was traversing the string twice -- first to find the end and second to do the work. What I think is missing is the "parent" concept of a "sequence". Say, template<iterator_type, sentry_type> struct sequence { iterator_type begin(); sentry_type sentry(); }; Then "range" would implement and refine the "sequence" concept by template<iterator_type> struct range : sequence<iterator_type, iterator_type> { iterator_type begin(); iterator_type end(); sentry_type sentry() { return end; } } I.e., as "range" implements/is the "sequence", the boost::iterator_range will have one additional "useless" sentry() method. That way all the old code (using and/or needing end()) would still work but traversing algorithms might gradually adapt to only require "sequences" instead of "ranges": template<typename Iterator, typename Sentry, typename Function> Function for_each(Iterator beg, Sentry sentry, Function fun) { for (; beg != sentry; ++beg) fun(*beg); return fun; } That means that now all "open-ended" (with no known "end") "ranges" (they are not even "ranges" in the strict meaning of the word but rather "sequences") can be handled efficiently. I ended up having such an "extended" range in Boost.Convert (to handle C string traversals efficiently) but I hate having/maintaining the code and much prefer the standard solution. Any suggestions? Vladimir.

4 6

Libraries failing across the board.
by Beman Dawes 13 Jul '14

13 Jul '14

Marshall is just a few days away from being able to put out a beta release candidate. (And that is very good news!) But we still have too many libraries failing across the board on master: accumulators interprocess numeric/ublas pool proto spirit/repository spirit/test tr1 wave See http://www.boost.org/development/tests/master/developer/summary.html What is the hold up with these? Does anyone need help? --Beman

10 24

1.56.0 beta 1 release candidates available for testing
by Marshall Clow 13 Jul '14

13 Jul '14

Release candidate files for 1.56.0 beta 1 are available at http://boost.cowic.de/rc/ 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_56_0b1_rc1.7z) = a23e0b5f503c82970c9754dbc8324256 MD5 (boost-1_56_0b1_rc1.tar.bz2) = c6c8486dde4375896f302bdfe1fd3d2f MD5 (boost-1_56_0b1_rc1.tar.gz) = 1042e97a9f354b7187326fa1f9eb313e MD5 (boost-1_56_0b1_rc1.zip) = 984a70feac785d908d8f75ea9d8d2158 Since this is the first post-git release, we are expecting some teething pains with this release. Please test extensively. Thank you. --The release managers

10 13

Can't run tests on develop
by Peter Dimov 12 Jul '14

12 Jul '14

When I try to run the smart_ptr tests on develop by the usual: C:\Projects\boost-git\boost\libs\smart_ptr\test>b2 toolset=gcc,gcc-cxx11,msvc-8.0,msvc-10.0,msvc-12.0 I now get the following errors: ...found 1 target... ...updating 1 target... msvc.write-setup-script C:\Users\PETERD~1\AppData\Local\Temp\b2_msvc_12.0_vcvarsall_x86.cmd ...updated 1 target... ...found 1 target... ...updating 1 target... msvc.write-setup-script C:\Users\PETERD~1\AppData\Local\Temp\b2_msvc_12.0_vcvarsall_x86_amd64.cmd ...updated 1 target... ...found 1 target... ...updating 1 target... msvc.write-setup-script C:\Users\PETERD~1\AppData\Local\Temp\b2_msvc_8.0_vcvarsall_x86.cmd ...updated 1 target... ...found 1 target... ...updating 1 target... msvc.write-setup-script C:\Users\PETERD~1\AppData\Local\Temp\b2_msvc_8.0_vcvarsall_x86_amd64.cmd ...updated 1 target... C:/Projects/boost-git/boost/tools/build/src/tools\msvc.jam:1057: in configure-really *** argument error * rule locate-default-setup ( command : parent : setup-name ) * called with: ( : C:\Program Files (x86)\Microsoft Visual Studio 8\vc\WPSDK : vcvarsphoneall.bat ) * missing argument command C:/Projects/boost-git/boost/tools/build/src/tools\msvc.jam:1446:see definition of rule 'locate-default-setup' being called C:/Projects/boost-git/boost/tools/build/src/tools\msvc.jam:200: in configure C:/Projects/boost-git/boost/tools/build/src/tools\msvc.jam:152: in msvc.init C:/Projects/boost-git/boost/tools/build/src/build\toolset.jam:43: in toolset.using C:/Projects/boost-git/boost/tools/build/src\build-system.jam:461: in process-explicit-toolset-requests C:/Projects/boost-git/boost/tools/build/src\build-system.jam:527: in load C:\Projects\boost-git\boost\tools\build\src/kernel\modules.jam:289: in import C:\Projects\boost-git\boost\tools\build\src/kernel/bootstrap.jam:139: in boost-build C:\Projects\boost-git\boost\boost-build.jam:17: in module scope Any ideas?

3 8