May 2015 - Boost - lists.boost.org

A GUI Library
by jinhao 09 Nov '17

09 Nov '17

Hi, all I am developing a GUI library, it takes aim at easy-to-use and portable library for modern C++ methods. The project at http://stdex.sourceforge.net A git repository at http://nanapro.codeplex.com A brief at http://nanaproject.wordpress.com/2011/12/16/preliminary-study-of-nana-c-lib… Is there any interest in this library? Regards Jinhao

8 8

Re: [boost] Boost CRC maintainer (Daryle Walker) missing in action?
by Olaf van der Spek 19 Jun '17

19 Jun '17

Hi Daryle, Any luck on your new setup? Gr, Olaf On Mon, Nov 28, 2011 at 1:11 AM, Daryle Walker <darylew(a)gmail.com> wrote: > I can look at it once I've finished my new setup. > > I had to reset my computer after a partial crash years ago. I never > got around to recreating my programming setup. My computer had been > at its maximum Operating System level back then, which is now 3 > versions behind. For the past few months, I've had my sister's old > laptop, with Windows Vista, and am trying to add a programming setup > to it now. > > > On Tue, Nov 22, 2011 at 7:18 AM, Beman Dawes <bdawes(a)acm.org> wrote: >> Hi Daryle, >> >> This guy has volunteered to take over maintenance of Boost CRC. Should >> we take him up on his offer? > >> ---------- Forwarded message ---------- >> From: >> Date: Wed, Nov 2, 2011 at 7:51 AM >> Subject: [boost] Boost CRC maintainer (Daryle Walker) missing in action? >> To: boost(a)lists.boost.org >> >> >> Hi, >> >> It looks like the Boost CRC maintainer (Daryle Walker) is missing in action? >> >> No response to tickets from the past 3 years. What's the procedure in this case? >> >> https://svn.boost.org/trac/boost/ticket/2492 >> https://svn.boost.org/trac/boost/query?component=crc&col=id&col=summary&col… > > -- > Daryle Walker > Mac, Internet, and Video Game Junkie > darylew AT gmail DOT com -- Olaf

2 2

bad include guards
by Steven Watanabe 26 Jan '17

26 Jan '17

AMDG The following pairs of files have identical include guards ./boost/concept_check/general.hpp ./boost/concept/detail/msvc.hpp ./boost/concept_check/msvc.hpp ./boost/concept/detail/msvc.hpp ./boost/filesystem/cerrno.hpp ./boost/cerrno.hpp ./boost/interprocess/containers/tree.hpp ./boost/interprocess/containers/detail/tree.hpp ./boost/mpl/min_max.hpp ./boost/mpl/max.hpp ./boost/mpl/vector/aux_/front.hpp ./boost/mpl/list/aux_/front.hpp ./boost/multi_index/identity_fwd.hpp ./boost/multi_index/identity.hpp ./boost/python/pointee.hpp ./boost/python/detail/pointee.hpp ./boost/spirit/phoenix/closures.hpp ./boost/lambda/closures.hpp ./boost/xpressive/proto/v1_/proto_typeof.hpp ./boost/xpressive/proto/proto_typeof.hpp ./libs/config/test/boost_no_dep_nested_class.ipp ./libs/config/test/boost_has_vc6_mem_templ.ipp ./libs/config/test/boost_no_mem_templates.ipp ./libs/config/test/boost_has_vc6_mem_templ.ipp ./libs/config/test/boost_no_std_allocator.ipp ./libs/config/test/boost_has_vc6_mem_templ.ipp ./libs/conversion/test.hpp ./libs/any/test.hpp ./libs/interprocess/example/print_container.hpp ./libs/interprocess/example/printcontainer.hpp ./libs/interprocess/test/expand_bwd_test_template.hpp ./libs/interprocess/test/allocation_test_template.hpp ./libs/interprocess/test/printcontainer.hpp ./libs/interprocess/example/printcontainer.hpp ./libs/interprocess/test/print_container.hpp ./libs/interprocess/example/printcontainer.hpp ./libs/iostreams/test/detail/utf8_codecvt_facet.hpp ./boost/detail/utf8_codecvt_facet.hpp ./libs/regex/test/regress/test_regex_search.hpp ./libs/regex/test/regress/test_partial_match.hpp ./libs/serialization/test/C.hpp ./libs/serialization/test/A.hpp ./libs/xpressive/perf/regex_comparison.hpp ./libs/regex/performance/regex_comparison.hpp ./tools/inspect/time_string.hpp ./tools/common/time_string.hpp In Christ, Steven Watanabe

5 8

[multiprecision] uses boost::math::gcd without including the header
by Peter Dimov 04 Jan '16

04 Jan '16

include/boost/multiprecision/cpp_int/misc.hpp uses boost::math::gcd (and lcm), but does not include common_factor_rt.hpp.

2 2

[variant] Opinion on boost::safe_get<> and default boost::get<> behavior
by Antony Polukhin 18 Dec '15

18 Dec '15

Hi all, I'm in doubt and would like to hear opinions on the following issue. boost::get for boost::variant was not making any compile time checks, resulting in runtime errors where a compile time error must be: boost::variant<int, string> v(100); boost::get<bool>(&v); // returns NULL instead of compile time error boost::get<bool>(v); // throws exception on runtime instead of compile time error Now we have an implementation of compile time checked get in a separate branch at git: boost::variant<int, string> v(100); boost::safe_get<bool>(&v); // compile time error boost::safe_get<bool>(v); // compile time error boost::unsafe_get<bool>(&v); // returns NULL instead of compile time error boost::unsafe_get<bool>(v); // throws exception on runtime instead of compile time error I'm in doubt, what the default behavior of boost::get must be: * safe_get behavior is much closer to Standard Library behavior (just like std::get for tuples) and allows to avoid errors in user code * unsafe_get behavior is same as behavior of old boost::get and won't break user's code if boost::get is used in some generic contexs What's your opinion? -- Best regards, Antony Polukhin

10 13

[thread] Do we can a non backward compatible version with non-blocking futures?
by Vicente J. Botet Escriba 18 Oct '15

18 Oct '15

Hi, in Boost 1.58 I fixed some issues as the result of the async and future<T>:then() was not a blocking future as the documentation described. However the implementation is horrible and I suspect that it is subject to deadlocks. BTW, I added already some fixes on the develop branch. Sometime ago I started in a branch an implementation that don't use blocking futures [1]. Well the implementation is also horrible after making futures non-blocking, but less ;-) The problem is that now I have some issues with the executors :( Anyway, Gor has told me that with the blocking implementation he is unable to define await_suspend (using resumable functions) >It is just if .then returns a blocking future, I cannot subscribe a callback to .then in await_suspend. >await_suspend(f, cb) { > f.then(cb); >} &will block here preventing coroutine from suspending I don't know yet if he will reach to configure boost::future<T> on the non-blocking branch. My question is if the Boost community will accept (or even wants) a breaking change on a near release (when I would reach to fix the executors issues) including non-blocking futures instead of the current blocking futures. Best, Vicente [1] https://github.com/boostorg/thread/tree/feature/non_blocking_futures

3 13

[WG21 mailing] N4453 Resumable expressions
by Niall Douglas 15 Oct '15

15 Oct '15

I'm finding Chris' paper on resumable expressions instead of compiler magic created resumable functions awfully compelling: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4453.pdf I essentially proposed the same with my functionally composed constexpr basic_future design some months ago. Would anyone else like to comment on this library based instead of compiler based resumable execution? I'm not against some compiler support for resumable execution, but I am finding the await based proposal highly problematic, and Chris does an excellent job in summarising my own thoughts on what's wrong with it. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

10 17

"Simple C++11 metaprogramming"
by Peter Dimov 22 Aug '15

22 Aug '15

I've recently made the mistake to reread Eric Niebler's excellent "Tiny Metaprogramming Library" article http://ericniebler.com/2014/11/13/tiny-metaprogramming-library/ which of course prompted me to try to experiment with my own tiny metaprogramming library and to see how I'd go about implementing tuple_cat (a challenge Eric gives.) Ordinarily, any such experiments of mine leave no trace once I abandon them and move on, but this time I decided to at least write an article about the result, so here it is, with the hope someone might find it useful. :-) http://pdimov.com/cpp2/simple_cxx11_metaprogramming.html

17 55

[context] msvc /SAFESEH
by Jeff Flinn 12 Aug '15

12 Aug '15

I need to build my application with /SAFESEH which uses boost coroutine which uses context. I'm getting the following link errors: 1>libboost_context-vc100-mt-gd-1_53.lib(jump_i386_ms_pe_masm.obj) : error LNK2026: module unsafe for SAFESEH image. 1>libboost_context-vc100-mt-gd-1_53.lib(make_i386_ms_pe_masm.obj) : error LNK2026: module unsafe for SAFESEH image. I've built boost static libs with the same MSVC vesion and options (sans /SAFESEH as it's not a compile/lib option) Compiler/linker versions: Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 16.00.40219.01 for 80x86 Microsoft (R) Incremental Linker Version 10.00.40219.01 Has anyone run into this and resolved the error? Any insight is appreciated. Thanks, Jeff

3 9

Review Request: QVM (generic Quaternion, Vector and Matrix operations library)
by Emil Dotchevski 04 Aug '15

04 Aug '15

Boost QVM defines a set of generic functions and operator overloads for working with quaternions, vectors and matrices of static size. The library also defines vector and matrix data types, however it allows users to introduce their own types by specializing the q_traits, v_traits and m_traits templates. Online documentation and a link to download the source code under the Boost license is available at http://www.revergestudios.com/boost-qvm/. I would like to thank Adam Wulkiewicz for volunteering to be the review manager for QVM and for his valuable initial feedback. Thanks, Emil Dotchevski

13 30

Test Runner Update to vc14.0 - CTP 6
by Tom Kent 23 Jul '15

23 Jul '15

Just a heads up, I have just updated the test runner teeks99-08f-win2012R2-64on64 from vc14.0 - CTP 4 to vc14.0 - CTP 6. The change should show up in the next run of that runner in a few hours. I think some people were waiting to see if MS was fixing some things, so I thought I'd send a message letting people know these results would be available. Tom

7 22

Serializing shared_ptr fails on .template
by Jared McIntyre 15 Jul '15

15 Jul '15

I've run into an issue where VS 2013, and likely earlier versions, fail to serialize a shared_ptr because Visual Studio is choking on the use of ar.template get_helper in load() to remove ambiguity. The issue appears to replicate previous bug report here: https://svn.boost.org/trac/boost/ticket/10727 That report didn't post an example, so instead of adding a new bug, I've posted example code to that existing report. VS 2013 Boost 1.57 Jared McIntyre

3 8

[predef] Using predef-check on 'develop' problem
by Edward Diener 06 Jul '15

06 Jul '15

In a jam file I have for a run test a predef-check which looks like: run test_variadic_macro.cpp : : : [ predef-check "BOOST_COMP_GNUC >= 4.3" "BOOST_OS_QNX == 0" : : <cxxflags>-std=c++0x ] ; When running on QNX with the gcc version greater than 4.3 I would expect that -std=c++0x would not be added as a C++ compile parameter to the run. Yet it is being added to the run. Another test confirms that BOOST_OS_QNX is indeed being set to a non-zero value. Is there a bug in predef-check ? Am I using it incorrectly ?

4 45

Fwd: [SORT] Parallel Algorithms
by Francisco José Tapia 01 Jul '15

01 Jul '15

Hi Steven I had been revising and testing spreadsort, and the results are impressive. I have prepared the benchmarks and include spreadsort. Now the numbers are extracted from a file generated with a random number generator. In a few days I will put all in a git repository for a easy access As I had seen, you use boost::sort for to invoke to spreadsort. If you use this name, which name use for to invoke introsort? I think a good idea can be call the algorithms by their name. If we do this we have the next algorithm list : - spreadsort - spreadsort_integer - spreadsort_float - spreadsort_string - introsort - parallel_introsort - smart_merge_sort - parallel_stable_sort - sample_sort I think it's a simple and easy to understand, because with the name sort, many people think about an algorithm as introsort ( general , not specific for several data types) and not stable. What's your opinion ?

3 19

[coroutine2] add to testing
by Oliver Kowalke 21 Jun '15

21 Jun '15

Hi, I'm uncertain if boost.coroutine2 (C++11-only) will be part to the 1.58 release - a git-submodule exists but not at the list for the regression tests (I've opened a pull-request to boostorg/boost). Could you tell me the status of boost.coroutine2?! thx, Oliver

2 3

[metaparse] Review period starts May 25th and ends June 7th - ongoing
by Christophe Henry 09 Jun '15

09 Jun '15

Dear all, The review of the metaparse library started last Monday. Please consider taking the time to review it and post comments or reviews on this list. Thanks, Christophe ------------------------------------------------------------------------------------------ Dear all, The review of the Metaparse library starts next Monday, May 25th and ends June 7th. Metaparse was written by Abel Sinkovics. Metaparse is a parser generator library for template metaprograms. The purpose of this library is to support the creation of parsers that parse at compile time. This library is intended to be used for embedded domain specific language creation for C++ and can help libraries provide a better interface. It is similar to Boost.Spirit, however while parsers built with Spirit parse at run-time, parsers built with Metaparse parse at compile-time. It makes it possible for library authors to provide an interface that follows the common notation of the problem domain of the library. (eg. SQL queries, grammars, etc written in their common notation instead of similar-looking C++ expressions). For example there is a (yet incomplete) interface for Boost.Spirit that makes it possible to write MPLLIBS_REGEX("^[abcd][3-8]\\.foo$") instead of bos >> set[as_xpr('a')|'b'|'c'|'d'] >> range('3','8') >> '.' >> 'f' >> 'o' >> 'o' >> eos and make the parser built with Metaparse generate the latter expression from the former one. (It can be found here: https://github.com/istvans/mpllibs/tree/master/libs/xlxpressive) Since the library is based on template metaprogramming, the DSLs can be used for type validation as well. This is demonstrated by the type-safe printf implementation ( http://abel.web.elte.hu/mpllibs/safe_printf/index.html) It type-checks the arguments of a printf call based on the format string and has zero runtime overhead compared to unchecked printf. Parsers can be constructed in a declarative manner and (even though this is template metaprogramming based) remain readable. The implementation reflects the grammar it parses (with additional elements for semantic actions). Even though the library requires the parser author to write template metaprograms, the development of parsers is well supported by tools like Metashell and MDB. An important aspect of parsers (built with this library or another one) is error reporting for invalid input. The library offers tools for the parser authors to be able to provide useful error messages in case of parsing errors. Here is an example error report by a parser built with Metaparse (the parser can be found in the Getting Started guide of the library): ..... x__________________PARSING_FAILED__________________x<1, 5, unpaired<1, 1, literal_expected<')'>>> .... It is an error report letting the developer know that a closing paren is missing at line 1, column 5 and the unclosed opening paren is in line 1, column 1. Metaparse can be downloaded from Github: https://github.com/sabel83/mpllibs/tree/master/mpllibs/metaparse And a very complete tutorial: http://abel.web.elte.hu/mpllibs/metaparse/getting_started.html The tutorial also offers the nice feature of a link to metashell for quick-starting trying out the library: http://abel.web.elte.hu/shell/metashell.html Boost.Msm v3 also implements a new compile-time strings based front-end called eUML2 to demonstrate the power of the library and the conciseness and expressiveness it allows. Please have a look at the documentation: https://htmlpreview.github.io/?https://raw.githubusercontent.com/boostorg/m… Everybody on this list is invited to participate in this formal review. I hope to see your review of Metaparse, including your vote on acceptance, and I welcome your participation in the ensuing discussions on the Boost developers' mailing list. Please always include in your review a vote as to whether the library should be accepted into Boost. Additionally please consider giving feedback on the following general topics: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? - With what compiler? - Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? Regards, Christophe Review Manager

9 28

[Boost-announce] [metaparse] Review period starts May 25th and ends June 7th
by Christophe Henry 08 Jun '15

08 Jun '15

Dear all, The review of the Metaparse library starts next Monday, May 25th and ends June 7th. Metaparse was written by Abel Sinkovics. Metaparse is a parser generator library for template metaprograms. The purpose of this library is to support the creation of parsers that parse at compile time. This library is intended to be used for embedded domain specific language creation for C++ and can help libraries provide a better interface. It is similar to Boost.Spirit, however while parsers built with Spirit parse at run-time, parsers built with Metaparse parse at compile-time. It makes it possible for library authors to provide an interface that follows the common notation of the problem domain of the library. (eg. SQL queries, grammars, etc written in their common notation instead of similar-looking C++ expressions). For example there is a (yet incomplete) interface for Boost.Spirit that makes it possible to write MPLLIBS_REGEX("^[abcd][3-8]\\.foo$") instead of bos >> set[as_xpr('a')|'b'|'c'|'d'] >> range('3','8') >> '.' >> 'f' >> 'o' >> 'o' >> eos and make the parser built with Metaparse generate the latter expression from the former one. (It can be found here: https://github.com/istvans/mpllibs/tree/master/libs/xlxpressive) Since the library is based on template metaprogramming, the DSLs can be used for type validation as well. This is demonstrated by the type-safe printf implementation ( http://abel.web.elte.hu/mpllibs/safe_printf/index.html) It type-checks the arguments of a printf call based on the format string and has zero runtime overhead compared to unchecked printf. Parsers can be constructed in a declarative manner and (even though this is template metaprogramming based) remain readable. The implementation reflects the grammar it parses (with additional elements for semantic actions). Even though the library requires the parser author to write template metaprograms, the development of parsers is well supported by tools like Metashell and MDB. An important aspect of parsers (built with this library or another one) is error reporting for invalid input. The library offers tools for the parser authors to be able to provide useful error messages in case of parsing errors. Here is an example error report by a parser built with Metaparse (the parser can be found in the Getting Started guide of the library): ..... x__________________PARSING_FAILED__________________x<1, 5, unpaired<1, 1, literal_expected<')'>>> .... It is an error report letting the developer know that a closing paren is missing at line 1, column 5 and the unclosed opening paren is in line 1, column 1. Metaparse can be downloaded from Github: https://github.com/sabel83/mpllibs/tree/master/mpllibs/metaparse And a very complete tutorial: http://abel.web.elte.hu/mpllibs/metaparse/getting_started.html The tutorial also offers the nice feature of a link to metashell for quick-starting trying out the library: http://abel.web.elte.hu/shell/metashell.html Boost.Msm v3 also implements a new compile-time strings based front-end called eUML2 to demonstrate the power of the library and the conciseness and expressiveness it allows. Please have a look at the documentation: https://htmlpreview.github.io/?https://raw.githubusercontent.com/boostorg/m… Everybody on this list is invited to participate in this formal review. I hope to see your review of Metaparse, including your vote on acceptance, and I welcome your participation in the ensuing discussions on the Boost developers' mailing list. Please always include in your review a vote as to whether the library should be accepted into Boost. Additionally please consider giving feedback on the following general topics: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? - With what compiler? - Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? Regards, Christophe Review Manager

23 76

Moving the include directory to $BOOST_ROOT/include? (again)
by Peter Dimov 04 Jun '15

04 Jun '15

I want to reiterate my suggestion that we move Boost's include directory from $BOOST_ROOT to $BOOST_ROOT/include. This has the following benefits: - it follows the established naming practice, - it does not make the whole Boost reachable from the include path as it does now, - when building Boost, the message given at the end would be The Boost C++ Libraries were successfully built! The following directory should be added to compiler include paths: C:\Projects\boost-git\boost\include The following directory should be added to linker library paths: C:\Projects\boost-git\boost\stage\lib instead of the current The Boost C++ Libraries were successfully built! The following directory should be added to compiler include paths: C:\Projects\boost-git\boost The following directory should be added to linker library paths: C:\Projects\boost-git\boost\stage\lib which is more in line with a user's expectations. - it's more consistent because it builds the virtual include/ subdirectory from the contents of the multiple libs/*/include/ subdirectories. For backward compatibility, "b2 headers" could create a boost/ symlink to include/boost/. Also for backward compatibility, monolithic releases can continue to ship the headers in boost/ if moving the directory would be seen as too disruptive. Failing acceptance of the above proposal, can we at least use a path constant (BOOST_INCLUDE?) somewhere in Jamroot or boostcpp.jam that identifies where the header links are to be placed? Its current contents would be "." but I would be able to change that to "include" instead of locating and patching all the places that refer to the include path.

8 19

Boost.Test v3 is here
by Gennadiy Rozental 02 Jun '15

02 Jun '15

Boost.Test team is proud to present new version of Boost.Test library. This milestone release among many other thing includes: * Completely updated (and hopefully improved) documentation * New universal testing tool BOOST_TEST * Support for decorators * Support for data driven test cases * and much more (you can see changelog here: http://raffienficiaud.github.io/test/boost_test/change_log.html This release would not be possible without Raffi Enficiaud, who joined the team and jump started documentation rework and Andrzej Krzemieński's major contribution to the new documentation. We invite everyone to review and comment on new documentation (http://raffienficiaud.github.io/test/index.html) We will be happy to accept your pull requests with improvements and notes in the mailing list. Unless we find any major showstopper we plan to merge to the master branch in 2-3 weeks time. We do not anticipate backward compatibility issues, but please report any you observe and we'll try to address them in a timely manner. Once again, please review the new documentation and feel free to comment here or by sending us pull requests. Regards, Gennadiy Rozental

8 12

[next gen future-promise] What to call the monadic return type?
by Niall Douglas 01 Jun '15

01 Jun '15

Dear list, As AFIO looks likely to be finally getting a community review soon, I've made a start on a final non-allocating constexpr-collapsing next generation future-promise such that the AFIO you review is "API final". You may remember my experimentations on those from: http://boost.2283326.n4.nabble.com/Non-allocating-future-promise-td466 8339.html. Essentially the win is that future-promise generates no code at all on recent C++ 11 compilers unless it has to [1], and when it does it generates an optimally minimal set with no memory allocation unless T does so. This should make these future-promises several orders of magnitude faster than the current ones in the C++ standard and solve their scalability problems for use with things like ASIO. They also have major wins for resumable functions which currently always construct a promise every resumable function entry - these next gen future-promises should completely vanish if the resumable function never suspends, saving a few hundred cycles each call. Anyway, my earlier experiments were all very promising, but they all had one big problem: the effect on compile time. My final design is therefore ridiculously simple: a future<T> can return only these options: * A T. * An error_code (i.e. non-type erased error, optimally lightweight) * An exception_ptr (i.e. type erased exception type, allocates memory, you should avoid this if you want performance) In other words, it's a fixed function monad where the expected return is T, and the unexpected return can be either exception_ptr or error_code. The next gen future provides Haskell type monadic operations similar to Boost.Thread + Boost.Expected, and thanks to the constexpr collapse this: future<int> test() { future<int> f(5); return f; } test().get(); ... turns into a "mov $5, %eax", so future<T> is now also a lightweight monadic return transport capable of being directly constructed. In case you might want to know why a monadic return transport might be so useful as to be a whole new design idiom for C++ 11, try reading https://svn.boost.org/trac/boost/wiki/BestPracticeHandbook#a8.DESIGN:S tronglyconsiderusingconstexprsemanticwrappertransporttypestoreturnstat esfromfunctions. However, future<T> doesn't seem named very "monadic", so I am inclined to turn future<T> into a subclass of a type better named. Options are: * result<T> * maybe<T> Or anything else you guys can think of? future<T> is then a very simple subclass of the monadic implementation type, and is simply some type sugar for promise<T> to use to construct a future<T>. Let the bike shedding begin! And my thanks in advance. Niall [1]: Compiler optimiser bugs notwithstanding. Currently only very recent GCCs get this pattern right. clang isn't bad and spills a dozen or so completely unnecessary opcodes, and I'll follow up with Chandler with some bug reports to get clang fixed. Poor old MSVC spits out about 3000 lines of assembler, it can't do constexpr folding at all yet. -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

16 122

RFC: Separating Boost.Python from Boost
by Stefan Seefeld 31 May '15

31 May '15

Hello, as I have mentioned here before, I would very much like to continue the modularization effort, by fully separating the Boost.Python project from the rest of Boost. For avoidance of doubt: my intent is not to remove Boost.Python out of the Boost organization. Rather, I would like to separate the build and release processes. For the sake of keeping the discussion focused, I would like to avoid getting into too many (technical) details (there already is a related discussion on the Boost.Build list). Rather, I would like to know whether people here (and Boost.Python users in particular) have any particular thoughts about this proposal. Any strong reasons not to move forward with this ? Things to consider while doing it ? Etc. (My hope is that if the operation succeeds, other Boost libraries may want to do the same, which would help Boost in the long term to become more manageable.) Thanks, Stefan -- ...ich hab' noch einen Koffer in Berlin...

18 62

Thoughts on Trac wiki page commenting facility
by Niall Douglas 31 May '15

31 May '15

Something Robert raised during the meetings at C++ Now was why can't people comment on Boost's Trac wiki pages? The simple answer is because Trac doesn't allow it and hasn't got to implementing it in many years (http://trac.edgewall.org/ticket/11676) despite it being technically as simple as appending a ticket's comments to a wiki page, so I spent some time researching what options are available: 1. https://trac-hacks.org/wiki/WikiCommentsPlugin This works by inserting the comments directly into the article text. Pros: The comments are the document. This lets the page author fix the problem and delete the comment where that is appropriate. Cons: You need a trac login and editing privs to comment, which until a Trac 1.0 upgrade remains manually awarded by a Boost admin. No preview, so you need to know Trac wiki markup. 2. Disqus https://disqus.com/ This is the grand daddy of free commenting services. This works by you inserting some Javascript into the page where you want the comments to appear. AJAX does the rest. This could very easily patched into Trac for every wiki page by tweaking its template as per the instructions at http://trac.edgewall.org/wiki/TracInterfaceCustomization. Pros: Very well understood by users, in fact by everyone. Built in excellent spam protection. Nice UI. Just works. I also have a ton of ready to go infrastructure from nedprod.com for Disqus, so it's really very little effort for me to integrate this. Cons: They own all your data. They serve adverts in the comment stream, though apparently you can now opt out. They track user visits and sell the information, so AdBlock and Ghostery default block Disqus. Comment load times can be very slow. Comments aren't indexed by Google, and this may decrease the value of the system. 3. Keep looking Niall! Like none of the above? There are open source clones of Disqus you can host on your own infrastructure, but I have no experience with any of the those. If the community really doesn't like either of the two above, I guess I can keep looking. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

4 5

[locale] Build failure on develop
by Marcel Raad 30 May '15

30 May '15

Hi, since Tuesday, all Boost.Locale tests have been failing on all compilers: http://www.boost.org/development/tests/dev elop/developer/locale.html The MSVC results only mention an expected has_iconv.cpp build failure and it seems all other results only say "Error extracting file: No matching files were found." I tested on my local machine with MSVC 14 RC and the library wouldn't compile because of a missing "#include <map>": https://github.com/boostorg/locale/pull/8

1 0

[bind] Placeholders suggestion, std and boost
by Edward Diener 30 May '15

30 May '15

I realize that changing boost::bind so by default that placeholders of the form _n needing some sort of namespace in front of it will break plenty of code, so I am not suggesting doing that. What I would like to suggest is a Boost.bind macro, which when used before including <boost/bind>, would put the boost::bind placeholders of the form _n in a boost::placeholders namespace. The reason for this suggestion is so that boost::bind and std::bind can be similar syntactically enough so that one could choose one or the other depending on compiler support. Since in the C++ std the placeholders are in the std::placeholders namespace, having a means to have the boost::bind placeholders in the boost::placeholders namespace would be a means to that end.

5 16

[type_traits] Big changes in develop
by John Maddock 30 May '15

30 May '15

A heads up that the "Version2" rewrite of type traits is now in develop. There's still lots to do - more PR's will happen over the coming weeks to remove obsoleted code from other libraries (and quash the warnings that they'd otherwise generate). The docs also need a major update. In the mean time please do shout loudly if there are any regressions caused by this change. Thanks, John.

8 26

[test] Fwd: [Boost-testing] All test runners (windows and linux) crashing
by Rene Rivera 29 May '15

29 May '15

Boost Test developers please fix ASAP. ---------- Forwarded message ---------- From: Tom Kent <lists(a)teeks99.com> Date: Thu, May 28, 2015 at 8:26 PM Subject: Re: [Boost-testing] All test runners (windows and linux) crashing To: Running Boost regression tests <boost-testing(a)lists.boost.org>, Boost Developers List <boost(a)lists.boost.org> On Thu, May 28, 2015 at 6:24 PM, Tom Kent <lists(a)teeks99.com> wrote: > All my test runners are quickly crashing during each run...here's the end > of the output in my results/bjam.log file: > > boost-test(RUN) "test/doc_boost_test_macro1" : > "libs/test/doc/examples/boost_test_macro1.cpp" > boost-test(RUN_FAIL) "test/doc_boost_test_macro2" : > "libs/test/doc/examples/boost_test_macro2.cpp" > boost-test(RUN_FAIL) "test/doc_boost_test_macro3" : > "libs/test/doc/examples/boost_test_macro3.cpp" > error: at D:/t08/c/boost_bb/src/kernel\modules.jam:107 > error: Unable to find file or target named > error: '../doc/examples/test_float_01.cpp' > error: referred to from project at > error: '../libs/test/test' > > Any thoughts? > Tom > I should have specified, that is on the develop branch. Master seems fine. _______________________________________________ Boost-Testing mailing list Boost-Testing(a)lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-testing -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

2 2

All test runners (windows and linux) crashing
by Tom Kent 29 May '15

29 May '15

All my test runners are quickly crashing during each run...here's the end of the output in my results/bjam.log file: boost-test(RUN) "test/doc_boost_test_macro1" : "libs/test/doc/examples/boost_test_macro1.cpp" boost-test(RUN_FAIL) "test/doc_boost_test_macro2" : "libs/test/doc/examples/boost_test_macro2.cpp" boost-test(RUN_FAIL) "test/doc_boost_test_macro3" : "libs/test/doc/examples/boost_test_macro3.cpp" error: at D:/t08/c/boost_bb/src/kernel\modules.jam:107 error: Unable to find file or target named error: '../doc/examples/test_float_01.cpp' error: referred to from project at error: '../libs/test/test' Any thoughts? Tom

1 1

[type_traits][units] migrating from ice_and
by Jürgen Hunold 28 May '15

28 May '15

Hi! I've noticed that boost/type_traits/detail/ice_or.hpp and boost/type_traits/detail/ice_and.hpp have been deprecated. Both headers are used as an implementation detail in boost/units/scaled_base_unit.hpp, now resulting in lots of warnings: In file included from .../boost/units/scaled_base_unit.hpp:20: .../boost/type_traits/detail/ice_or.hpp:17:10: warning: NOTE: Use of this header (ice_or.hpp) is deprecated [-W#pragma-messages] # pragma message("NOTE: Use of this header (ice_or.hpp) is deprecated") Question: Is there a known migration path from type_traits to what? MPL? Or am I better off copying both files to Boost.Units and be done? Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! * voice: ++49 4257 300 ! Fährstraße 1 * fax : ++49 4257 300 ! 31609 Balge/Sebbenhausen * jhunold(a)gmx.eu ! Germany

3 4

[testing][teeks] MSVC-14 errors about MSPDB140.DLL
by Andrey Semashev 27 May '15

27 May '15

Hi, All tests for Boost.Log (and I suspect any other built libraries) on MSVC-14 are failing because of this error: LINK : fatal error LNK1101: incorrect MSPDB140.DLL version; recheck installation of this product See here for example: http://www.boost.org/development/tests/develop/developer/output/teeks99-08f… Could this be fixed?

4 7

[typeof] Weird VC++ compiler bug
by Edward Diener 27 May '15

27 May '15

I discovered a strange VC++ bug using Boost.typeof. I am not posting this to rag VC++ but wondering if there is some known workaround in Boost or in Boost.config. #include <boost/typeof/typeof.hpp> template <class T> struct dereference { typedef BOOST_TYPEOF_TPL(*T()) type; }; int main() { } Compiling this with VC++12 gives: test_vc_type_of_indirection.cpp(6) : error C2100: illegal indirection test_vc_type_of_indirection.cpp(7) : see reference to class template instantiation 'dereference<T>' being compiled Notice that I am not even instantiating 'dereference'. But if I write: #include <boost/typeof/typeof.hpp> template <class T> struct dereference { void afunction() { typedef BOOST_TYPEOF_TPL(*T()) type; } }; int main() { } all is well, for all the good it does me. BOOST_TYPEOF_TPL(*T()) expands to: typename boost::type_of::msvc_typeid_wrapper<sizeof(*boost::type_of::encode_start(*T()))>::type and if I substitute this directly the same results occur. I can report this to the VC++ bug tracker but wanted to see if this is a known problem with VC++ in Boost, some weird error for which maybe Boost has some workaround syntax.

6 13

Fwd: Binary Region Differentials
by Kenneth Adam Miller 27 May '15

27 May '15

Suppose I have a rather huge binary region. Transferring it by any means is an expensive operation. But changes to it will only be some fraction at worst case as large as the binary region itself, but in practice will typically be regional byte blobs, mostly not more than a single kilobyte long.. Is there any data structure that already handles this, where I could say, have every instance start off from the original binary region, and calculate what any other instance of that data structure has by "applicating the deltas"?

3 4

svn.boost.org SSL cert errro
by Olaf van der Spek 26 May '15

26 May '15

Hi, The certificatie of svn.boost.org has expired (two weeks ago).. -- Olaf

10 19

[branch master] add library to regression tests
by Oliver Kowalke 26 May '15

26 May '15

Hello, could you please add boost.coroutine2 to the regression tests of branch master?! best regards, Oliver

1 0

Aho - Corasick String Search (for searching multiple patterns) Interface
by meghana madhyastha 26 May '15

26 May '15

Hi, In some of my previous mails I had suggested that the Rabin Karp and Aho - Corasick string search algorithms be implemented as a part of the Boost algorithm library. This is primarily because these algorithms perform well for searching for multiple patterns. The Aho - Corasick algorithm works by building a trie (a tree with each node corresponding to an ASCII character) of the patterns strings and traversing the trie to search for the pattern in a given text. Additionally, the Aho - Corasick introduced the concept of "failure pointer/failure node" which is the node to be traversed when there is a mismatch. For more information: http://en.wikipedia.org/wiki/Aho%E2%80%93Corasick_string_matching_algorithm The interface I propose is as follows. 1. The input of the patterns should be strings within a *container*. This is because these algorithms are primarily used for multiple pattern searching. The user can input pointers/iterators to the first and last pattern . The final output which is returned is a container with each pattern and a iterator/pointer to their occurrences (There are multiple patterns so just returning an iterator/pointer to where the patterns first occurs in the pattern will not suffice). 2. Just like the previous string searching algorithms that have been implemented in Boost, there can be an object based interface as well as a procedure based interface. In the object based interface, the trie is constructed and the failure nodes are computed in the constructor (while creating the object). The user can then search the text using the operator(). template <typename patIter> class aho_corasick { public: aho_corasick(patIter first, patIter last): pat_first(first), pat_last(last), head(std::shared_ptr<trie_node>(new trie_node)) { //first and last are pointers/iterators to the first and last patterns in the container gotoFn(head); failureFn(head); } ~aho_corasick () {}; template <typename corpusIter> corpusIter operator ()(corpusIter corpus_first, corpusIter corpus_last) //Note: using the same notation as used in the other search algorithms. Corpus- refers to the text to be searched. I've implemented this and would like to get feedback/suggestions on the code as well as the interface. Where should I put up the code for it to be reviewed ? Thanks, Meghana

1 0

boost [vmd]: configuration issue in Jamfile.v2 for Oracle Solaris Studio compiler
by Aparna Kumta 26 May '15

26 May '15

I am looking at my test run for vmd in develop branch. http://www.boost.org/development/tests/develop/developer/vmd.html under SunOS. My tests are run with cxxflags="-compat=5 -library=stlport4" as configured in user-config.jam An example of a test, http://www.boost.org/development/tests/develop/developer/output/oracle-spar… The test fails as follows: "CC" -std=c++0x -std=c++11 -compat=5 -library=stlport4 -xO4 -mt -erroff=%none -m32 -KPIC -DBOOST_ALL_NO_LIB=1 -DNDEBUG -I".." -c -o "/export/home/sstrunk-tester/boost_regression/boost_sparc-S2_stlport4/results/boost/bin.v2/libs/vmd/test/test_after_identifier_elem.test/sun-stlport4/release/threading-multi/test_after_identifier_elem.o" "../libs/vmd/test/test_after_identifier_elem.cpp" CC: -compat=5 can not be used with -std CC: -library=stlport4 cannot be used with -std=c++11 If I compile the test manually without '-std=c++0x -std=c++11', the test compiles OK. %CC -compat=5 -library=stlport4 -xO4 -mt -erroff=%none -m64 -KPIC -DBOOST_AL0%L_NO_LIB=1 -DNDEBUG -I.. -c -o ./test_after_identifier_elem.o ../libs/vmd/test/test_after_identifier_elem.cpp % It looks like boost_root/libs/vmd/test/Jamfile.v2 needs to be modified for this compiler. Any ideas on how this can be done? Thanks, Aparna

2 3

boost::bind C2664 error with two non-const references
by Nicolas FRANCOIS 25 May '15

25 May '15

Hi, Relatively to this thread http://lists.boost.org/Archives/boost/2015/03/220930.php and this correcting commit 42b5cef177603328ead66bc6a98a3067aebc433d, I still have errors using boost::bind. #include <boost/bind.hpp> #include <boost/function.hpp> struct A { void f(int&, std::vector<int*>&); }; int main(){ A a; auto f = boost::bind(&A:f, &a, _1, _2); } results in error C2664: cannot convert from 'const std::vector<int*> &' to 'std::vector<int*> &' Defining BOOST_NO_CXX11_RVALUE_REFERENCES solves the issue for now. Nicolas FRANCOIS Software Department L-ACOUSTICS Tel : +33 (0) 1 69 63 23 90 Fax : +33 (0) 1 69 63 69 64 www.l-acoustics.com<http://www.l-acoustics.com/> Please consider the environment before printing this email.

2 7

Environment Variables Library?
by Michael Ainsworth 24 May '15

24 May '15

StackOverflow regarding the (non) standardisation of the "setenv" function, does Boost provide a library to interact with environment variables? http://stackoverflow.com/questions/30292642/c-standard-library-stdsetenv-vs… Michael

10 34

[testing][CrystaX.NET] Missing header
by Andrey Semashev 23 May '15

23 May '15

Hi, Many of the CrystaX.NET testers fail to compile tests because of this error: fatal error: crystax/google/sys/select.h: No such file or directory See here for example: http://www.boost.org/development/tests/develop/developer/CrystaX-NET-apilev… Could this be fixed?

2 1

boostdep documentation?
by Robert Ramey 22 May '15

22 May '15

I am interesting in taking a look at boostdep. I see the code in tools/... but I don't see any documentation. Is there any? will there be in the future? Robert Ramey

2 3

Re: [boost] [Better Enums] Interest in/feedback on C++11 enums library
by Anton Bachin 22 May '15

22 May '15

I've been keeping away because I am doing a ton of work on the library, and I don't want to attract too much attention until the work is ready, since there are lots of changes. But, I think I should reply, and I will also give a brief update of the progress at the end of the message. > I suspect this code: > > Depth depth = default_<Depth>(); > > could be made to look like this: > > Depth depth = _default; > > > ie all enums have a constructor that takes a default_t type. The > constructor then calls default_<T>(). > Or something like that. And then change the names to get > > Depth depth = default_; // calls default_impl<T>(); That’s a good idea. I hadn't thought of such a constructor. I will try it out, but I am not sure that it would belong directly in the library, if that's what you mean. It's not clear where one should stop. Should there also be an "invalid" constructor for projects that have such a notion? Are there other special values we can't predict? Perhaps this could be achieved with some kind of extension facility. I will eventually be adding either support for subclassing, or extra macros, or some kind of template-based extensibility. To the other commenters: thanks :) As for progress: there are substantial improvements. - The entire interface is now constexpr, including string functions and iterators. - I ported the interface to C++98, though it still requires __VA_ARGS__. This makes the topic of this message inaccurate. Should I start a new thread for the new version when it's up? - The C++98 conversion means that, in theory, the library should work on MSVC down to VS2005. I will be testing that when I get my new notebook in a few days. If successful, Better Enums will be compatible with the 3 major compiler families. - Eliminated all weak symbols, leaving only standard C++. Some may be brought back later for optimization, but they are no longer required. - When compiling for C++11, there are no more implicit conversions to integers. - The library is now a single header file, containing both the C++11 version and the C++98 port, and all helper macros. - The documentation is getting a major improvement, so please don't look now. The all-constexpr version is unfortunately noticeably slower to compile. The performance test that was previously two times faster than including iostream is now twice as slow, but I can mitigate this with some combination of opt-in and optimization. Anton

1 0

[build][test][gsoc] question about compiling tests with multiple compile params using b2
by Damian Vicino 22 May '15

22 May '15

Hi, I’m working in the safe_float library for the GSOC. For testing I’m using the boost.test library and for building I’m using b2. The implementation have several pieces that are implemented in two flavours, one for compilers supporting FLOAT_ENV and one for those not supporting it. (this is a C++11 feature missed in at least clang and gcc compilers) Right now, the implementation is selected with an #ifdef and I #define them with a -D parameter. My config file for test is: using testing ; lib boost_unit_test_framework ; unit-test test : main-test.cpp [ glob *_test.cpp ] boost_unit_test_framework ; I guess I can generate 2 different executables using 2 targets, duplicating last line and adding something to tell it to pass -DFENV_AVAILABLE, but I couldn’t find how to do that. Having 2 executables for the tests and running them both will provide testing for both compilation paths (when using a compiler supporting FENV). Also, I’m wondering if B2 has the inteligence detect and pass a parameter when using a compiler supporting FENV. Is there any common approach for these situations where conditionally compiling based on a c++ feature support? In the case a Boost.Build needs to define a test for detecting if the compiler supports the feature (autoconf-like) it can be tested compiling a one-liner file: test.fenv.cpp #pragma STDC FENV_ACCESS ON When compiled: clang++ -c test.fenv.cpp test.clang.cpp:1:14: warning: pragma STDC FENV_ACCESS ON is not supported, ignoring pragma [-Wunknown-pragmas] #pragma STDC FENV_ACCESS ON The warning means the feature is not supported. Thanks for any guidance in this area, I’m pretty newbie with the b2 system. Best regards, Damian

2 1

[Better Enums] Interest in/feedback on C++11 enums library
by Anton Bachin 21 May '15

21 May '15

Hello, I’ve just released an enum library that takes advantage of constexpr functions and literal types to provide a nice declaration syntax and decent feature set: https://github.com/aantron/better-enums <https://github.com/aantron/better-enums> I’d like to get feedback on it from the experienced developers here at Boost. Is this approach useful? Are any major features missing? Would this be an interesting candidate for enums in Boost? I am very willing to do further development on this project. The library's basic features are string conversions, value and name listing, some type safety, and a declaration syntax that is based on built-in enums and is easy to learn and use. A much more "advanced” feature is that the generated class is a literal type, and almost everything is constexpr. Here is a simple example, that takes advantage of this, of a compile-time encoding of project policy: https://github.com/aantron/better-enums/blob/master/example/6-traits.cc <https://github.com/aantron/better-enums/blob/master/example/6-traits.cc> . Once I make the iterators constexpr as well, by providing a way to increment them other than mutation (++), it will be easy to write rather involved compile-time algorithms that process Better Enums declarations. Here is an example of a whole bunch of simple compile-time processing already possible: https://github.com/aantron/better-enums/blob/master/example/4-constexpr.cc <https://github.com/aantron/better-enums/blob/master/example/4-constexpr.cc> . Some of that could be useful when C++ declarations are generated by script. The library is all standard C++11 (to the best of my knowledge), except for the usage of weak symbols for some generated constexpr static arrays. I have tested it successfully on clang and g++, but I would need help getting access to more compilers. I believe weak symbols are not a problem for MSVC, but I still don’t believe the library will compile on MSVC since I don’t think MSVC supports enough of C++11 yet. Performance is what I would call excellent. I compared compilation times of these two files to each other: https://github.com/aantron/better-enums/blob/master/test/performance/4-decl… <https://github.com/aantron/better-enums/blob/master/test/performance/4-decl…> https://github.com/aantron/better-enums/blob/master/test/performance/5-iost… <https://github.com/aantron/better-enums/blob/master/test/performance/5-iost…> The first file includes enum.h and declares a bunch of enums, and the second merely includes iostream. On my machine, clang compiled all those enums in about half the time it took to process iostream. g++ was faster on iostream, but only slightly. Using a lot of compile-time expressions would have additional cost, but it has been too small to measure for “realistic” examples from my own usage. I haven’t yet made an example that repeatedly deals with a very large enum at compile time to properly measure that impact. I’ve also explored an alternative interface where the constexpr properties provided by the library are in a traits class parametrized by a normal C++11 enum class, but the interface seemed too verbose. There is also a bitset type that has a very slightly nicer interface than std::bitset for usage with enums, but I didn’t think the improvement was worth the user’s learning effort. I can put these in branches if there is interest, however. Please let me know what you think. Best, Anton

5 4

[BOOST_FOREACH] Problem to iterate on a non-copyable container...
by nico 21 May '15

21 May '15

I'm not sure of the title, because I'm not sure the issue comes from the "copyablility" of my container. I tryied quite everything but I can't get rid of this error. Here is a simplified version of my code (please do not challenge the class design, I really would like to keep the end-used syntax in the BOOST_FOREACH): template <typename T> class MyContainer { public: typedef typename std::vector<T>::iterator iterator; typedef typename std::vector<T>::const_iterator const_iterator; MyContainer(std::vector<T>& vec, boost::mutex& mutex) : m_vector(vec), m_lock(mutex) { } iterator begin() { return m_vector.begin(); } const_iterator begin() const { return m_vector.begin(); } iterator end() { return m_vector.end(); } const_iterator end() const { return m_vector.end(); } private: std::vector<T>& m_vector; boost::lock_guard<boost::mutex> m_lock; }; template <typename T> struct GetContainer { GetContainer(std::vector<T>& vec, boost::mutex& mutex) : m_vector(vec), m_mutex(mutex) { } MyContainer<T> Get() { return MyContainer<T>(m_vector, m_mutex); } std::vector<T>& m_vector; boost::mutex& m_mutex; }; int main() { std::vector<int> v; v.push_back(1); v.push_back(2); boost::mutex m; GetContainer<int> getter(v, m); BOOST_FOREACH(int i, getter.Get()) { std::cout << i << std::endl; } return 0; } The compiler complains about not having a copy constructor for MyContainer<int>::MyContainer(const MyContainer<int>&) I also have : error: no matching function for call to ‘MyContainer<int>::MyContainer(boost::foreach_detail_::rvalue_probe<const MyContainer<int> >::value_type)’ I follow the extensibility tips: http://www.boost.org/doc/libs/1_58_0/doc/html/foreach/extensibility.html#fo… But, making MyContainer<T> : private boost::noncopyable doesn't solve the issue. Nor defining the function boost_foreach_is_noncopyable or specializing the template struct is_noncopyable for MyContainer<int> (in fact, how would I specialize this template for a template type ?) Last "tip": If I remove the mutex and the lock from everywhere (I just pass the vector to GetContainer and to MyContainer<T>, it works. But it doesn't work if I make MyContainer<T> : private boost::noncopyable (I expected it should, so I'm not sure my problem is with BOOST_FOREACH, but maybe because I return a copy of MyContainer with my getter ?) I thank you if you read me until here, and thanks in advance for help.

3 4

What does "xml this : this.qbk" do?
by Peter Dimov 21 May '15

21 May '15

Documentation Jamfiles often contain a line like xml core : core.qbk ; What does this line do? Is "xml" a rule? I haven't been able to find it anywhere.

2 1

Questions about upcoming review of Boost.AFIO
by Niall Douglas 21 May '15

21 May '15

Dear list, Ahmed has volunteered to review manage AFIO (thanks Ahmed!), however I wanted to get the list's feedback on some things first. 1. After collecting feedback at C++ Now from members of WG21 on the shape and preferred future of a race free Filesystem TS, the next iteration of AFIO will have a radically different API consisting of the form: std::vector<afio::future<T>> afio::batch(...) afio::future<T> afio::async_io_handle::operation(inputs) noexcept(is_nothrow_move_constructible<T>) T afio::io_handle::operation(inputs) T afio::io_handle::operation(error_code &ec, inputs) The internal engine is the same very well tested code, just the API is very different from before. The current API was forced by VS2010's limitations and the lack of constexpr in MSVC - now VS2015 RTM has C++ 11 constexpr, I can adopt the custom future based API I always originally wanted. This new API will require C++ 14 in the compiler. Question: Given the API will so radically change, is now the time for a community review? Do note that APIBind allows me to support the existing API and the new API concurrently without issue. 2. AFIO requires APIBind which is a separate library. APIBind is not yet in the review queue and it is pending me writing up its documentation and a more useful unit test suite. Is this a problem? Do note that you the user of AFIO will never need to know about APIBind, it is entirely an internal implementation detail. Comments appreciated. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

8 10

More cool free github tooling: https://reviewable.io/
by Niall Douglas 21 May '15

21 May '15

Dear list, I'm not sure about other libraries, but in Boost.Thread Vicente the primary maintainer does the lion's share of dealing with pull requests but he occasionally needs someone else to review a patchset or a pull request before it can be merged. Github's facilities for this are okay - you can comment per line of a pull request, and overall. It works, though one wishes for something more gerrit like. So enter a new free tool with github integration: https://reviewable.io/. One click install into your github project. You now gain an alternative UI for pull requests, one which is much better than the default Github UI, specifically: * Per file review gating like gerrit * Can publish a group of per-line comments as a single thing (and just one email notification) * Doesn't hide deleted change history * Diffs are much better calculated and presented I've turned it on for AFIO. We'll see how it goes. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

1 0

Some statistics about the C++ 11/14 mandatory Boost libraries
by Niall Douglas 21 May '15

21 May '15

Tomorrow at 11am after Eric's talk I'll be presenting at C++ Now a review of the upcoming C++ 11/14 mandatory Boost libraries. I looked at fifteen libraries and decided ten were worth further investigation. I'm sure you all remember my colour coded ranking of those ten libraries by "nearness" to entering Boost: https://goo.gl/6l1KiH I sadly only have time to review four of those libraries during my talk, but one (APIBind) enables an alternative Boost 2.0 approach and I will spend 45 mins on that library alone. And here is my alternative Boost 2.0 vision: Boost 2.0 is a alternative distro of modular standalone Boost libraries which can be each downloaded separately. Each has contemporary per commit CI testing and is nightly dashboarded by quality score by a web service under the 19 quality score headings listed at https://svn.boost.org/trac/boost/wiki/BestPracticeHandbook (still unfinished, but nearly there). APIBind allows the library end user to dependency inject what dependencies that library uses. This allows a Boost library, in a single codebase, to be part of both the monolithic Boost 1.x distro and to be modular and standalone and part of the Boost 2.x distro. Motivated library maintainers port their Boost 1.x library to the APIBind platform, and therefore can be part of both 1.x and 2.x distros if they want. Those libraries not ported to APIBind remain in the 1.x distro, which I would assume will gradually fade into obsolescence over time. This makes sense, as if a maintainer is not motivated to do the port then it seems proper that library should gracefully deprecate. There is some empirical data supporting the inevitability of this alternative vision of Boost 2.0. Of the ten libraries I examined in any detail: * Just 1.5 libraries have any dependencies on Boost headers at all (the 0.5 is because that library is currently removing its Boost dependencies). * Just 3 libraries can use Boost.Test. * Just 3 libraries use Boost Docs. * Just 2 libraries require using Boost.Build. The rest are header only, or use cmake. * Just 6 libraries use Travis/Appveyor for free CI testing on Linux, OS X and Windows. * Just 3 libraries use valgrind as part of their unit testing (two are mine!). * Just 3 libraries use coveralls for coverage reporting (two are mine!). Personally speaking, I think the new library authors are overwhelmingly voting for a complete break with Boost 1.x. It makes no sense to bundle these new libraries into a 1.x monolithic distro when they have no dependencies on Boost. I believe now is the time we start establishing the infrastructure to shape the new Boost 2.0 distro instead of wasting resources on trying to refactor the 1.x distro. APIBind is there for maintainers wanting to be part of both distros. Let's make a clean break. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

28 133

Deprecation Policy
by Rob Stewart 21 May '15

21 May '15

Some Boost libraries are unmaintained, some are under-maintained, and others have been replaced by newer libraries or by the Standard Library. Boost needs to decide whether to deprecate such libraries, and if so, how and when to do it. Please consider my initial thoughts below and provide ideas on such a policy. I will try to capture your ideas and create a policy statement for later review. It would seem obvious that unmaintained libraries should be deprecated, but a library that works, even if it has some known bugs, doesn't grow worse over time. Thus, if an unmaintained library was included in one Boost release, continuing to include it is no worse than before. That implies that deprecating Unmaintained libraries is not a given. Another issue is deciding when a library is unmaintained. Boost prefers that library authors and maintainers seek a replacement when no longer able to provide maintenance. Unfortunately, that doesn't always happen. Thus, establishing criteria by which to judge a library as unmaintained is warranted. Many continue to use C++03 and benefit from the presence of libraries that only support that language. I think it a non-starter to suggest that a library is unmaintained, or under-maintained, because it hasn't been updated to use C++11/14. Indeed, a replacement library may be the better way forward, while the old library might remain in Boost releases. Some have suggested that libraries with Standard Library equivalents be considered deprecated. Note that such libraries provide equivalent or similar functionality for older compilers, so I think that they should be treated the same as C++03-only libraries. Libraries that have superior replacements in Boost releases seem like obvious candidates for deprecation. There is precedent for that: Boost.Signals was deprecated in favor of Boost.Signals2. There are some likely libraries in this category, such as Boost.Lambda. Once we reach consensus on how to identify libraries to deprecate, we then must decide on the process. How long should a deprecated library be released before it is removed from Boost releases? How do we mark deprecated libraries? What do we do with deprecated libraries that have been removed from Boost releases? ___ Rob (Sent from my portable computation engine)

12 33

[preprocessor] Link to Boostpro site for introduction to preprocessor metaprogramming
by Edward Diener 20 May '15

20 May '15

The preprocessor documentation has a link to the Boostpro site which had an html version of the Appendix A of "C++ Template Metaprogramming" by Abrahams and Gurtovoy. Appendix A is "An Introduction to Preprocessor Metaprogramming", which is all about Boost PP. Alas Boostpro is no more and the link in the preprocessor documentation goes nowhere. I can remove the link and any notice of the introduction. But If either David Abrahams or Aleksey Gurtovoy are still around it would be nice to get the html pages which existed before and incorporate them into the Boost PP docs. Does anyone know how to contact either of them ? I can try their addresses in maintainers.txt but I do not want to directly encroach on their privacy if there is a better way.

2 4

Interest in non-intrusive signal/slot lib?
by Emil Dotchevski 20 May '15

20 May '15

Hello, I realize that Boost has Signals library already, but I've implemented a non-intrusive one which approaches the problem differently, and I'm pretty sure that there is no overlap between the two. It turned out more generic than I originally anticipated, so I thought I'd ask if others would find it useful as well. Specifically I was motivated by wanting to use Qt without MOCing. I asked the Qt community if that was possible which generated several rather annoyed negative responses. :) The issue is that while in Qt it's possible to use any function as a Slot, to define a new Qt signal for an existing Qt type one needs to derive from the Qt type, define the signal (as a member function) and do the MOC dance -- which I wanted to avoid. The result is a small, non-intrusive signals/slots library that allows objects of any type to be used as signal emitters, e.g. one of the included examples shows how signals can be emitted by a Windows HWND object. Documentation and source code released under the Boost license can be found here: http://www.revergestudios.com/boost-synapse/. Thanks, Emil P.S. Thanks to Peter Dimov for his feedback and for coming up with the name Synapse. :)

9 48

Version mismatch on develop
by Peter Dimov 20 May '15

20 May '15

On the current develop, autolink wants to link to (for instance) libboost_filesystem-vc80-mt-s-1_59.lib, but b2 builds libboost_filesystem-vc80-mt-s-1_58.lib. That's because BOOST_VERSION has been updated to 1.59 in boost/version.hpp, but is still 1.58 in Jamroot.

2 1

[type_traits] A bug in has_nothrow_default_constructor
by Andrzej Krzemienski 20 May '15

20 May '15

Hi All, I have submitted a new ticket: https://svn.boost.org/trac/boost/ticket/11324 Given the information floating around that Boost.TypeTraits are unmaintained and that they are to be replaced with the rewrite, is there any chance that this is fixed, or at least the test case added to regression matrix? BTW, does type_traits v2 handle this case correctly? Regards, &rzej

2 2

[Testing] Android clang tests
by John Maddock 20 May '15

20 May '15

Since all the Android/clang tests which use PCH are failing, can we either: * Change the build options to disable PCH, or better, * Fix the clang toolset? Someone who understands clang on Android would have to do the latter. See http://www.boost.org/development/tests/develop/developer/output/CrystaX-NET… for an example fail. Many thanks, John.

3 4

crash in boost/date_time/microsec_time_clock.hpp:70 v1.55
by George Georgiev 20 May '15

20 May '15

Hi, I am having crash in in local_time () at boost155_lin32_gcc480//include/boost/date_time/microsec_time_clock.hpp:70 I can call this in isolation and there is no issues, but in the production calls it crashes 100% reproducible with Program terminated with signal SIGABRT, Aborted. The only difference I could think about it is that the call is made from a dynamically loaded library. Is there any known issue about this? Thanks, George

4 3

Getting a trac id
by Steven Ross 19 May '15

19 May '15

I have a bug filed against my library, but with no trac ID I can't modify the bug. How do I get a trac ID?

2 1

RemoteCall framework for RPC
by Alex Marmer 19 May '15

19 May '15

Hello, I created a C++ framework RemoteCall which allows to use RPC the same way as local C++ calls are used. For declaration, implementation and call used macros: DECLARE_REMOTE, IMPLEMENT_REMOTE, CALL_REMOTE.Return and parameters (In and In/Out) can be any type except pointers. For instance: std::tuple<in, bool> DECLARE_REMOTE(Test)(std::vector<std::string>& vInOut, const std::wstring& sIn). Implementation is on https://github.com/amarmer/RemoteCall Would it be useful to add this framework in Boost? Sincerely,Alex

4 8

[all][testing] Regression summary upgrades
by Adam Wulkiewicz 18 May '15

18 May '15

Hi, Recently the regression summary was upgraded. The cells corresponding to the failing tests can have names comp, link, run or fail. This way we can see what's the nature of the failure without going into details. See, e.g. the tests for Math: http://www.boost.org/development/tests/develop/developer/math.html The last category of failures (generic "fail") is for the others or unknown. Currently the "Lib" errors are falling into this category. There are some in Math, e.g.: http://www.boost.org/development/tests/develop/developer/output/CrystaX-NET… So we could mark them explicitly as "lib" failures and then the other/unknown failures could be marked as "unkn" or left as it is now - "fail". This has sense if there can be other "types" of failures, e.g. caused by some error in the testing scripts, Build or Regression, for which the reason is somehow unknown. Though I haven't seen them. I propose to go further with this and to mark the compilation failures for which we know the reason of the failure in a special way: - "file" - file too big (reported on Windows, e.g. http://www.boost.org/development/tests/develop/developer/output/MinGW-w64-4…) - "time" - time limit exceeded (e.g. http://www.boost.org/development/tests/develop/developer/output/teeks99-03b…) I saw them in many libraries and I think it would be very useful for libraries having many tests like Math or Geometry. The other types of failures I could think of aren't that important for me personally but maybe someone could appreciate them, e.g. the compilers developers: - "ierr" or "cerr" - internal compiler error or segmentation fault during compilation (e.g. http://www.boost.org/development/tests/develop/developer/output/PNNL-RHEL6_… or http://www.boost.org/development/tests/develop/developer/output/teeks99-03h…) - "segf" - segmentation fault during run (http://www.boost.org/development/tests/develop/developer/output/BenPope%20x…) Furthermore I propose to use various colors for different failure reasons. You can see the examples here: https://github.com/awulkiew/summary-enhancer https://github.com/awulkiew/summary-enhancer/tree/master/example/pages Of course the colors could be changed. We should be able to modify them in the master.css file. In the examples above they are varying much to make a clear distinction between them. But if you like the yelow collor then all of the new failures could be yelowish with a slight accent of another color, e.g. compilation errors could be yellow with orange accent and "time"/"file" errors with green accent. Regards, Adam

11 27

Spirit 3.0.0
by Joel de Guzman 18 May '15

18 May '15

Hello! C++ Now 2015. Today is the official release of Spirit X3, aka Spirit 3.0.0. X3 will be in beta, coexisting side by side with Qi, Karma, Lex and Classic. If you are a Qi user. The best place to start are the examples, especially rexpr and x3 fun. Remember to use a compiler with c++14 capabilities: clang 3.4 or greater gcc 4.9 or greater Follow this link for more: http://boost-spirit.com/home/2015/05/16/spirit-3-0-0/ Cheers! -- Joel de Guzman http://www.ciere.com http://boost-spirit.com http://www.cycfi.com/

4 5

[type_traits] Time to upgrade to "version 2" ?
by John Maddock 17 May '15

17 May '15

Now that the release is out it's decision time: I'd like to merge the "Version2" branch of type_traits to develop, it passes all the tests, and I've been using it exclusively for testing and development locally for a few months now without issues. But.... it's a big change with the potential to break a lot of folks stuff if things go wrong given that this is such a core component. To recap the main advantages are: * Removed all the redundant cruft that's no longer required for old/broken compilers we don't support anymore anyway. * Very nearly dependency free (other than Config), there's just comon_type which still has dependencies elsewhere - and even that disappears for a C++11 compiler. * Much cleaner, easier to understand code, now that the horrid obfuscating macros introduced by MPL have gone. * Fewer template instantiations than before as much of the indirection / forwarding templates have been removed. * As a result code using these headers should be somewhat faster to compile - both with fewer template instantiations, and a much lighter #include load. Note that as a result of this change, a number of undocumented headers which were none the less being used in Boost have been deprecated. The headers still exist, but warn loud and clear about their deprecated status, so folks will get a lot of warnings to begin with. I know Edward Diener has submitted some PR's to fix these, but I plan to make a concerted attack on any remaining once the new version is in develop. So here's the question, how do we proceed? My thoughts are to basically go ahead and merge, but not merge to master until after the next release at the earliest to give everything a chance to bed down, and the required changes in other libraries to filter through. Or we could have some sort of mini-review either formally or informally to check things out before the merge - of course folks are most welcome to do this anyway! Let me know what you think, best, John.

9 14

[type_traits] difference in decay semantic between boost and standard library
by Anton Bikineev 17 May '15

17 May '15

Hi Boost, Is it expected semantic of boost::decay not to strip top-level constness? Thanks.

1 0

[testing] Regression unresolved issues page
by Adam Wulkiewicz 15 May '15

15 May '15

Hi, The unresolved issues page seems to be outdated (only msvc-8.0 failures can be found there): http://www.boost.org/development/tests/develop/developer/issues.html It's because from all required toolsets mentioned here: https://github.com/boostorg/boost/blob/develop/status/explicit-failures-mar… only the msvc-8.0 is currently tested. The required compilers are quite old ones. I'm not sure how we should addres this issue. I get an impression that in the past this page was used differently than it is now. I'm not sure how though. The ToC/menu is also missing. Anyway, we could: - add only some specific, more modern required toolsets to the explicit-failures-markup.xml - ignore the required toolsets entries and display the issues detected in a library for all non-disabled toolsets - remove the issues page I'd probably go with the second option and treat this page as a complement of the regression matrix. What do you think? Regards, Adam

1 0

[ELFIO] - New library proposal
by Serge Lamikhov-Center 15 May '15

15 May '15

Hello Boost community! I'd like to determine interest in possible new library submission. ELFIO is header-only C++ library that provides a simple interface for reading and generating files in ELF binary format. It is a mature library and is in use by a number of open source and commercial projects. It is a part of some Linux distributions as well as Cygwin project. Would you please have a look at the library's home page located at: http://elfio.sourceforge.net Documentation: http://elfio.sourceforge.net/elfio.pdf Library download: http://sourceforge.net/projects/elfio/files/ELFIO-sources/ELFIO-3.1/ and its source code available through: http://github.com/serge1/ELFIO Please share your opinion on making this library be a part of the Boost. Thank you and Best regards, Serge

5 6

[test] Problem with BOOST_TEST_MESSAGE
by Edward Diener 15 May '15

15 May '15

In testing out a library with Boost.Test I want to inject informational messages that will appear in the output of the test results. When I use BOOST_TEST_MESSAGE with the correct logging level my message appears in the output if there is some sort of Boost.Test error during my tests. However if my unit test does not have a Boost.Test error my BOOST_TEST_MESSAGE does not appear. Needless to say I always want my BOOST_TEST_MESSAGE messages to always appear in the output. Is there a solution to this ?

4 12

[website] Broken uBLAS link
by Renato Florentino Garcia 14 May '15

14 May '15

Hi, The link to uBLAS documentation page on http://www.boost.org/doc/libs points to http://www.boost.org/doc/libs/release/libs/numeric/ublas/doc/index.htm instead of http://www.boost.org/doc/libs/release/libs/numeric/ublas/doc/index.html There are a missing l on .html Regards, Renato Garcia

1 0

[testing] Looking for test runner owner
by Andrzej Krzemienski 14 May '15

14 May '15

Hi All, The test matrix in branch 'master' contains these two test runners: oracle-intel-S2-stlport4 <http://www.boost.org/development/tests/master/oracle-intel-S2-stlport4.html> and oracle-sparc-S2-stlport4 <http://www.boost.org/development/tests/master/oracle-sparc-S2-stlport4.html> Could the owner of these reply to me? I am trying to fix a bug on this platform in Boost.Optional, and would require some assistance. Regards, &rzej

2 1

[variant] 1.58 boost/variant/get.hpp compile errors
by Maarten de Vries 14 May '15

14 May '15

Hello list, I recently updated to boost 1.58 and one of my programs didn't compile any more. The reason was the <boost/variant/get.hpp> header. A simple test program and compiler output is attached below. Swapping the order of the includes or including <boost/type_traits/remove_cv.hpp> before <boost/variant/get.hpp> in the test program will get rid of the errors. It would appear that <boost/variant/detail/element_index.hpp> should include <boost/type_traits/remove_cv.hpp>. Kind regards, Maarten de Vries Test program: #include <boost/variant/get.hpp> > #include <boost/variant/variant.hpp> > > int main() { > return 0; > } > Compiler output g++ (GCC) 4.9.2 20150304 (prerelease): In file included from /usr/include/boost/variant/get.hpp:24:0, > from test.cpp:1: > /usr/include/boost/variant/detail/element_index.hpp:38:69: error: > ‘remove_cv’ in namespace ‘boost’ does not name a template type > variant_element_functor<boost::mpl::_1, typename > boost::remove_cv<T>::type > > ^ > /usr/include/boost/variant/detail/element_index.hpp:38:78: error: expected > template-argument before ‘<’ token > variant_element_functor<boost::mpl::_1, typename > boost::remove_cv<T>::type > > > ^ > /usr/include/boost/variant/detail/element_index.hpp:38:78: error: expected > ‘>’ before ‘<’ token > /usr/include/boost/variant/detail/element_index.hpp:38:88: error: template > argument 2 is invalid > variant_element_functor<boost::mpl::_1, typename > boost::remove_cv<T>::type > > > ^ > /usr/include/boost/variant/detail/element_index.hpp:39:9: error: expected > ‘::’ before ‘>’ token > > > ^ > /usr/include/boost/variant/detail/element_index.hpp:39:9: error: expected > identifier before ‘>’ token > /usr/include/boost/variant/detail/element_index.hpp:39:9: error: template > argument 2 is invalid > /usr/include/boost/variant/detail/element_index.hpp:40:5: error: expected > ‘::’ before ‘>’ token > > > ^ > /usr/include/boost/variant/detail/element_index.hpp:40:5: error: expected > identifier before ‘>’ token > /usr/include/boost/variant/detail/element_index.hpp:40:5: error: template > argument 2 is invalid > /usr/include/boost/variant/detail/element_index.hpp:41:1: error: expected > ‘::’ before ‘{’ token > {}; > ^ > /usr/include/boost/variant/detail/element_index.hpp:41:1: error: expected > class-name before ‘{’ token >

3 3

Community Maintainence Team - a Modest proposal
by Robert Ramey 13 May '15

13 May '15

Today at 12:45 in Bethe is the operations meeting of the Boost Community Library Maintainence team. In advance of that meeting I'd like to render my proposal on this list so I have it written down. Premise:The library maintainence team does not and will likely never have sufficient resources to maintain libraries without current maintainers. Proposal: a) The CMT will solicit volunteers to take over maintainence of specific libraries. b) The most likely source of such volunteers are those working in companies which use and depend upon the libraries in maintainence. Such companies will be expected to support the library maintainence by permitting the maintainer to undertake this effort using company time and resources. c) Since we don't have a list of which companies are using which libraries, we will send a solicitation to volunteer to every person who has posted a bug report for the library in question on the TRAC system. I believe this is the most likely source for prospective maintainers. d) Companies that support maintainence of a particular library will be permited to place their logo and link on the TRAC page for that library. So they will receive the following benefits from sponsoring the maintainece of the library. 1) They will be demonstrating their commitment to the high standard of software development that Boost supports. 2) By placing their logo and link on the track page, they will be encouraging and facilitating prospective employees who desire to work for such an organization to contact them. That is, they will have a leg up on attracting the highest quality C++ programmers. 3) They will be guarenteed timely and rigorous maintainence of the library which they depend on. 4) They will have the inside track on proposing and implementing any library enhancements that they desire. 5) They will benefit from collaboration of the boost community which provides numerous valuable benefits: Bug fixes submitted by users, suggestions for enhancements. etc. The value of all these benefits to the sponsoring company will far, far out weigh the incremental cost of the employee time. In many cases, since employees have to maintain the library anyway - the incremental cost is zero anyway. This moves the responsibility for library maintainence to those most willing and able to undertake it. The role of the CMT would be to promote, recruit, certify, and monitor library maintainence. The CMT would have the authority to move the responsability from maintainer to another. The current practice of having a single person/entity responsible for maintainence of a library would continue unchanged. Robert Ramey

4 7

boost serialization and new archive types
by Robert Ramey 13 May '15

13 May '15

I'm here at C++Now and some have approached me about some enhancements to the serialization library. Specifically there is interest in moving the implementation of XML serialization to the latest C++11 of boost. I've gone them one better - While they're at it, how about including JSON and YAML as well? I would be happy to meet with anyone and everyone interested in this while here at the conference. I'm commited to all the operations meetings 12:45 so that time would be out - I'm flexible. Robert Ramey

2 1

Windows XP support survey
by Niall Douglas 13 May '15

13 May '15

The Boost SC suggested I ask about Microsoft Windows XP support in Boost libraries here, so I'd appreciate if library maintainers could state: 1. If they still support Microsoft Windows XP i.e. actively do not use APIs not supported by XP. And if SP3 is the only service pack supported, or if any XP is okay. 2. Whether they regularly test their libraries on a Windows XP machine to ensure their libraries work there. 3. Their personal opinion about when would be best to drop mandatory Microsoft Windows XP support. Individual library maintainers can of course choose to keep supporting it. As we all know, Microsoft Windows XP is no longer supported by Microsoft as of April 2014, however a widely available registry tweak reenables support and updates until 2019. However Visual Studio 2012 cannot run on XP, nor by default can produce binaries which execute on XP, so testing and developing for XP compatibility is going to become increasingly difficult. It may become wise to announce a date that XP support guarantees will be dropped, and any users needing XP support must remain on an older Boost version and/or make use of Boost modularity to mux their own Boost distro. One big reason for thinking about this is that the first C++ 11 mandatory Boost libraries are just around the corner, and they of course need VS2013 or even VS2015 and so therefore cannot promise Windows XP support. There are also a number of post-XP APIs the assumption of which would make some library authors very pleased. For example, I would assume any Boost.Thread v5 would use the Vista only condvar APIs as one can then skip emulating condvars with win32 semaphores which would be an enormous saving of code complexity. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

14 41

Re: [boost] Interest in a container which can hold multiple data types?
by James Armstrong 12 May '15

12 May '15

You're correct in that a vector<boost::any> can achieve the same thing, and that would probably be the better way to implement this internally. I guess the proposal would be to provide the container interface to give some data modification functions and iterators which iterate over only a given type and such. That way there would be a standardized container with methods to deal with the data in a type specific way. -- James Armstrong

5 17

Re: [boost] [boost.org website] Incorrect links on Boost website
by Marek Kurdej 12 May '15

12 May '15

> > From: Daniel James <dnljms(a)gmail.com> > To: boost(a)lists.boost.org > Cc: > Date: Sun, 10 May 2015 20:04:10 +0100 > Subject: Re: [boost] [boost.org website] Incorrect links on Boost website > On 10 May 2015 at 16:10, Michael Levine <shmuel.levine(a)gmail.com> wrote: > > I was browsing through the Boost website this morning and the links on > the > > right sidebar caught my attention. It appears that there is a duplicate > > entry for "coding guidelines for constant integral expressions", under > > Development / Requirements and Guidelines. The first of these links > points > > to the correct page. The second links to a page regarding library > > metadata. I'm not sure who, exactly, to contact for this, so I figured > this > > list would be the most appropriate means to have this addressed. > It's fixed now. Hi, Along these lines, I have spotted a curious detail on 3 Boost mailing lists. The logos (C++ Boost / Boost C++ libraries) point to web pages that are not affiliated in any way to boost. The concerned lists are: - http://lists.boost.org/boost-docs/ points to www [dot] boost [dot] com - http://lists.boost.org/boost-testing/ points to www [dot] boost [dot] com - http://lists.boost.org/geometry/ points to www [dot] osl [dot] iu [dot] edu There are maybe more wrong links that I haven't caught. Can it be fixed, please?. Regards, Marek Kurdej

2 1

A summary of testing with sanitizers
by Ben Pope 12 May '15

12 May '15

Hello all. Now that I've finally managed to get the sanitizers all working properly (correctly linking against the sanitized runtimes) I'd like to present a summary of its output (which I hope doesn't wrap). I would like to point out that the sanitizers may not be able to completely determine whether the code is correct or not, perhaps merely that they do not understand it (inline asm, etc.), and it also looks like some of the errors are in libc++, not Boost. If the code is determined to be correct, I could add entries to the blacklist to make sure the sanitizers ignore the output, but I would prefer not to. Perhaps a better approach would be to mark up the code so that all users of sanitizers benefit, rather than just the test matrix. Suggestions on how to reduce this output (I hope to publish summaries on a regular basis) in the best possible way are welcomed. I've ordered the output by the number of test failures that result from a particular complaint as determined by the command below: cat bjam.log | grep SUMMARY | sort | uniq -c | sort -n -r Count Warning 89 SUMMARY: ThreadSanitizer: data race /home/ben/development/boost/test/build/boost_root/status/../boost/smart_ptr/detail/shared_count.hpp:449:49 in boost::detail::shared_count::shared_count(boost::detail::shared_count const&) 70 SUMMARY: ThreadSanitizer: data race /home/ben/development/boost/test/build/boost_root/status/../boost/smart_ptr/shared_ptr.hpp:392:63 in boost::shared_ptr<boost::detail::thread_data_base>::shared_ptr(boost::shared_ptr<boost::detail::thread_data_base> const&) 69 SUMMARY: ThreadSanitizer: data race /home/ben/development/boost/test/build/boost_root/status/../boost/smart_ptr/detail/sp_counted_base_clang.hpp:31:5 in boost::detail::atomic_increment(int _Atomic*) 44 SUMMARY: ThreadSanitizer: data race /home/ben/development/boost/test/build/boost_root/status/../boost/smart_ptr/shared_ptr.hpp:392:57 in boost::shared_ptr<boost::detail::thread_data_base>::shared_ptr(boost::shared_ptr<boost::detail::thread_data_base> const&) 44 SUMMARY: ThreadSanitizer: data race /home/ben/development/boost/test/build/boost_root/status/../boost/smart_ptr/detail/shared_count.hpp:449:43 in boost::detail::shared_count::shared_count(boost::detail::shared_count const&) 33 SUMMARY: ThreadSanitizer: data race on vptr (ctor/dtor vs virtual call) /home/ben/development/boost/test/build/boost_root/status/../libs/thread/src/pthread/thread.cpp:168:21 in boost::(anonymous namespace)::thread_proxy(void*) 22 SUMMARY: ThreadSanitizer: data race (/home/ben/development/llvm/trunk/build/release/projects/compiler-rt/lib/tsan/libcxx_tsan/lib/libc++.so.1+0x43962) in std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >::assign(char const*, unsigned long) 21 SUMMARY: ThreadSanitizer: data race (/home/ben/development/llvm/trunk/build/release/projects/compiler-rt/lib/tsan/libcxx_tsan/lib/libc++.so.1+0x43991) in std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >::assign(char const*, unsigned long) 21 SUMMARY: ThreadSanitizer: data race /home/ben/development/boost/test/build/boost_root/status/../boost/test/utils/basic_cstring/basic_cstring.hpp:384:13 in boost::unit_test::basic_cstring<char const>::operator=(boost::unit_test::basic_cstring<char const> const&) 21 SUMMARY: ThreadSanitizer: data race /home/ben/development/boost/test/build/boost_root/status/../boost/test/utils/basic_cstring/basic_cstring.hpp:383:13 in boost::unit_test::basic_cstring<char const>::operator=(boost::unit_test::basic_cstring<char const> const&) 21 SUMMARY: ThreadSanitizer: data race /home/ben/development/boost/test/build/boost_root/status/../boost/test/impl/unit_test_log.ipp:118:41 in boost::unit_test::(anonymous namespace)::unit_test_log_impl::set_checkpoint(boost::unit_test::basic_cstring<char const>, unsigned long, boost::unit_test::basic_cstring<char const>) 18 SUMMARY: ThreadSanitizer: data race /usr/local/bin/../include/c++/v1/ios:499:12 in std::__1::ios_base::width() const 15 SUMMARY: MemorySanitizer: use-of-uninitialized-value /home/ben/development/boost/test/build/boost_root/status/../boost/multiprecision/gmp.hpp:331:10 in boost::multiprecision::backends::detail::gmp_float_imp<50u>::~gmp_float_imp() 12 SUMMARY: ThreadSanitizer: heap-use-after-free /home/ben/development/boost/test/build/boost_root/status/../boost/chrono/time_point.hpp:196:20 in boost::chrono::time_point<boost::chrono::steady_clock, boost::chrono::duration<long, boost::ratio<1l, 1000000000l> > >::time_since_epoch() const 11 SUMMARY: ThreadSanitizer: data race /home/ben/development/boost/test/build/boost_root/status/../boost/thread/detail/invoke.hpp:134:14 in _ZN5boost6detail6invokeIPFvNS_7promiseIRiEEEJS4_EEEDTclclsr5boostE7forwardIT_Efp_Espclsr5boostE7forwardIT0_Efp0_EEEOS7_DpOS8_ 11 SUMMARY: ThreadSanitizer: data race /home/ben/development/boost/test/build/boost_root/status/../boost/smart_ptr/shared_ptr.hpp:392:63 in boost::shared_ptr<boost::detail::shared_state<int&> >::shared_ptr(boost::shared_ptr<boost::detail::shared_state<int&> > const&) 10 SUMMARY: MemorySanitizer: use-of-uninitialized-value /usr/local/bin/../include/c++/v1/string:640:63 in std::__1::char_traits<char>::length(char const*) 10 SUMMARY: AddressSanitizer: 4 byte(s) leaked in 1 allocation(s). 8 SUMMARY: AddressSanitizer: 552 byte(s) leaked in 23 allocation(s). 7 SUMMARY: ThreadSanitizer: data race /usr/local/bin/../include/c++/v1/ios:742:54 in std::__1::basic_ios<char, std::__1::char_traits<char> >::fill() const 6 SUMMARY: ThreadSanitizer: data race /usr/local/bin/../include/c++/v1/ios:437:12 in std::__1::ios_base::flags() const 6 SUMMARY: ThreadSanitizer: data race /home/ben/development/boost/test/build/boost_root/status/../boost/thread/detail/invoke.hpp:134:14 in _ZN5boost6detail6invokeIPFvNS_7promiseIiEEEJS3_EEEDTclclsr5boostE7forwardIT_Efp_Espclsr5boostE7forwardIT0_Efp0_EEEOS6_DpOS7_ 6 SUMMARY: ThreadSanitizer: data race /home/ben/development/boost/test/build/boost_root/status/../boost/smart_ptr/shared_ptr.hpp:392:63 in boost::shared_ptr<boost::detail::shared_state<int> >::shared_ptr(boost::shared_ptr<boost::detail::shared_state<int> > const&) 5 SUMMARY: ThreadSanitizer: data race /usr/local/bin/../include/c++/v1/map:1006:47 in std::__1::map<void const*, boost::detail::tss_data_node, std::__1::less<void const*>, std::__1::allocator<std::__1::pair<void const* const, boost::detail::tss_data_node> > >::empty() const 5 SUMMARY: ThreadSanitizer: data race /usr/local/bin/../include/c++/v1/ios:506:22 in std::__1::ios_base::width(long) 5 SUMMARY: ThreadSanitizer: data race /home/ben/development/boost/test/build/boost_root/status/../libs/thread/src/pthread/thread.cpp:85:78 in boost::detail::(anonymous namespace)::tls_destructor(void*) 5 SUMMARY: MemorySanitizer: use-of-uninitialized-value /home/ben/development/boost/test/build/boost_root/status/../libs/serialization/test/test_shared_ptr.cpp:123:5 in void save_and_load<boost::shared_ptr<A> >(boost::shared_ptr<A>&) 5 SUMMARY: MemorySanitizer: use-of-uninitialized-value /home/ben/development/boost/test/build/boost_root/status/../libs/serialization/test/test_shared_ptr_132.cpp:117:5 in void save_and_load<boost_132::shared_ptr<A> >(boost_132::shared_ptr<A> const&) 5 SUMMARY: MemorySanitizer: use-of-uninitialized-value /home/ben/development/boost/test/build/boost_root/status/../libs/serialization/src/basic_iarchive.cpp:443:16 in boost::archive::detail::basic_iarchive_impl::load_pointer(boost::archive::detail::basic_iarchive&, void*&, boost::archive::detail::basic_pointer_iserializer const*, boost::archive::detail::basic_pointer_iserializer const* (*)(boost::serialization::extended_type_info const&)) 5 SUMMARY: MemorySanitizer: use-of-uninitialized-value /home/ben/development/boost/test/build/boost_root/status/../boost/numeric/odeint/stepper/bulirsch_stoer.hpp:202:13 in boost::numeric::odeint::controlled_step_result boost::numeric::odeint::bulirsch_stoer<std::__1::vector<double, std::__1::allocator<double> >, double, std::__1::vector<double, std::__1::allocator<double> >, double, boost::numeric::odeint::range_algebra, boost::numeric::odeint::default_operations, boost::numeric::odeint::initially_resizer>::try_step<void (*)(std::__1::vector<double, std::__1::allocator<double> > const&, std::__1::vector<double, std::__1::allocator<double> >&, double), std::__1::vector<double, std::__1::allocator<double> >, std::__1::vector<double, std::__1::allocator<double> >, std::__1::vector<double, std::__1::allocator<double> > >(void (*)(std::__1::vector<double, std::__1::allocator<double> > const&, std::__1::vector<double, std::__1::allocator<double> >&, double), std::__1::vector<double, std::__1::allocator<double> > co 5 SUMMARY: AddressSanitizer: heap-use-after-free /home/ben/development/llvm/trunk/llvm/projects/compiler-rt/lib/asan/asan_interceptors.cc:403:3 in __asan_memcpy 5 SUMMARY: AddressSanitizer: 936 byte(s) leaked in 6 allocation(s). 5 SUMMARY: AddressSanitizer: 768 byte(s) leaked in 4 allocation(s). 5 SUMMARY: AddressSanitizer: 64 byte(s) leaked in 2 allocation(s). 5 SUMMARY: AddressSanitizer: 576 byte(s) leaked in 4 allocation(s). 5 SUMMARY: AddressSanitizer: 552 byte(s) leaked in 2 allocation(s). 5 SUMMARY: AddressSanitizer: 480 byte(s) leaked in 8 allocation(s). 5 SUMMARY: AddressSanitizer: 368 byte(s) leaked in 4 allocation(s). 5 SUMMARY: AddressSanitizer: 32 byte(s) leaked in 4 allocation(s). 5 SUMMARY: AddressSanitizer: 240 byte(s) leaked in 4 allocation(s). 5 SUMMARY: AddressSanitizer: 1 byte(s) leaked in 1 allocation(s). 4 SUMMARY: ThreadSanitizer: thread leak /home/ben/development/boost/test/build/boost_root/status/../libs/thread/src/pthread/thread.cpp:250:25 in boost::thread::start_thread_noexcept() 4 SUMMARY: ThreadSanitizer: data race /home/ben/development/boost/test/build/boost_root/status/../boost/thread/pthread/pthread_mutex_scoped_lock.hpp:24:23 in boost::pthread::pthread_mutex_scoped_lock::pthread_mutex_scoped_lock(pthread_mutex_t*) 4 SUMMARY: ThreadSanitizer: data race /home/ben/development/boost/test/build/boost_root/status/../boost/thread/pthread/pthread_mutex_scoped_lock.hpp:24:17 in boost::pthread::pthread_mutex_scoped_lock::pthread_mutex_scoped_lock(pthread_mutex_t*) 4 SUMMARY: ThreadSanitizer: data race /home/ben/development/boost/test/build/boost_root/status/../boost/thread/pthread/once_atomic.hpp:128:25 in void boost::call_once<void (&)()>(boost::once_flag&, void (&)()) 4 SUMMARY: ThreadSanitizer: data race /home/ben/development/boost/test/build/boost_root/status/../boost/thread/detail/thread.hpp:116:17 in boost::detail::thread_data<void (*)()>::run() 4 SUMMARY: ThreadSanitizer: data race /home/ben/development/boost/test/build/boost_root/status/../boost/atomic/detail/atomic_template.hpp:134:22 in boost::atomics::detail::base_atomic<unsigned int, int>::compare_exchange_strong(unsigned int&, unsigned int, boost::memory_order, boost::memory_order) volatile 4 SUMMARY: MemorySanitizer: use-of-uninitialized-value /home/ben/development/boost/test/build/boost_root/status/../libs/serialization/test/test_shared_ptr_multi_base.cpp:185:5 in void shared_weak<boost::shared_ptr<Sub>, boost::weak_ptr<Base3> >(boost::shared_ptr<Sub>&, boost::weak_ptr<Base3>&) 4 SUMMARY: MemorySanitizer: use-of-uninitialized-value /home/ben/development/boost/test/build/boost_root/status/../boost/type_index/stl_type_index.hpp:141:40 in boost::typeindex::stl_type_index::pretty_name() const 3 SUMMARY: ThreadSanitizer: data race /home/ben/development/boost/test/build/boost_root/status/../boost/thread/detail/invoke.hpp:134:14 in _ZN5boost6detail6invokeIPFvNS_7promiseIvEEEJS3_EEEDTclclsr5boostE7forwardIT_Efp_Espclsr5boostE7forwardIT0_Efp0_EEEOS6_DpOS7_ 3 SUMMARY: MemorySanitizer: use-of-uninitialized-value /usr/local/bin/../include/c++/v1/string:3767:13 in bool std::__1::operator==<std::__1::allocator<char> >(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&) 3 SUMMARY: MemorySanitizer: use-of-uninitialized-value /home/ben/development/boost/test/build/boost_root/status/../boost/spirit/home/qi/numeric/detail/real_impl.hpp:295:22 in bool boost::spirit::qi::detail::real_impl<double, boost::spirit::qi::real_policies<double> >::parse<char const*, double>(char const*&, char const* const&, double&, boost::spirit::qi::real_policies<double> const&) 3 SUMMARY: MemorySanitizer: use-of-uninitialized-value /build/buildd/glibc-2.21/misc/tsearch.c:356 in tdelete 2 SUMMARY: ThreadSanitizer: data race (/home/ben/development/llvm/trunk/build/release/projects/compiler-rt/lib/tsan/libcxx_tsan/lib/libc++.so.1+0x381e2) in std::__1::__shared_weak_count::__release_shared() 2 SUMMARY: ThreadSanitizer: data race /home/ben/development/boost/test/build/boost_root/status/../libs/thread/test/threads/thread/members/try_join_until_pass.cpp:55:12 in G::operator()() 2 SUMMARY: ThreadSanitizer: data race /home/ben/development/boost/test/build/boost_root/status/../libs/thread/test/threads/thread/members/try_join_until_pass.cpp:54:5 in G::operator()() 2 SUMMARY: ThreadSanitizer: data race /home/ben/development/boost/test/build/boost_root/status/../libs/thread/test/threads/thread/members/detach_pass.cpp:70:5 in main 2 SUMMARY: ThreadSanitizer: data race /home/ben/development/boost/test/build/boost_root/status/../libs/thread/test/threads/thread/members/detach_pass.cpp:69:5 in main 2 SUMMARY: ThreadSanitizer: data race /home/ben/development/boost/test/build/boost_root/status/../libs/thread/test/threads/thread/constr/move_pass.cpp:58:55 in G::operator()(int, double) 2 SUMMARY: ThreadSanitizer: data race /home/ben/development/boost/test/build/boost_root/status/../libs/asio/test/strand.cpp:91:3 in sleep_increment(boost::asio::io_service*, int*) 2 SUMMARY: ThreadSanitizer: data race /home/ben/development/boost/test/build/boost_root/status/../boost/thread/future.hpp:3377:50 in boost::packaged_task<double (int, char)>::packaged_task(boost::packaged_task<double (int, char)>&&) 2 SUMMARY: ThreadSanitizer: data race /home/ben/development/boost/test/build/boost_root/status/../boost/thread/future.hpp:3377:11 in boost::packaged_task<double (int, char)>::packaged_task(boost::packaged_task<double (int, char)>&&) 2 SUMMARY: ThreadSanitizer: data race /home/ben/development/boost/test/build/boost_root/status/../boost/thread/detail/invoke.hpp:134:14 in _ZN5boost6detail6invokeIPFvNS_13packaged_taskIFdicEEEEJS4_EEEDTclclsr5boostE7forwardIT_Efp_Espclsr5boostE7forwardIT0_Efp0_EEEOS7_DpOS8_ 2 SUMMARY: ThreadSanitizer: data race /home/ben/development/boost/test/build/boost_root/status/../boost/smart_ptr/shared_ptr.hpp:392:63 in boost::shared_ptr<boost::detail::shared_state<void> >::shared_ptr(boost::shared_ptr<boost::detail::shared_state<void> > const&) 2 SUMMARY: ThreadSanitizer: data race /home/ben/development/boost/test/build/boost_root/status/../boost/smart_ptr/shared_ptr.hpp:334:35 in boost::shared_ptr<boost::detail::task_base_shared_state<double (int, char)> >::shared_ptr() 2 SUMMARY: ThreadSanitizer: data race /home/ben/development/boost/test/build/boost_root/status/../boost/smart_ptr/detail/shared_count.hpp:114:21 in boost::detail::shared_count::shared_count() 2 SUMMARY: ThreadSanitizer: data race /home/ben/development/boost/test/build/boost_root/status/../boost/log/utility/once_block.hpp:91:24 in boost::log::v2_mt_posix::aux::once_block_sentry::executed() const 2 SUMMARY: MemorySanitizer: use-of-uninitialized-value /home/ben/development/boost/test/build/boost_root/status/../boost/multiprecision/gmp.hpp:159:10 in boost::multiprecision::backends::detail::gmp_float_imp<50u>::operator=(long) 2 SUMMARY: MemorySanitizer: use-of-uninitialized-value /home/ben/development/boost/test/build/boost_root/status/../boost/geometry/strategies/cartesian/point_in_box.hpp:36:34 in bool boost::geometry::strategy::within::within_range::apply<double, double>(double const&, double const&, double const&) 2 SUMMARY: MemorySanitizer: use-of-uninitialized-value /home/ben/development/boost/test/build/boost_root/status/../boost/container/vector.hpp:2774:7 in boost::container::container_detail::vec_iterator<boost::container::stable_vector_detail::node_base<void*>**, false> boost::container::vector<boost::container::stable_vector_detail::node_base<void*>*, boost::container::allocator<boost::container::stable_vector_detail::node_base<void*>*, 2u, 0u> >::priv_forward_range_insert<boost::container::container_detail::insert_value_initialized_n_proxy<boost::container::allocator<boost::container::stable_vector_detail::node_base<void*>*, 2u, 0u>, boost::container::stable_vector_detail::node_base<void*>**> >(boost::container::stable_vector_detail::node_base<void*>** const&, unsigned long, boost::container::container_detail::insert_value_initialized_n_proxy<boost::container::allocator<boost::container::stable_vector_detail::node_base<void*>*, 2u, 0u>, boost::container::stable_vector_detail::node_base<void*>**>) 2 SUMMARY: MemorySanitizer: use-of-uninitialized-value /home/ben/development/boost/test/build/boost_root/status/../boost/container/vector.hpp:2604:11 in void boost::container::vector<MyInt, boost::container::allocator<MyInt, 2u, 6u> >::priv_push_back<MyInt>(MyInt&&) 2 SUMMARY: MemorySanitizer: use-of-uninitialized-value /build/buildd/glibc-2.21/misc/tsearch.c:320 in tfind 2 SUMMARY: AddressSanitizer: stack-buffer-overflow /home/ben/development/boost/test/build/boost_root/status/../libs/spirit/classic/test/traverse_tests.cpp:379:44 in void post_order_trace_test<boost::spirit::classic::sequence<boost::spirit::classic::chlit<char>, boost::spirit::classic::chlit<char> > >(boost::spirit::classic::sequence<boost::spirit::classic::chlit<char>, boost::spirit::classic::chlit<char> > const&, char const**, unsigned long) 2 SUMMARY: AddressSanitizer: stack-buffer-overflow /home/ben/development/boost/test/build/boost_root/status/../libs/local_function/test/return_derivative_seq.cpp:17:9 in derivative(boost::function<int (int)>&, int)::boost_local_function_auxXfunctorX17X::operator()(int) 2 SUMMARY: AddressSanitizer: 576 byte(s) leaked in 12 allocation(s). 2 SUMMARY: AddressSanitizer: 288 byte(s) leaked in 6 allocation(s). 2 SUMMARY: AddressSanitizer: 16 byte(s) leaked in 1 allocation(s). 2 SUMMARY: AddressSanitizer: 14496 byte(s) leaked in 404 allocation(s). 2 SUMMARY: AddressSanitizer: 120 byte(s) leaked in 5 allocation(s). 1 SUMMARY: ThreadSanitizer: data race /usr/local/bin/../include/c++/v1/ios:488:22 in std::__1::ios_base::precision(long) 1 SUMMARY: ThreadSanitizer: data race /usr/local/bin/../include/c++/v1/ios:444:20 in std::__1::ios_base::flags(unsigned int) 1 SUMMARY: ThreadSanitizer: data race /home/ben/development/boost/test/build/boost_root/status/../libs/thread/test/./util.inl:106:16 in (anonymous namespace)::execution_monitor::wait() 1 SUMMARY: ThreadSanitizer: data race /home/ben/development/boost/test/build/boost_root/status/../libs/thread/test/threads/thread/members/try_join_for_pass.cpp:55:12 in G::operator()() 1 SUMMARY: ThreadSanitizer: data race /home/ben/development/boost/test/build/boost_root/status/../libs/thread/test/threads/thread/members/try_join_for_pass.cpp:54:5 in G::operator()() 1 SUMMARY: ThreadSanitizer: data race /home/ben/development/boost/test/build/boost_root/status/../libs/thread/test/threads/thread/members/join_pass.cpp:56:12 in G::operator()() 1 SUMMARY: ThreadSanitizer: data race /home/ben/development/boost/test/build/boost_root/status/../libs/thread/test/threads/thread/members/join_pass.cpp:39:5 in G::G() 1 SUMMARY: ThreadSanitizer: data race /home/ben/development/boost/test/build/boost_root/status/../libs/spirit/classic/test/owi_mt_tests.cpp:93:23 in test_task<boost::spirit::classic::impl::object_with_id<tag1, unsigned long> >::increase_test_size(unsigned long) 1 SUMMARY: ThreadSanitizer: data race /home/ben/development/boost/test/build/boost_root/status/../libs/log/test/run/util_once_block.cpp:64:25 in once_block_flag_thread(boost::barrier&) 1 SUMMARY: ThreadSanitizer: data race /home/ben/development/boost/test/build/boost_root/status/../libs/log/test/run/util_once_block.cpp:112:25 in once_block_thread(boost::barrier&) 1 SUMMARY: ThreadSanitizer: data race /home/ben/development/boost/test/build/boost_root/status/../libs/interprocess/test/condition_test_template.hpp:83:17 in void boost::interprocess::test::condition_test_thread<boost::interprocess::interprocess_condition_any, boost::interprocess::ipcdetail::spin_mutex>(boost::interprocess::test::condition_test_data<boost::interprocess::interprocess_condition_any, boost::interprocess::ipcdetail::spin_mutex>*) 1 SUMMARY: ThreadSanitizer: data race /home/ben/development/boost/test/build/boost_root/status/../libs/interprocess/test/condition_test_template.hpp:321:15 in void boost::interprocess::test::do_test_condition_queue_notify_one<boost::interprocess::interprocess_condition_any, boost::interprocess::ipcdetail::spin_mutex>() 1 SUMMARY: ThreadSanitizer: data race /home/ben/development/boost/test/build/boost_root/status/../libs/interprocess/test/condition_test_template.hpp:282:10 in boost::interprocess::test::condition_func<boost::interprocess::interprocess_condition_any, boost::interprocess::ipcdetail::spin_mutex>::operator()() 1 SUMMARY: ThreadSanitizer: data race /home/ben/development/boost/test/build/boost_root/status/../libs/interprocess/test/condition_test_template.hpp:277:10 in boost::interprocess::test::condition_func<boost::interprocess::interprocess_condition_any, boost::interprocess::ipcdetail::spin_mutex>::operator()() 1 SUMMARY: ThreadSanitizer: data race /home/ben/development/boost/test/build/boost_root/status/../libs/atomic/test/ordering.cpp:200:40 in total_store_order_test<(boost::memory_order)0, (boost::memory_order)0>::thread2fn() 1 SUMMARY: ThreadSanitizer: data race /home/ben/development/boost/test/build/boost_root/status/../libs/atomic/test/atomicity.cpp:131:28 in racy_add(unsigned int volatile&, unsigned long) 1 SUMMARY: ThreadSanitizer: data race /home/ben/development/boost/test/build/boost_root/status/../boost/thread/pthread/mutex.hpp:62:17 in boost::posix::pthread_mutex_lock(pthread_mutex_t*) 1 SUMMARY: ThreadSanitizer: data race /home/ben/development/boost/test/build/boost_root/status/../boost/thread/future.hpp:2481:88 in boost::promise<void>::promise(boost::promise<void>&&) 1 SUMMARY: ThreadSanitizer: data race /home/ben/development/boost/test/build/boost_root/status/../boost/thread/detail/invoke.hpp:134:14 in _ZN5boost6detail6invokeIPFvvEJEEEDTclclsr5boostE7forwardIT_Efp_Espclsr5boostE7forwardIT0_Efp0_EEEOS4_DpOS5_ 1 SUMMARY: ThreadSanitizer: data race /home/ben/development/boost/test/build/boost_root/status/../boost/smart_ptr/shared_ptr.hpp:663:16 in boost::shared_ptr<boost::detail::shared_state<void> >::get() const 1 SUMMARY: MemorySanitizer: use-of-uninitialized-value /usr/local/bin/../include/c++/v1/bitset:757:46 in std::__1::bitset<8ul>::bitset<char, std::__1::char_traits<char>, std::__1::allocator<char> >(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >::size_type, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >::size_type, char, char) 1 SUMMARY: MemorySanitizer: use-of-uninitialized-value /usr/local/bin/../include/c++/v1/algorithm:1193:13 in bool std::__1::equal<boost::archive::iterators::mb_from_wchar<wchar_t const*>, char const*, std::__1::__equal_to<wchar_t, char> >(boost::archive::iterators::mb_from_wchar<wchar_t const*>, boost::archive::iterators::mb_from_wchar<wchar_t const*>, char const*, std::__1::__equal_to<wchar_t, char>) 1 SUMMARY: MemorySanitizer: use-of-uninitialized-value (/home/ben/development/boost/test/build/results/boost/bin.v2/libs/multiprecision/test/test_rational_io_mpz.test/clang-linux-3.7~msan~c14_libc++/release/test_rational_io_mpz+0x76708) in boost::multiprecision::number<boost::multiprecision::backends::gmp_rational, (boost::multiprecision::expression_template_option)1> generate_random<boost::multiprecision::number<boost::multiprecision::backends::gmp_rational, (boost::multiprecision::expression_template_option)1> >() 1 SUMMARY: MemorySanitizer: use-of-uninitialized-value (/home/ben/development/boost/test/build/results/boost/bin.v2/libs/multiprecision/test/test_miller_rabin.test/clang-linux-3.7~msan~c14_libc++/release/test_miller_rabin+0x75bbf) in void test<boost::multiprecision::number<boost::multiprecision::backends::gmp_int, (boost::multiprecision::expression_template_option)1> >() 1 SUMMARY: MemorySanitizer: use-of-uninitialized-value (/home/ben/development/boost/test/build/results/boost/bin.v2/libs/multiprecision/test/test_int_io_mpz.test/clang-linux-3.7~msan~c14_libc++/release/test_int_io_mpz+0x7ca20) in boost::multiprecision::number<boost::multiprecision::backends::gmp_int, (boost::multiprecision::expression_template_option)1> generate_random<boost::multiprecision::number<boost::multiprecision::backends::gmp_int, (boost::multiprecision::expression_template_option)1> >() 1 SUMMARY: MemorySanitizer: use-of-uninitialized-value (/home/ben/development/boost/test/build/results/boost/bin.v2/libs/multiprecision/test/test_generic_conv.test/clang-linux-3.7~msan~c14_libc++/release/test_generic_conv+0x99138) in void boost::multiprecision::detail::generic_interconvert<boost::multiprecision::backends::gmp_int, boost::multiprecision::backends::cpp_int_backend<0u, 0u, (boost::multiprecision::cpp_integer_type)1, (boost::multiprecision::cpp_int_check_type)0, std::__1::allocator<unsigned long long> > >(boost::multiprecision::backends::gmp_int&, boost::multiprecision::backends::cpp_int_backend<0u, 0u, (boost::multiprecision::cpp_integer_type)1, (boost::multiprecision::cpp_int_check_type)0, std::__1::allocator<unsigned long long> > const&, mpl_::int_<0> const&, mpl_::int_<0> const&) 1 SUMMARY: MemorySanitizer: use-of-uninitialized-value (/home/ben/development/boost/test/build/results/boost/bin.v2/libs/multiprecision/test/test_float_io_mpf.test/clang-linux-3.7~msan~c14_libc++/release/test_float_io_mpf+0x916e9) in void test<boost::multiprecision::number<boost::multiprecision::backends::gmp_float<50u>, (boost::multiprecision::expression_template_option)1> >() 1 SUMMARY: MemorySanitizer: use-of-uninitialized-value (/home/ben/development/boost/test/build/results/boost/bin.v2/libs/multiprecision/test/test_cpp_int_3.test/clang-linux-3.7~msan~c14_libc++/release/test_cpp_int_3+0x89656) in boost::multiprecision::number<boost::multiprecision::backends::gmp_int, (boost::multiprecision::expression_template_option)1> generate_random<boost::multiprecision::number<boost::multiprecision::backends::gmp_int, (boost::multiprecision::expression_template_option)1> >(unsigned int) 1 SUMMARY: MemorySanitizer: use-of-uninitialized-value (/home/ben/development/boost/test/build/results/boost/bin.v2/libs/multiprecision/test/test_cpp_int_2.test/clang-linux-3.7~msan~c14_libc++/release/test_cpp_int_2+0x89246) in boost::multiprecision::number<boost::multiprecision::backends::gmp_int, (boost::multiprecision::expression_template_option)1> generate_random<boost::multiprecision::number<boost::multiprecision::backends::gmp_int, (boost::multiprecision::expression_template_option)1> >(unsigned int) 1 SUMMARY: MemorySanitizer: use-of-uninitialized-value (/home/ben/development/boost/test/build/results/boost/bin.v2/libs/multiprecision/test/test_cpp_int_1.test/clang-linux-3.7~msan~c14_libc++/release/test_cpp_int_1+0x95d16) in boost::multiprecision::number<boost::multiprecision::backends::gmp_int, (boost::multiprecision::expression_template_option)1> generate_random<boost::multiprecision::number<boost::multiprecision::backends::gmp_int, (boost::multiprecision::expression_template_option)1> >(unsigned int) 1 SUMMARY: MemorySanitizer: use-of-uninitialized-value /home/ben/development/boost/test/build/boost_root/status/../libs/serialization/src/basic_xml_grammar.ipp:200:5 in boost::archive::basic_xml_grammar<char>::my_parse(std::__1::basic_istream<char, std::__1::char_traits<char> >&, boost::spirit::classic::rule<boost::spirit::classic::scanner<std::__1::__wrap_iter<char*>, boost::spirit::classic::scanner_policies<boost::spirit::classic::iteration_policy, boost::spirit::classic::match_policy, boost::spirit::classic::action_policy> >, boost::spirit::classic::nil_t, boost::spirit::classic::nil_t> const&, char) const 1 SUMMARY: MemorySanitizer: use-of-uninitialized-value /home/ben/development/boost/test/build/boost_root/status/../libs/graph/test/typestr.hpp:33:29 in std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > typestr<boost::undirected_graph<VertexBundle, EdgeBundle, GraphBundle> >() 1 SUMMARY: MemorySanitizer: use-of-uninitialized-value /home/ben/development/boost/test/build/boost_root/status/../libs/container/test/alloc_full_test.cpp:126:10 in boost::container::test::test_allocation_shrink() 1 SUMMARY: MemorySanitizer: use-of-uninitialized-value /home/ben/development/boost/test/build/boost_root/status/../libs/container/test/alloc_basic_test.cpp:24:7 in basic_test() 1 SUMMARY: MemorySanitizer: use-of-uninitialized-value /home/ben/development/boost/test/build/boost_root/status/../libs/container/bench/bench_alloc.cpp:63:13 in void allocation_timing_test<char_holder<8u> >(unsigned int, unsigned int) 1 SUMMARY: MemorySanitizer: use-of-uninitialized-value /home/ben/development/boost/test/build/boost_root/status/../libs/config/test/limits_test.cpp:97:8 in void print_hex_val<long double>(long double, char const*) 1 SUMMARY: MemorySanitizer: use-of-uninitialized-value /home/ben/development/boost/test/build/boost_root/status/../boost/test/impl/test_tools.ipp:298:9 in boost::test_tools::tt_detail::report_assertion(boost::test_tools::assertion_result const&, boost::unit_test::lazy_ostream const&, boost::unit_test::basic_cstring<char const>, unsigned long, boost::test_tools::tt_detail::tool_level, boost::test_tools::tt_detail::check_type, unsigned long, ...) 1 SUMMARY: MemorySanitizer: use-of-uninitialized-value /home/ben/development/boost/test/build/boost_root/status/../boost/spirit/home/qi/numeric/detail/real_impl.hpp:295:22 in bool boost::spirit::qi::detail::real_impl<double, boost::spirit::qi::ureal_policies<double> >::parse<char const*, double>(char const*&, char const* const&, double&, boost::spirit::qi::ureal_policies<double> const&) 1 SUMMARY: MemorySanitizer: use-of-uninitialized-value /home/ben/development/boost/test/build/boost_root/status/../boost/spirit/home/qi/numeric/detail/real_impl.hpp:295:22 in bool boost::spirit::qi::detail::real_impl<double, boost::spirit::qi::strict_real_policies<double> >::parse<char const*, double>(char const*&, char const* const&, double&, boost::spirit::qi::strict_real_policies<double> const&) 1 SUMMARY: MemorySanitizer: use-of-uninitialized-value /home/ben/development/boost/test/build/boost_root/status/../boost/spirit/home/qi/numeric/detail/real_impl.hpp:295:22 in bool boost::spirit::qi::detail::real_impl<double, boost::spirit::qi::real_policies<double> >::parse<std::__1::__wrap_iter<char*>, double>(std::__1::__wrap_iter<char*>&, std::__1::__wrap_iter<char*> const&, double&, boost::spirit::qi::real_policies<double> const&) 1 SUMMARY: MemorySanitizer: use-of-uninitialized-value /home/ben/development/boost/test/build/boost_root/status/../boost/numeric/odeint/stepper/bulirsch_stoer.hpp:202:13 in boost::numeric::odeint::controlled_step_result boost::numeric::odeint::bulirsch_stoer<boost::array<double, 3ul>, double, boost::array<double, 3ul>, double, boost::numeric::odeint::array_algebra, boost::numeric::odeint::default_operations, boost::numeric::odeint::initially_resizer>::try_step<lorenz, boost::array<double, 3ul>, boost::array<double, 3ul>, boost::array<double, 3ul> >(lorenz, boost::array<double, 3ul> const&, boost::array<double, 3ul> const&, double&, boost::array<double, 3ul>&, double&) 1 SUMMARY: MemorySanitizer: use-of-uninitialized-value /home/ben/development/boost/test/build/boost_root/status/../boost/numeric/odeint/iterator/impl/adaptive_iterator_impl.hpp:105:17 in boost::numeric::odeint::adaptive_iterator_impl<boost::numeric::odeint::adaptive_iterator<boost::numeric::odeint::dummy_controlled_stepper, empty_system, boost::array<double, 1ul>, boost::numeric::odeint::controlled_stepper_tag>, boost::numeric::odeint::dummy_controlled_stepper, empty_system, boost::array<double, 1ul>, boost::numeric::odeint::detail::ode_state_iterator_tag, boost::numeric::odeint::controlled_stepper_tag>::increment() 1 SUMMARY: MemorySanitizer: use-of-uninitialized-value /home/ben/development/boost/test/build/boost_root/status/../boost/multiprecision/gmp.hpp:368:7 in boost::multiprecision::backends::detail::gmp_float_imp<0u>::data() const 1 SUMMARY: MemorySanitizer: use-of-uninitialized-value /home/ben/development/boost/test/build/boost_root/status/../boost/multiprecision/gmp.hpp:331:10 in boost::multiprecision::backends::detail::gmp_float_imp<25u>::~gmp_float_imp() 1 SUMMARY: MemorySanitizer: use-of-uninitialized-value /home/ben/development/boost/test/build/boost_root/status/../boost/multiprecision/gmp.hpp:331:10 in boost::multiprecision::backends::detail::gmp_float_imp<100u>::~gmp_float_imp() 1 SUMMARY: MemorySanitizer: use-of-uninitialized-value /home/ben/development/boost/test/build/boost_root/status/../boost/multiprecision/gmp.hpp:234:7 in boost::multiprecision::backends::detail::gmp_float_imp<0u>::str(long, unsigned int) const 1 SUMMARY: MemorySanitizer: use-of-uninitialized-value /home/ben/development/boost/test/build/boost_root/status/../boost/multiprecision/gmp.hpp:1932:7 in boost::multiprecision::backends::gmp_rational::str(long, unsigned int) const 1 SUMMARY: MemorySanitizer: use-of-uninitialized-value /home/ben/development/boost/test/build/boost_root/status/../boost/multiprecision/gmp.hpp:1827:10 in boost::multiprecision::backends::gmp_rational::operator=(unsigned long) 1 SUMMARY: MemorySanitizer: use-of-uninitialized-value /home/ben/development/boost/test/build/boost_root/status/../boost/multiprecision/gmp.hpp:152:10 in boost::multiprecision::backends::detail::gmp_float_imp<50u>::operator=(unsigned long) 1 SUMMARY: MemorySanitizer: use-of-uninitialized-value /home/ben/development/boost/test/build/boost_root/status/../boost/multiprecision/gmp.hpp:152:10 in boost::multiprecision::backends::detail::gmp_float_imp<2000u>::operator=(unsigned long) 1 SUMMARY: MemorySanitizer: use-of-uninitialized-value /home/ben/development/boost/test/build/boost_root/status/../boost/multiprecision/gmp.hpp:152:10 in boost::multiprecision::backends::detail::gmp_float_imp<0u>::operator=(unsigned long) 1 SUMMARY: MemorySanitizer: use-of-uninitialized-value /home/ben/development/boost/test/build/boost_root/status/../boost/multiprecision/gmp.hpp:1226:7 in boost::multiprecision::backends::gmp_int::str(long, unsigned int) const 1 SUMMARY: MemorySanitizer: use-of-uninitialized-value /home/ben/development/boost/test/build/boost_root/status/../boost/multiprecision/gmp.hpp:1100:10 in boost::multiprecision::backends::gmp_int::operator=(long) 1 SUMMARY: MemorySanitizer: use-of-uninitialized-value /home/ben/development/boost/test/build/boost_root/status/../boost/multiprecision/gmp.hpp:1093:10 in boost::multiprecision::backends::gmp_int::operator=(unsigned long) 1 SUMMARY: MemorySanitizer: use-of-uninitialized-value /home/ben/development/boost/test/build/boost_root/status/../boost/graph/boykov_kolmogorov_max_flow.hpp:471:22 in boost::detail::bk_max_flow<boost::adjacency_list<boost::vecS, boost::vecS, boost::directedS, Node<boost::detail::edge_desc_impl<boost::directed_tag, unsigned long> >, Link<boost::detail::edge_desc_impl<boost::directed_tag, unsigned long> >, boost::no_property, boost::listS>, boost::adj_list_edge_property_map<boost::directed_tag, long, long&, unsigned long, Link<boost::detail::edge_desc_impl<boost::directed_tag, unsigned long> >, long Link<boost::detail::edge_desc_impl<boost::directed_tag, unsigned long> >::*>, boost::adj_list_edge_property_map<boost::directed_tag, long, long&, unsigned long, Link<boost::detail::edge_desc_impl<boost::directed_tag, unsigned long> >, long Link<boost::detail::edge_desc_impl<boost::directed_tag, unsigned long> >::*>, boost::adj_list_edge_property_map<boost::directed_tag, boost::detail::edge_desc_impl<boost::directed_ 1 SUMMARY: MemorySanitizer: use-of-uninitialized-value /home/ben/development/boost/test/build/boost_root/status/../boost/gil/color_base_algorithm.hpp:237:60 in bool boost::gil::detail::element_recursion<2>::static_equal<boost::gil::bit_aligned_pixel_reference<unsigned char, boost::mpl::vector3_c<int, 1, 2, 1>, boost::gil::layout<boost::mpl::vector3<boost::gil::red_t, boost::gil::green_t, boost::gil::blue_t>, boost::mpl::vector3_c<int, 2, 1, 0> >, true>, boost::gil::bit_aligned_pixel_reference<unsigned char, boost::mpl::vector3_c<int, 1, 2, 1>, boost::gil::layout<boost::mpl::vector3<boost::gil::red_t, boost::gil::green_t, boost::gil::blue_t>, boost::mpl::range_c<int, 0, 3> >, true> >(boost::gil::bit_aligned_pixel_reference<unsigned char, boost::mpl::vector3_c<int, 1, 2, 1>, boost::gil::layout<boost::mpl::vector3<boost::gil::red_t, boost::gil::green_t, boost::gil::blue_t>, boost::mpl::vector3_c<int, 2, 1, 0> >, true> const&, boost::gil::bit_aligned_pixel_reference<unsigned char, boost::mpl::vector3_c<int, 1, 2, 1 SUMMARY: MemorySanitizer: use-of-uninitialized-value /home/ben/development/boost/test/build/boost_root/status/../boost/context/execution_context.hpp:115:17 in boost::context::execution_context::activation_record::resume(bool) 1 SUMMARY: MemorySanitizer: use-of-uninitialized-value /home/ben/development/boost/test/build/boost_root/status/../boost/container/vector.hpp:457:10 in boost::container::container_detail::vector_alloc_holder<boost::container::allocator<int, 2u, 0u>, boost::move_detail::integral_constant<unsigned int, 2u> >::~vector_alloc_holder() 1 SUMMARY: MemorySanitizer: use-of-uninitialized-value /home/ben/development/boost/test/build/boost_root/status/../boost/container/vector.hpp:2774:7 in boost::container::container_detail::vec_iterator<int*, false> boost::container::vector<int, boost::container::allocator<int, 2u, 0u> >::priv_forward_range_insert<boost::container::container_detail::insert_move_proxy<boost::container::allocator<int, 2u, 0u>, int*> >(int* const&, unsigned long, boost::container::container_detail::insert_move_proxy<boost::container::allocator<int, 2u, 0u>, int*>) 1 SUMMARY: MemorySanitizer: use-of-uninitialized-value /home/ben/development/boost/test/build/boost_root/status/../boost/container/vector.hpp:2774:7 in boost::container::container_detail::vec_iterator<boost::container::container_detail::pair<int, int>*, false> boost::container::vector<boost::container::container_detail::pair<int, int>, boost::container::allocator<boost::container::container_detail::pair<int, int>, 2u, 0u> >::priv_forward_range_insert<boost::container::container_detail::insert_move_proxy<boost::container::allocator<boost::container::container_detail::pair<int, int>, 2u, 0u>, boost::container::container_detail::pair<int, int>*> >(boost::container::container_detail::pair<int, int>* const&, unsigned long, boost::container::container_detail::insert_move_proxy<boost::container::allocator<boost::container::container_detail::pair<int, int>, 2u, 0u>, boost::container::container_detail::pair<int, int>*>) 1 SUMMARY: MemorySanitizer: use-of-uninitialized-value /home/ben/development/boost/test/build/boost_root/status/../boost/container/vector.hpp:2675:10 in boost::container::vector<MyInt, boost::container::allocator<MyInt, 2u, 0u> >::priv_shrink_to_fit(boost::move_detail::integral_constant<unsigned int, 2u>) 1 SUMMARY: MemorySanitizer: use-of-uninitialized-value /home/ben/development/boost/test/build/boost_root/status/../boost/container/vector.hpp:2604:11 in void boost::container::vector<int, boost::container::allocator<int, 2u, 0u> >::priv_push_back<int>(int&&) 1 SUMMARY: AddressSanitizer: stack-buffer-overflow /home/ben/development/boost/test/build/boost_root/status/../libs/local_function/test/return_derivative.cpp:22:9 in derivative(boost::function<int (int)>&, int)::boost_local_function_auxXfunctorX22X::operator()(int) 1 SUMMARY: AddressSanitizer: stack-buffer-overflow /home/ben/development/boost/test/build/boost_root/status/../boost/intrusive/detail/size_holder.hpp:35:14 in boost::intrusive::detail::size_holder<true, unsigned long, void>::get_size() const 1 SUMMARY: AddressSanitizer: global-buffer-overflow /home/ben/development/boost/test/build/boost_root/status/../boost/numeric/odeint/iterator/impl/times_iterator_impl.hpp:86:42 in boost::numeric::odeint::times_iterator_impl<boost::numeric::odeint::times_time_iterator<boost::numeric::odeint::dummy_stepper, empty_system, boost::array<double, 1ul>, double*, boost::numeric::odeint::stepper_tag>, boost::numeric::odeint::dummy_stepper, empty_system, boost::array<double, 1ul>, double*, boost::numeric::odeint::detail::ode_state_time_iterator_tag, boost::numeric::odeint::stepper_tag>::times_iterator_impl(boost::numeric::odeint::dummy_stepper, empty_system, boost::array<double, 1ul>&, double*, double*, double) 1 SUMMARY: AddressSanitizer: global-buffer-overflow /home/ben/development/boost/test/build/boost_root/status/../boost/numeric/odeint/iterator/impl/times_iterator_impl.hpp:86:42 in boost::numeric::odeint::times_iterator_impl<boost::numeric::odeint::times_iterator<boost::numeric::odeint::dummy_stepper, empty_system, boost::array<double, 1ul>, double*, boost::numeric::odeint::stepper_tag>, boost::numeric::odeint::dummy_stepper, empty_system, boost::array<double, 1ul>, double*, boost::numeric::odeint::detail::ode_state_iterator_tag, boost::numeric::odeint::stepper_tag>::times_iterator_impl(boost::numeric::odeint::dummy_stepper, empty_system, boost::array<double, 1ul>&, double*, double*, double) 1 SUMMARY: AddressSanitizer: container-overflow /usr/local/bin/../include/c++/v1/string:1664:39 in std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >::__is_long() const 1 SUMMARY: AddressSanitizer: container-overflow /home/ben/development/llvm/trunk/llvm/projects/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors.inc:188:3 in __interceptor_strcmp 1 SUMMARY: AddressSanitizer: 96 byte(s) leaked in 6 allocation(s). 1 SUMMARY: AddressSanitizer: 8 byte(s) leaked in 1 allocation(s). 1 SUMMARY: AddressSanitizer: 816 byte(s) leaked in 1 allocation(s). 1 SUMMARY: AddressSanitizer: 797943 byte(s) leaked in 357 allocation(s). 1 SUMMARY: AddressSanitizer: 796079 byte(s) leaked in 351 allocation(s). 1 SUMMARY: AddressSanitizer: 72000000 byte(s) leaked in 3000000 allocation(s). 1 SUMMARY: AddressSanitizer: 65536 byte(s) leaked in 1 allocation(s). 1 SUMMARY: AddressSanitizer: 56 byte(s) leaked in 4 allocation(s). 1 SUMMARY: AddressSanitizer: 324 byte(s) leaked in 3 allocation(s). 1 SUMMARY: AddressSanitizer: 24 byte(s) leaked in 2 allocation(s). 1 SUMMARY: AddressSanitizer: 20 byte(s) leaked in 2 allocation(s). 1 SUMMARY: AddressSanitizer: 1984 byte(s) leaked in 11 allocation(s). 1 SUMMARY: AddressSanitizer: 171 byte(s) leaked in 9 allocation(s). 1 SUMMARY: AddressSanitizer: 14256 byte(s) leaked in 99 allocation(s). 1 SUMMARY: AddressSanitizer: 12345 byte(s) leaked in 1 allocation(s). 1 SUMMARY: AddressSanitizer: 114688 byte(s) leaked in 7 allocation(s). 1 SUMMARY: AddressSanitizer: 104 byte(s) leaked in 2 allocation(s). I'm happy to expand on any line that is less than useful. For the sake of sanity, I think I will also add this to the command line -Wno-unused-local-typedef, as the log contains 462603 matches, often times the warnings push more interesting things off beyond the 64Kb limit. Ben

6 12

Re: [boost] Multiple-pattern string search algorithms
by meghana madhyastha 12 May '15

12 May '15

Hi, The Rabin Karp algorithm performs better than KMP and Boyer Moore during multiple pattern searching. The interface that I have suggested is given below. Please let me know your opinions and if there is a better approach than the one I am suggesting. Any feedback/criticism/guidance will be appreciated and helpful. An overview of the Rabin Karp Algorithm: The Rabin Karp algorithm assigns hash values to the text. The pattern is made to 'slide' along the text to be searched. The hash value of the text is computed and is compared to the hash value of the pattern. A brute force search of each element in the pattern with the current window of text is performed if and only if the hash value of the text matches the hash value of the pattern (and this hash value can be calculated in O(1) time). There can be two interfaces that can be implemented for this a procedural and an object oriented interface (similar to the interfaces for the Boyer Moore Algorithm). There should be two iterator types. One to iterate through the text called 'textIter' and another to iterate through the set of patterns (multiple patterns can be stored as part of a set) called 'setIter'. In the object oriented interface, the hash value of the pattern can be precomputed in the constructor. The text can be searched to match the pattern using the () operator (similar to the implementation of Boyer Moore). In the procedural interface, the search as well as hash computation of the pattern string all happens in the single function 'rabin_karp_search'. template <typename patIter> class rabin_karp { public: rabin_karp ( patIter first, patIter last ); ~rabin_karp (); template <typename textIter> template <typename setIter> textIter operator () ( textIter text_first, textIter text_last, setIter set_first, setIter set_last); }; template <typename patIter, typename textIter> textIter rabin_karp_search ( textIter text_first, textIter text_last, setIter set_first, setIter set_last ); Thanks and Regards, Meghana

1 0

[website] online docs not available?
by Andrzej Krzemienski 12 May '15

12 May '15

Hi Everyone, It looks that the online documentation is not available. the link http://www.boost.org/doc/libs/1_58_0/ displays a blank page. Can you see the docs? Regards, &rzej

3 2

[regression][testing][config] Regression results not displayed.
by Adam Wulkiewicz 11 May '15

11 May '15

Hi, Since 2015/04/26 the tests started to dissapear from Geometry summary pages for develop branch. And now the pages aren't even displayed properly, I see only: Error extracting file: No matching files were found. for: http://www.boost.org/development/tests/develop/developer/geometry.html http://www.boost.org/development/tests/develop/developer/geometry-extension… and on: http://www.boost.org/development/tests/develop/developer/geometry-index.html there are only 2 tests. Furthermore "geometry" and "geometry-extensions" can't be found in the menu. I can see the results for Geometry in the paskages sent to the server. I can also see them in the sanitizer reports sent by Ben. So I'm guessing that the error must be on a later stage of processing, probably in the Regression. Just before the time I saw the issue the first time I added new tests to "geometry-extensions", though it seems wierd that it could affect "geometry" and "geometry-index": https://github.com/boostorg/geometry/commit/9bc8baaa3b3fffc96fbb0abd10a8cb0… https://github.com/boostorg/geometry/commit/07c8b24b89e9fec75c6b7efc7e94032… Geometry is probably the library with the most complex tests structure. We use nested directories and build-project directive in Jamfiles. May this be a part of the problem? AFAIR at that time there were also some changes in the Regression, and the last time something like this happened Config was changed. Could some changes in those modules cause the issue I'm writing about? What may be the reason of such behavior and most importantly do you know how to fix it? Regards, Adam

2 6

What variants should be build on Windows by default?
by Olaf van der Spek 11 May '15

11 May '15

Hi, What library variants should be build on Windows by default? Currently it builds: --build-type=<type> Build the specified pre-defined set of variations of the libraries. Note, that which variants get built depends on what each library supports. -- minimal -- (default) Builds a minimal set of variants. On Windows, these are static multithreaded libraries in debug and release modes, using shared runtime. On Linux, these are static and shared multithreaded libraries in release mode. Personally I use a static-release runtime often (for simple deployments). What variants do others use and what should be build by default? Greetings, -- Olaf

4 3

[array] Support for multidimensional arrays?
by Peter Dimov 10 May '15

10 May '15

Currently, creating a multidimensional boost/std::array is a bit unwieldy: array<array<array<int, 5>, 4>, 3> a; // int a[3][4][5] a[2][3][4] = 5; As a first step, we should consider enabling the element type T of array<T, N> to be an array type. array<int[4][5], 3> a; // int a[3][4][5] a[2][3][4] = 5; This almost works already, except for the array interface functions specified and implemented in terms of, say, std::equal or std::fill. It is an open question whether these standard algorithms should not be fixed themselves to work on array types, as swap_ranges has been, but for now, we can implement the array functions in a way that works. Opinions on that part? If we agree that this is a good idea, the next logical step would be to eliminate the special handling of the first extent and simply allow array<int[3][4][5]> a; // int a[3][4][5] a[2][3][4] = 5;

4 4

[boost.org website] Incorrect links on Boost website
by Michael Levine 10 May '15

10 May '15

I was browsing through the Boost website this morning and the links on the right sidebar caught my attention. It appears that there is a duplicate entry for "coding guidelines for constant integral expressions", under Development / Requirements and Guidelines. The first of these links points to the correct page. The second links to a page regarding library metadata. I'm not sure who, exactly, to contact for this, so I figured this list would be the most appropriate means to have this addressed. Best regards, Shmuel

2 1

[algorithm] Removal of preference to std implementation
by Rob Conde 10 May '15

10 May '15

Marshall/Others-in-the-know, In boost algorithm change set 4dac507b773cf4a82727703ddffa2b36c42ab814, the code which uses std version of algorithms when available was removed. I'm curious about the motivation for this change. I can guess at a few potential reasons, but I figure you can just share the real reason. This change potentially explains a performance regression in my code so I'm just trying to understand the motivation before I make any code changes. Thanks! Rob Conde

1 0

[testing] Add a tester with hidden visibility
by Andrey Semashev 09 May '15

09 May '15

Hi, Is it possible to add a tester that enables hidden visibility (- fvisibility=hidden -fvisibility-inlines-hidden) when building and testing Boost? I believe, a single tester on Linux+GCC would be enough to discover most issues related to symbol visibility. The reason I'm asking is that I believe Boost should support building with hidden visibility by default. This mode allows more optimizations and does not export unintended symbols from libraries. I've set hidden visibility for Boost.Log (in develop) and, as I understand, Robert is doing a similar change in Boost.Serialization. However, when building 1.58 with hidden visibility for my project I found out that not all libraries work well with that setting. What do you think about it?

4 20

Re: [boost] Windows XP support survey
by Thomas Trummer 07 May '15

07 May '15

The sad reality in a lot of industries is that we still have to support Windows XP for the foreseeable future. Though, I understand the desire to drop support for it. Believe me, everyone would be more than happy to just require Windows 7 as default and be done with it. However, it is hard to convince costumers to make the switch when there is only risk and no tangible benefit attached to it. In addition to this we do have the problem that we control complex (and expensive) hardware that consists of components that don’t have drivers for Windows 7 because the manufacturer discontinued them. For these people the end of support from Microsoft isn’t really an argument since the computers are not connected to the Internet and continue to work fine, not to mention that you can still buy extended support from Microsoft. The huge outcry from the C++ community when Microsoft wanted to drop support for XP in Visual Studio should be a clear indicator that a lot of people livelihoods still depend on it. Unfortunately since then the install base hasn’t really shrunken too much. So even Visual C++ 2015 will continue to support it. So, as long as a Visual C++ version supported by Boost can build for Windows XP and there isn’t a significant cost attached to it, Boost should also continue to support Windows XP.

3 2

Re: [boost] Windows XP support survey
by Andrzej Horoszczak - Billon 07 May '15

07 May '15

1 0

Re: [boost] Interest in a container which can hold multiple data types?
by James Armstrong 07 May '15

07 May '15

Sorry about the README file, I pretty much just uploaded what I had to github so people can grab the source. Admittedly, things there are lacking. I'll work on filling out the readme with some instructions hopefully today. The main difference between this and a container of boost:any is that the container of boost::any still is a container of one data type, just being that one data type is a very flexible one. This container natively supports insertion of different data types. So, you could do, int my_int = 5; double my_double0 = 9342.132; double my_double1 = 987.654; std::string my_string("This is a string."); std::vector<double> my_vec; my_vector.push_back(123.456); omni my_container; my_container.push_back(my_int); my_container.push_back(my_double); my_container.push_back(my_string); my_container.push_back(my_vector); and the container happily stores the data. You can then access the data through iterators //access all doubles for (auto itr = my_container.begin<double>(); itr != my_containert.end<double>(); ++itr) { std::cout << *itr << std::endl; } or through specifying the data type and index //get the 0th element string std::cout << my_container.at<string>(0) << std::endl; -- James Armstrong

9 27

[lambda] Addressing pull requests
by Edward Diener 07 May '15

07 May '15

The maintainer for lambda in the libs/maintainer.txt list is Jaako Jarvi, who is the original author. But I see others who have made changes to the library. So I am wondering if anyone is still actively maintaining the library. There are a number of pull requests for lambda, related to updating the code for type_traits Version2, by John Maddock and myself. Is someone handling these ?

5 6

Arguing about names in Boost libraries
by Edward Diener 06 May '15

06 May '15

What is wrong with the people commenting on libraries for Boost who are so concerned about the names being used ? We are talking only about C++ identifiers and yet there are now endless discussions where people disagree on names or argue that some name is not what they want or that they like some other name, with a list of names that they find adequate. This is irrelevant. There is something mentally wrong about all those peoples spending endless amounts of time around this issue. I notice this does not happen nowadays for just one library but for ever single library, or proposed library, which is mentioned on this mailing list. Is this the way all of you people actually work in your daily jobs, or on your own projects, spending hours and days arguing with others about C++ identifiers for every little thing ? Are you not aware of the absurdity of your endless remarks ? Grow up ! Surely there are better things to do than carry on endlessly about some name, that is should be x or y or z or some other inane preferable list. It's time for somebody to say this, so I will do it. A C++ identifier name, as long as it is vaguely about what the functionality entails, is perfectly adequate. It does not have to satisfy everyone in the universe. Period !

9 10

C++11 compilers and fenv
by Damian Vicino 06 May '15

06 May '15

Hi, I’m implementing the safe_float library (on c++11) proposed for the GSOC . I was planning to access FENV for detecting unsafe operations on the native floating point types and include some custom pre-post conditions for testing other floating types safety conditions. Conditions come from policies passed as template parameter to give users the possibility of chose their own set of safety conditions to be enforced. An example of the conditions that can be asked is enforcing overflows to infinite does not happen. An overflow to infinite can be detected by the FE overflow flag or because the addition of two finites numbers result in an infinite one. I just found today that clang++ does not support the pragma to use FENV yet. warning: pragma STDC FENV_ACCESS ON is not supported Googling a little I found out that neither does gcc. How are c++11 boost libraries dealing with these compiler issues? I got some options in mind: — Implement everything using custom detections, this will work in every compiler, but it will run slower for everyone too. — Finding a compiler with the support, implementing the library using the FENV, and assuming compilers will support it when the library is finished and reviewed. — Detect somehow the FENV pragma was not processed and have 2 implementations. No idea how to detect something like this. Had someone dealt with similar problem already? Is there a common approach? Best regards, Damian Vicino

4 5

[ boost ] [ Trie ]
by Cosmin Boaca 06 May '15

06 May '15

Hello, I am interested in working at the Boost.Trie project which was started during GSoC 2013 and I am searching for someone who can give me some advice about what should I change / add to the current implementation, because I'm not too experienced in developing library code. However, I do not want do this during GSoC because I won't be available during the summer. I want to contribute during my spare time. If anyone thinks that can help me with this, please reply to this email. Thank you, Cosmin

8 90

BenPope x86_64 Ubuntu issue at link time
by Vicente J. Botet Escriba 06 May '15

06 May '15

Hi, I'm getting this link error /usr/bin/ld: error: /home/ben/development/boost/test/build/results/boost/bin.v2/libs/thread/test/thread__constr__FArgs_p_lib.test/clang-linux-3.7~asan~c14_libc++/debug/threading-multi/threads/thread/constr/FArgs_pass.o: multiple definition of 'operator delete(void*)' /usr/bin/ld: /home/ben/development/llvm/trunk/install/release/bin/../lib/clang/3.7.0/lib/linux/libclang_rt.asan_cxx-x86_64.a(asan_new_delete.cc.o): previous definition here at http://www.boost.org/development/tests/develop/developer/output/BenPope%20x… I define it as follows #if defined _GLIBCXX_THROW void* operator new(std::size_t s) _GLIBCXX_THROW (std::bad_alloc) #elif defined BOOST_MSVC void* operator new(std::size_t s) #else void* operator new(std::size_t s) throw (std::bad_alloc) #endif { std::cout << __FILE__ << ":" << __LINE__ << std::endl; if (throw_one == 0) throw std::bad_alloc(); --throw_one; return std::malloc(s); } Is this a compiler issue, or is my definition of the operator new incorrect? Vicente

2 2

[move] unique_ptr converting constructor
by Peter Dimov 06 May '15

06 May '15

While looking at https://svn.boost.org/trac/boost/ticket/11259 I found that after implementing a converting shared_ptr constructor that takes a boost::movelib::unique_ptr, the straightforward code in the ticket still fails (with g++ in C++03 mode): namespace mystd { using boost::shared_ptr; using boost::make_shared; using boost::movelib::unique_ptr; using boost::movelib::make_unique; } mystd::unique_ptr<int> load_thing() { return mystd::make_unique<int>(1); } mystd::shared_ptr<int> get_thing() { return load_thing(); } So, out of curiosity, I looked at how unique_ptr itself implements its converting constructor. It turns out that it, too, doesn't work. mystd::unique_ptr<int const> get_thing_2() { return load_thing(); } Furthermore, the two possible ways to make the shared_ptr code work: mystd::shared_ptr<int> get_thing() { mystd::shared_ptr<int> r( load_thing() ); return r; } mystd::shared_ptr<int> get_thing() { mystd::unique_ptr<int> r( load_thing() ); return boost::move( r ); } fail for the unique_ptr<int const> case.

4 8

Re: [boost] Interest in a container which can hold multiple data types?
by Brian Wood 06 May '15

06 May '15

Joaquin M Lopez Munoz writes: > I wrote something on this some time ago, maybe worth having a look at: > > http://bannalia.blogspot.com/2014/05/fast-polymorphic-collections.html <http://bannalia.blogspot.com/2014/05/fast-polymorphic-collections.html> > http://bannalia.blogspot.com/2014/05/fast-polymorphic-collections-with.html <http://bannalia.blogspot.com/2014/05/fast-polymorphic-collections-with.html> I look forward to someone implementing these things. Any progress? -- Brian Ebenezer Enterprises - In G-d we trust. http://webEbenezer.net

2 1

Fwd: Boost.Python build error in 1.58 RC1, 2 and 3 (OK in Beta 1)
by Marshall Clow 06 May '15

06 May '15

---------- Forwarded message ---------- From: <mark.incley(a)synx.com> Date: Wed, Apr 8, 2015 at 1:29 AM Subject: Boost.Python build error in 1.58 RC1, 2 and 3 (OK in Beta 1) To: mclow.lists(a)gmail.com Hi Marshall, Please excuse the direct mail, but my mailing list posting wasn't picked up on by anyone. I believe I've found a problem in Boost.Python that causes build errors if the user has Python 3.0 or later on their system. This change appears to have been introduced after 1.58 Beta 1. Using: bjam address-model=32 runtime-link=shared toolset=msvc-12.0 --stagedir=./stage/x86 C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\INCLUDE\xtgmath.h(206) : warning C4273: 'round' : inconsistent dll linkage C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\INCLUDE\math.h(516) : see previous definition of 'round' libs\python\src\exec.cpp(91) : error C2664: 'FILE *_Py_fopen(PyObject *,const char *)' : cannot convert argument 1 from 'char *' to 'PyObject *' Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast call "C:\Users\MARK~1.INC\AppData\Local\Temp\b2_msvc_12.0_vcvarsall_x86.cmd" >nul cl /Zm800 -nologo @"bin.v2\libs\python\build\msvc-12.0\debug\link-static\threading-multi\exec.obj.rsp" ...failed compile-c-c++ bin.v2\libs\python\build\msvc-12.0\debug\link-static\threading-multi\exec.obj… The problem appears to be this Boost.Python code that was changed some time after 1.58 Beta 1 and appears in 1.58 RC1 within boost\libs\python\src\exec.cpp at around line 91: 1.58 beta 1: FILE *fs = fopen(f, "r"); 1.58 RCs: FILE *fs = _Py_fopen(f, "r"); ← f is a char *, hence the error shown above. It expects a PyObject * as the first parameter. This code occurs within a test for #if PY_VERSION_HEX >= 0x03000000 which may explain why no-one else has reported it – I have Python 3.3.0 on my HDD. Cheers, Mark. _____________________________________ Sent from http://boost.2283326.n4.nabble.com

13 31

Interest in a container which can hold multiple data types?
by James Armstrong 06 May '15

06 May '15

Hello forum, I was wanting to gauge interest in a container I developed which can natively handle multiple data types (as opposed to using a container of boost::any). I have the templated source hosted on my github account at https://github.com/armstrhu/omni There is some documentation on the current functions under omni/doc/html/index.html. main.cpp has some example codes on inserting, retrieving, and manipulating the data within the container. The one caveat to using the container is that the function destroy<T>() must be called for all data types inserted into the container, I currently have an assert in the destructor which will hit if destroy<T>() is not called for a data type. Also, this requires using a modified version of boost/core/typeinfo.hpp, so you will need to replace the original with the one I provide. The changes simply keep the boost functionality even when C++ typeinfo is available. I am trying to guage interest in this, and if there is interest, get some feedback on additional functionality to include. The iterators I have now work, but they are inefficient and that will be fixed eventually. Currently, I'm calling the container an omni, but don't really like that name and am looking for suggestions for something better :) Thanks -- James Armstrong

5 5

[Voronoi] Weighted Voronoi diagram
by Sybren A. Stüvel 06 May '15

06 May '15

Dear Boost mailing list, Currently I'm working on a Voronoi-based crowd simulation system. We model crowd agents as line segments, and feed them to the Boost Voronoi library. It would be very nice if we could give different line segments different weights. Does the Boost Voronoi library support different weights for its inputs? If not (which I'm afraid is the case, as it isn't mentioned in the documentation), how difficult would it be to add support for this? Kind regards, -- Sybren A. Stüvel http://stuvelfoto.nl/ http://stuvel.eu/

1 0

[threads] Unexpected behaviour of Thread loal storage
by Fu ji 06 May '15

06 May '15

Hello, I would like to ask if there is everything ok with my way of thinking. I have 3 solutions (projects) in MS Visual Studio. Let say: SolutionA (static lib) SolutionB (linked with Solution A) SolutionC (linked with Solution A) In Header file of solutionA I have delaration of TLS from boost static boost::thread_specific_ptr<int> TLS; And now in SolutionB I set tls (TLS.reset(uVariable)) - uVariable is integer 2 Call function from SolutionC and call TLS.get() but there is different value than 2. But when i return from function to SolutionB and call TLS.get there is everything ok (return 2). It's ok ? Why in solutionC there is no visibilty of value set in solutionB ? It's the same thread (with the same threadId). Best regards

2 18

[tuple] Changes living in develop
by Marcel Raad 06 May '15

06 May '15

Hi, there are three commits from last year in develop that haven't been merged to master yet. Could someone merge them please? 8bdf2a9 Make tuple constructor explicit 4fb2618 Add metadata file. b4f0590 Ported documentation to boostbook I always have to apply 8bdf2a9 manually to new Boost releases.

1 0

Re: [boost] [Boost-testing] Attempt to redeclare already registered project id '/check/predef'
by Tom Kent 06 May '15

06 May '15

On Tue, May 5, 2015 at 2:43 AM, Dmitry Moskalchuk <dm(a)crystax.net> wrote: > > Hello, > > Running tests of 'develop' branch, I've bumped with error today: > > error: at /home/cislave/.crystax/ci-boost/regression/android-19-x86-develop/test/develop/regression/x86/test/boost_bb/src/build/project.jam:1069 > error: Attempt to redeclare already registered project id '/check/predef'. > error: Original project: > error: Name: ../check/predef > error: Module: ../check/predef > error: Main id: /check/predef > error: File: ../check/predef.jam > error: Location: ../check/predef > error: New project: > error: Module: ../../predef/check/predef > error: File: ../../predef/check/predef.jam > error: Location: ../check/predef > > > It happens only when run regression tests for 'develop' branch ('master' > is OK). Is this known problem? > I'm getting the same error (which is stopping the regression run) on all my develop testers (windows and linux). Tom

2 1

[Master project] GitHub issues disabled
by Louis Dionne 06 May '15

06 May '15

Hi, The title pretty much says it all. Is there a reason for disabling GitHub issues on the master project? Also, I'd like to know when will the master project be tagged with the 1.58.0 release. Thanks, Louis

18 35

Re: [boost] Interest in a container which can hold multiple data types?
by James Armstrong 05 May '15

05 May '15

On 5/5/2015 7:49 PM, Joaquin M Lopez Munoz wrote: > TONGARI J <tongari95 <at> gmail.com> writes: > >> If the data sequence shows some affinity, I guess an ordered >> tuple_vector-based sequence can provide some performance benefit in >> traversal (with some crafted for_each method). >> >> That is, a sequence of [AAABBB] may be traversed faster than [ABABAB] for >> such a container, and I believe in the later case such that the types are >> uniformly distributed, vector<variant> will perform better. > I wrote something on this some time ago, maybe worth having a look at: > > http://bannalia.blogspot.com/2014/05/fast-polymorphic-collections.html > http://bannalia.blogspot.com/2014/05/fast-polymorphic-collections-with.html > Nice analysis. If we can identify different use cases, we may be able to come up with several implementations of heterogeneous containers which balance efficiency and flexibility. I think it would be an interesting project to work on and surely useful if the containers all the a similar 'feel' -- James Armstrong

1 0

[filesystem] copy_file compilation error
by Rob Conde 05 May '15

05 May '15

In boost 1.55 the following code compiled file on visual studio 2013 and g++ 4.4.7: #include "boost/filesystem/operations.hpp" void myFunc() { using namespace boost::filesystem; copy_option opt(copy_option::overwrite_if_exists); copy_file(path("p1"),path("p2"),opt); } in boost 1.58 I get the following error on g++ 4.4.7 (Visual Studio 2013 continues to work): test.cpp: In function 'void myFunc()': test.cpp:9: error: no matching function for call to 'copy_file(boost::filesystem::path, boost::filesystem::path, boost::filesystem::copy_option&)' boost/filesystem/operations.hpp:494: note: candidates are: void boost::filesystem::copy_file(const boost::filesystem::path&, const boost::filesystem::path&, boost::filesystem::copy_option::enum_type) boost/filesystem/operations.hpp:500: note: void boost::filesystem::copy_file(const boost::filesystem::path&, const boost::filesystem::path&) boost/filesystem/operations.hpp:505: note: void boost::filesystem::copy_file(const boost::filesystem::path&, const boost::filesystem::path&, boost::filesystem::copy_option::enum_type, boost::system::error_code&) boost/filesystem/operations.hpp:511: note: void boost::filesystem::copy_file(const boost::filesystem::path&, const boost::filesystem::path&, boost::system::error_code&) is this a bug in filesystem on gcc, a bug in gcc, a non-standard behavior in visual studio 2013, or an intended change? Rob Conde

2 2

Re: [boost] Description of pre-requisites for building Boost 1.58.0?
by Marko Asplund 05 May '15

05 May '15

On 2015-04-24 22:17:55 Ben Pope wrote: > This doesn't really answer the question, but as a practical note, you > can do: > sudo apt-get build-dep libboost* > Which will install the build dependencies for the version of Boost in > your repository, rather than the version you're trying to build, but it > should get you where you want to be most of the time. FYI, I submitted a documentation pull request for adding a short section about pre-requisite software installation: https://github.com/boostorg/boost/pull/78 marko

1 0