- Boost - lists.boost.org

[vmd] Adding to boost master branch
by Edward Diener 26 Aug '15

26 Aug '15

In an effort to get vmd as a submodule of the boost superproject master branch I submitted a PR against Boost on master ( https://github.com/boostorg/boost/pull/93 ). In this PR I added vmd to .gitmodules and also to the status/jamfile.v2 for testing. But looking at the Travis CI build of this a failure occurs: 0.01s$ cd status The command "cd status" exited with 0. 2.13s$ ../b2 -n -d0 error: Unable to find file or target named error: '../libs/vmd/test/' error: referred to from project at error: '.' There is most definitely a jamfile and tests at libs/vmd/test on the master branch. Is there something else I have to do to get vmd added to the master branch ?

3 5

Re: [boost] [Boost-users] [afio] Formal review of Boost.AFIO
by Niall Douglas 25 Aug '15

25 Aug '15

On 25 Aug 2015 at 12:30, Robert Ramey wrote: > > There is precedent for this: Boost.Fiber was provisionally approved > > here as a C++ 98 library with condition of a mini-review before > > entry. Boost.Fiber is now a C++ 14 library and sufficiently different > > from the library originally reviewed it may require a second > > mini-review if during its first mini-review it is felt still lacking. > > This is a precedent - a bad one which I hope to avoid a repetition of in > the future. A library which is accepted should be close enough to it's > final state so that it can be finished up on the order of a couple of > months and will result in a final version which is close to what > reviewers actually reviewed. > > We can't have a library pass a review, then have the package morph into > something significantly different then have it accepted. This make the > original review a farce. I've been watching Fiber closely since we reviewed it. As far as I know, the public API has barely changed. The documentation has improved in all the areas the review recommended. Just because the internal implementation is radically different does not mean it has morphed into something significantly different. For example, Oliver is considering making boost::fiber::future<> based on my Monad/Outcome Concurrency TS custom future framework as why bother duplicating the work. If he did, even then the public API reviewed and accepted into Boost remains exactly that which was reviewed and accepted. You don't really need to know or think about Monad/Outcome for boost::fiber::future<> to work as a C++ 11 type future. > All > > these changes to AFIO are almost entirely driven by changes since > > 2012 to the various WG21 technical standards. If they hadn't changed > > and C++ compilers (specifically MSVC) hadn't changed, AFIO wouldn't > > have changed. > > > It's very similar for Fiber, which had to be refactored > > in the face of substantial changes in C++ 14. > > I seriously doubt that a package which compiles and passes tests and > reviews with C++03 cannot do these things when C++11 comes out. What > really happens is that the author sees opportunities with C++11 that he > didn't have before then starts incorporating them after the original > review. I guess this would be called feature creep or implementation > creep. In any case, it indicates that the original acceptance was > premature. I think he saw a chance to make his internal implementation code vastly simpler and easier to maintain yes. Same as me. We're going to be supporting this thing for a decade or so, it makes sense to invest in saving ourselves work. > Ultimately it hinges on what "acceptance into Boost" means. To me it's > a library ready - with a few straight forward / uncontroversial changes > which is ready to be incorporated into the boost distribution. It's not > acceptance of an idea for a library, a prototype for a library, or that > a developer is certified to add a library in the future. I agree. But I draw the line between API and design and then the internal implementation. If it's just the latter which has changed and the API and design is identical, I think a mini-review is enough. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

1 0

boost.test documentation header
by Raffi Enficiaud 25 Aug '15

25 Aug '15

Hi, Boost.test 1.59 documentation header is not the same as the other boost libraries. In particular, the green header is missing: http://www.boost.org/doc/libs/1_59_0/libs/test/doc/html/index.html vs for instance: http://www.boost.org/doc/libs/1_59_0/libs/assert/assert.html I would like to know how to include this header and what I am missing in the documentation generation. Those headers are also mentioning the latest available version of the doc. Thanks, Raffi PS.: sorry for cross-posting, but I cannot get an answer on boost-doc ML/

3 4

Boost Social Event at CppCon
by Jon Kalb 25 Aug '15

25 Aug '15

Boosters, Because a lot of Boosters are going to be attending CppCon, we¹d like to arrange a social event for Boosters/C++Now regulars. http://cppcon.org/ If you are planning to attend CppCon or even If you are just going to be in or around Bellevue, Washington between September 20th and 25 and you¹d like to join us for dinner, please let us know so we can get a count. Please send mail to: social(a)boost.org Once we settle on a date, etc, we¹ll let everyone who responded know when and where, so please let us know, even if you are a ³maybe.² I hope to see you at CppCon. Jon

1 0

Re: [boost] [Boost-users] [afio] Formal review of Boost.AFIO
by Niall Douglas 25 Aug '15

25 Aug '15

On 25 Aug 2015 at 12:37, Paul A. Bristow wrote: > 1. Should Boost.AFIO be accepted into Boost? Please state all > conditions for acceptance explicity. > > Provisionally, yes. > > Requirements: > > . Major restructuring of documentation. (Not re-writing!) > > . Completion of Boost.Was_Called_Monad and APBind. > > . Creation of a TODO list. > > . Mini-review before going into a release (perhaps of all together?). > > . More documentation of examples to explain what they demonstrate. Thanks for the review Paul. I pretty much agree with all of it. This review process has been particularly useful for helping me see the documentation as others see it - I had no idea it was so confusing! - and I'm going to try raising with the Standard C++ Foundation in Seattle next month the idea of them funding professional copy writers to take passes at C++ library documentation. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

1 0

Did Boost 1.59.0 change the meaning of "using python : 3.4 : ..." in user-config.jam?
by Jonathan Wakely 24 Aug '15

24 Aug '15

Hi, I'm trying to update the Fedora rawhide package to Boost 1.59.0 and the build fails with the output below (ignore the MPI warnings). We build with the following in user-config.jam: # This _adds_ extra python version. It doesn't replace whatever # python 2.X is default on the system. using python : 3.4 : /usr/bin/python3 : /usr/include/python3.4m : : : : m ; Is that comment no longer true? Did something change in Boost 1.59.0 so that that line now sets the only allowed python version? I can make the build work with the following but I'd like to understand the change: using python : 2.7 : /usr/bin/python2 : /usr/include/python2.7 : : : : ; using python : 3.4 : /usr/bin/python3 : /usr/include/python3.4m : : : : m ; Build failure: + echo ============================= build serial ================== + ./b2 -d+2 -q -j4 --without-mpi --without-graph_parallel --build-dir=serial variant=release threading=multi debug-symbols=on pch=off python=2.7 stage MPI auto-detection failed: unknown wrapper compiler mpic++ Please report this error to the Boost mailing list: http://www.boost.org You will need to manually configure MPI support. /builddir/build/BUILD/boost_1_59_0/tools/build/src/build/feature.jam:494: in feature.validate-value-string from module feature error: "2.7" is not a known value of feature <python> error: legal values: "3.4" /builddir/build/BUILD/boost_1_59_0/tools/build/src/build/property.jam:276: in validate1 from module property /builddir/build/BUILD/boost_1_59_0/tools/build/src/build/property.jam:302: in property.validate from module property /builddir/build/BUILD/boost_1_59_0/tools/build/src/build/build-request.jam:216: in convert-command-line-element from module build-request /builddir/build/BUILD/boost_1_59_0/tools/build/src/build/build-request.jam:154: in build-request.from-command-line from module build-request /builddir/build/BUILD/boost_1_59_0/tools/build/src/build-system.jam:583: in load from module build-system /builddir/build/BUILD/boost_1_59_0/tools/build/src/kernel/modules.jam:295: in import from module modules /builddir/build/BUILD/boost_1_59_0/tools/build/src/kernel/bootstrap.jam:139: in boost-build from module /builddir/build/BUILD/boost_1_59_0/boost-build.jam:17: in module scope from module

2 8

Unicode characters in filenames
by Tom Kent 24 Aug '15

24 Aug '15

Recently there was a thread that ended up changing the boost guidelines so that Unicode characters are now allowed in C++ source files. http://lists.boost.org/Archives/boost/2015/06/223822.php However, in the 1.59 release, there was a filename that had unicode characters in it: libs\preprocessor\doc\Appendix A An Introduction to Preprocessor Metaprogramming.html. Which, HTML encoded, actually looks like: Appendix%20A%20%C2%A0%20An%20Introduction. Note the %C2%A0 character (Hex C2A0, Octal: 302240, Windows displays: ┬á)? Since this seems like a mistake, I've created a pull request for this in pre-processor. However, it begs the question: Should we support unicode codepoints for filenames in the boost distribution? I would like for this answer to be 'no' as there are still lots of tools out there that don't correctly handle unicode filenames. However, it is worth bringing up the discussion. Is there a reason we would want unicode file names? I would guess that tests uses them (especially the filesystem tests), however I would also expect that these tests generate the files on the fly, and that they aren't part of what is distributed. Thoughts? Tom Kent

5 9

"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

cache size runtime detection
by Joel FALCOU 22 Aug '15

22 Aug '15

We have a bunch of cross-platform CPU cache size and cache line size detection that we want to offload into boost in preparation for the first reviewable version of Boost.SIMD. It's rather smallish in term of API but the code is non-trivial. I think it's a bit broad to be in utility/core, doesn't really fit in align and IIRC there is no "general memory related" library in Boost. Questions: 1/ would there be interest to have such utility in Boost ? 2/ here should we put it ? Is Boost.Memory a viable solution or could it be hosted somewhere non-trivial ? Regards

10 25

[Polygon] trait register on derived class
by Lechuan Xue 21 Aug '15

21 Aug '15

Hi, Currently, if I have one custom geometry and a few further derived custom geometries, I need to do trait register on all of them. Like: class derived_point1 : public base_point {}; class derived_point2 : public base_point1 {}; namespace boost { namespace polygon { struct geometry_concept<base_point> { typedef point_concept type; }; struct geometry_concept<derived_point1> { typedef point_concept type; }; struct geometry_concept<derived_point2> { typedef point_concept type; }; } What I want is to register all custom geometries in one step. Like: template<typename T> struct geometry_concept<T, typename std::enable_if<std::is_base_of<base_point, T>()>::type> { typedef point_concept type; }; To do that, I need to add a dummy template type to all the trait classes to enable SFINAE. Attached is the patch (based on boost 1.57.0_1). Is this something we can consider? Thanks, Leo Xue

1 0