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