- Boost - lists.preview.boost.org

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

[serialization][release][teeks99] All MSVC tests for Boost.Serialization failing?
by Joaquín M Lopez Munoz 31 Mar '15

31 Mar '15

Hi All teeks99-* regression tests for Boost.Serialization in MSVC compilers appear as failing, yet when one clicks on any the information seems to indicate nothing went wrong: http://tinyurl.com/nf5bd9a Any clue? Thank you Joaquín M López Muñoz Telefónica

3 4

Transferring a library on Github
by Edward Diener 31 Mar '15

31 Mar '15

In order to get VMD under boostorg in order to begin the process of integrating the library into Boost for the release after the current pending one I tried to transfer the library as explained on the page https://svn.boost.org/trac/boost/wiki/NewLibFromGit. But I do not have the necessary admin rights for boostorg. How do I proceed ? I want to get VMD under boostorg and then do whatever is necessary to add it to the superproject and have it part of for regression testing.

2 4

[detail] Bug in is_postfix_incrementable
by Edward Diener 31 Mar '15

31 Mar '15

There is a rather bad bug in is_postfix_incrementable in the detail/is_incrementable.hpp header file. I noticed this when I was looking at how I can remove the dependncies in is_incrementable.hpp on the deprecated Type_traits header files in Version2 of type_traits. The bug looks totally obvious to me. It's that the is_postfix_incrementable metafunction is derived from the is_incrementable_::impl<T> implementation rather than the is_incrementable_::postfix_impl<T> implementation. I am sure this was just a copy-paste problem but evidently has been in the header file from the beginning. Can we fast forward the simple fix to the new release ? I posted this just to be sure I haven't missed anything in the file. I believe that only the iterator library currently uses the is_incrementable and is_postfix_incrementable metafunctions in its tests. Since it is Boost detail no end-user should be using it. Still we should have it correct, shouldn't we, in our release ?

1 0

Conflicts when building libraries at root
by Peter Dimov 31 Mar '15

31 Mar '15

On Windows, at least, when I do ./b2 toolset=msvc-8.0 at Boost root, I get error: Name clash for '<pstage\lib>libboost_system-vc80-mt-gd-1_58.lib' error: error: Tried to build the target twice, with property sets having error: these incompatible properties: error: error: - <warnings>all error: - <address-model>32 <architecture>x86 <warnings>on When I add --without-context --without-coroutine, I now get error: Name clash for '<pstage\lib>libboost_system-vc80-mt-1_58.lib' error: error: Tried to build the target twice, with property sets having error: these incompatible properties: error: error: - <asynch-exceptions>off error: - <asynch-exceptions>on So I add --without-test. error: Name clash for '<pstage\lib>libboost_timer-vc80-mt-1_58.lib' error: error: Tried to build the target twice, with property sets having error: these incompatible properties: error: error: - <asynch-exceptions>on <library>object(file-target)@10959 error: - <asynch-exceptions>off <library>object(file-target)@9953 Now where did _that_ come from. :-) Ah. --without-endian. Builds now. This is perhaps old news for some, but it looks like it doesn't play well with our simple build instructions. Or maybe it doesn't occur on the master branch, so we don't care? I haven't checked yet. It's also perhaps an indication of a deeper problem. I can use b2 --with-test and have 'test' built; it builds its dependencies (system, chrono and timer) with <asynch-exceptions>on in bin.v2, and if I use it from within Boost.Build, it will link to them. But if I stage (or install) Boost.Test, and then stage or install Boost.System separately, Boost.System will be built with <asynch-exceptions>off. So the library user who just has headers and binaries will link those, potentially creating a conflict, which may in this case be benign. Or not.

12 55

[Container] const boost::container::vector is mutable??
by Eric Niebler 31 Mar '15

31 Mar '15

Why are the elements of a const boost::vector mutable through its const_iterator? #include <boost/container/vector.hpp> int main() { using C = boost::container::vector<int>; C c{1,2,3,4}; C const & r = c; r[0] = 42; // Error, good. *r.begin() = 42; // Compiles! huh?? } -- Eric Niebler Boost.org http://www.boost.org

2 3

how to contact iterator developers
by Claas H. Koehler 31 Mar '15

31 Mar '15

Hi! About a week ago I sent a question about a specific bug to the iterator developers via this list and haven't received any feedback yet. Is this list not the right place to ask such questions or are there currently no active iterator developers managing the project ? Regards Claas

3 3