- Boost - lists.preview.boost.org

boost log memory leak? Maybe it is my wrong.
by 梁明辉 14 Nov '15

14 Nov '15

Way I want to use win32 dynamic link library encapsulates the boost.log, the wrapper DLL in MFC MSVC 2015 calls, memory leak in output window prompt; The same library in a console program calls, no such problems. I am very depressed. Who can help me? 2015-11-14 梁明辉

2 1

Boost 1.60.0 beta 1 Release Candidate 3 available for testing
by Marshall Clow 14 Nov '15

14 Nov '15

Release candidate files for 1.60.0 beta 3 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. Changes since rc1: * Boost.Sprit has been updated and Boost.Log now builds. * Boost.Math has been updated and now builds. [ Note: The RC2 files that I posted yesterday were incorrectly produced. RC3 is identical to what RC2 should have been -- end note ] Known issues: * Errors when building libraries for visual studio: test and type_erasure. * Boost.Test fails when building on Darwin with gcc 4.9.2 The files (and associated md5s) are: MD5 (boost_1_60_0_b1_rc3.7z) = cfac18348700d0e6c1a0e4418a57e9aa MD5 (boost_1_60_0_b1_rc3.tar.bz2) = d3cb5a59e5b38555096814a6bfbcb441 MD5 (boost_1_60_0_b1_rc3.tar.gz) = db9b011547b8933454d0dfe31f7b8551 MD5 (boost_1_60_0_b1_rc3.zip) = 216c7cd0c15c096ece24d2649a272b51 Thanks! -- The release managers

3 4

Seeking advice regarding inline namespaces
by Louis Dionne 13 Nov '15

13 Nov '15

Dear community, I am seeking advice regarding the usage of inline namespaces for header-only metaprogramming libraries. I was at Eric Niebler's talk on C++11 library design back in 2014, and I understand the problem that inline namespaces solve. I also read all of this past thread [1] on the mailing list, but did not find what I was looking for. I also understand how they can be useful for a normal header-only library __that would provide guarantees about ABI compatibility__. Indeed, if the ABI of the library changes from v1 to v2, then any client C1 exposing types from v1 in its interface and trying to link with a client C2 built against v2 will get a clean link-time error instead of a runtime error. Now, my question has several aspects: (1) How can you guarantee ABI compatibility from one version of a library to the next? IIUC, ABI can be broken by merely changing the size or the layout of a type, so guaranteeing backwards ABI compatibility means freezing those things in time, right? (2) Assuming that it is unreasonable for a library L to guarantee ABI compatibility from one version to the next, would there still be a reason to use inline namespaces to version that library? (3) When using inline namespaces to version a library (at all, not necessarily for header only libraries), are there other guidelines to follow? For example, I see that Eric Niebler's range-v3 library is all stuffed in the range/v3 subdirectory. IIUC, this would allow an eventual range-v4 library to cohabit with the range-v3 library, because people explicitly state which version of the library they're including. Is this the reason behind the v3 subdirectory? Any answer or pointer to answers is appreciated. Regards, Louis [1]: http://boost.2283326.n4.nabble.com/type-traits-general-Best-practice-for-in… -- View this message in context: http://boost.2283326.n4.nabble.com/Seeking-advice-regarding-inline-namespac… Sent from the Boost - Dev mailing list archive at Nabble.com.

2 6

Boost 1.60.0 beta 1 Release Candidates available for testing
by Marshall Clow 12 Nov '15

12 Nov '15

Release candidate files for 1.60.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. IMPORTANT NOTE: The files (and associated md5s) are: MD5 (boost_1_60_0_b1_rc1.7z) = ac6b2128d951ad688421fde2d878c2a7 MD5 (boost_1_60_0_b1_rc1.tar.bz2) = 2fc232f255f1ce8868315da207c05b6b MD5 (boost_1_60_0_b1_rc1.tar.gz) = d594e10f2761abaf957a67c6a223d2a4 MD5 (boost_1_60_0_b1_rc1.zip) = 16a2d512fca7995d5fa421d13f841b0f Thanks! -- The release managers

23 49

[property_tree iostreams smart_ptr] Warning fixes
by Joachim Faulhaber 11 Nov '15

11 Nov '15

Dear all, I have submitted pull requests for mostly warning fixes. 3 of them are still open. https://github.com/boostorg/property_tree/pull/15/files https://github.com/boostorg/iostreams/pull/19 https://github.com/boostorg/smart_ptr/pull/18 Could someone merge them in, so we have this fixed for 1.60. That would be nice. Thanx in advance Joachim -- Interval Container Library [Boost.Icl] http://www.joachim-faulhaber.de

1 0

Re: [boost] [Boost-users] Boost 1.60.0 beta 1 Release Candidates available for testing
by Tom Kent 10 Nov '15

10 Nov '15

On Tue, Nov 10, 2015 at 12:05 AM, Raffi Enficiaud < raffi.enficiaud(a)mines-paris.org> wrote: > Le 10/11/15 00:05, Tom Kent a écrit : > >> On Mon, Nov 9, 2015 at 9:52 AM, Marshall Clow <mclow.lists(a)gmail.com >> <mailto:mclow.lists@gmail.com>> wrote: >> >> Release candidate files for 1.60.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. >> >> >> Errors when building libraries for visual studio: test and type_erasure. >> I've grabbed the repeated outputs and posted below. Full logs are at: >> >> 32-Bit: https://gist.github.com/teeks99/bed0ef4204d24677fa4e >> 64-Bit: https://gist.github.com/teeks99/6d0358817ddfe43724f7 >> >> Tom >> > > I have a fix for MSVC but some problems have also been reported for gcc4.4 > c++0x mode. I can merge the fix for MSVC to develop and/or master once > reopened. > > Raffi > Since it is preventing building of the release binaries, I think this should be merged before the beta is released. Tom

3 4

[1.60][spirit] Unmerged changes prevent compilation
by Andrey Semashev 10 Nov '15

10 Nov '15

Hi, The latest 1.60 beta RC fails to build Boost.Log because some changes in Boost.Spirit has not been merged to master. At least these patches need to be merged to master: 1. Fix the duplicate definition of strip_single_element_vector specialization: https://github.com/boostorg/spirit/commit/4d8899fdfe26237d6d983a7ac5528d00f… 2. Fix an attempt to construct an instance of none_t: https://github.com/boostorg/spirit/commit/534cf39f15ced047359ee8b6dfe434635… 3. Although it's not strictly a build breaker, this change fixes a bunch of warnings about signed/unsigned mismatch: https://github.com/boostorg/spirit/pull/140 After applying those patches to the RC Boost.Log builds successfully. These commits and the PR has been in develop for quite some time, could someone merge them to master, please?

4 7

[Range] sorted and randomized adaptors
by Mohammed El-Afifi 10 Nov '15

10 Nov '15

Hello everybody, I know this might have been raised a few times before in this mailing list, but I'd like to know if it's possible(or otherwise what would prevent) to have sorted and randomized adaptors so that I may have a sorted and randomized view of a range respectively. Something like vector<int> x; // operations to fill x x | boost::adaptors::sorted; x | boost::adaptors::randomized;// That one might also take an optional random generator as a parameter. I understand that in this case the adaptor isn't entirely lazy as the adapted(x here) must be completely consumed before producing a single element in the resulting range. I want to know however if having such adaptors may contradict any basic principles of the existing adaptors. P.S. Two other threads I found that discussed the same idea(for sorted only): - http://lists.boost.org/Archives/boost/2009/03/149247.php - http://lists.boost.org/Archives/boost/2006/05/105122.php

3 2

Seeking feedback on SegmentedTreeSeq (sequence data structure with efficient random access insert and erase)
by Chris Clearwater 09 Nov '15

09 Nov '15

Greetings, At this time I would like to solicit feedback for my library SegmentedTreeSeq. It is an implementation of a counted B+Tree that allows efficient random access insert and erase. It's an ideal data structure for an application such as a text editor. I am also seeking interested reviewers as I feel it has reached a state that is ready for formal review. Features: - Implements the union of std::vector, std::deque, and std::list interfaces. - Implements the C++11 allocator model. - Implements the full C++14 interfaces including emplacement and move semantics. - O(log n) to obtain an iterator at any position. - O(log n) insert and erase. - Amortized O(log n) iterator movement. - Strong exception guarantee for insert. - Support for incomplete types. - SCARY iterators. - Best in class performance for many operations. - Low memory overhead for data of any type. Links: - Incubator: http://rrsd.com/blincubator.com/bi_library/segmentedtreeseq-2/?gform_post_i… - Repository: https://github.com/det/segmented_tree_seq - Documentation: https://det.github.io/segmented_tree_seq Thanks, Chris

2 2

[1.60.0] Release Notes
by Daniel James 08 Nov '15

08 Nov '15

Hello everyone, If you haven't done so already, please can you add your entries to the release notes. Easiest way to do so is to create a pull request by clicking on the pencil icon at the top right of the source code at: https://github.com/boostorg/website/blob/master/feed/history/boost_1_60_0.q… Or if you prefer you can email me. thanks, Daniel

2 1