June 2014 - Boost - lists.preview.boost.org

[Modularization] Levels classification
by Vicente J. Botet Escriba 04 Jun '14

04 Jun '14

Hi, could we add a page listing the modules by levels following this rule * A module is in Level 0 if it doesn't depends on other modules * A module is in Level 1 if it depends only on modules at level 0 * A module is in Level N+1 if it depends only on modules at level N or lower levels We have now the following modules that satisfy the rule Moduler levels Level 0 : Config Predef Preprocessor Level 1 : Assert Static Assert Level 2 : Core Level 3 : Utility (After moving string_ref out (???), moving iterator to Core and generator_iterator to Iterator Peter, could you update the Dependency report? Could your report assign a level following this rule and show the modules with an assigned level? Best, Vicente

2 3

[multiprecision] General/design query about which conversions should be implicit/explicit
by John Maddock 04 Jun '14

04 Jun '14

Folks, I have an open bug report https://svn.boost.org/trac/boost/ticket/10082 that requests that conversions from floating point to rational multiprecision-types be made implicit (currently they're explicit). Now on the one hand the bug report is correct: these are non-lossy conversions, so there's no harm in them being implicit. However, it still sort of feels wrong to me, the only arguments against I can come up with are: 1) An implicit conversion lets you assign values such as 0.1 to a rational (which actually leads to 3602879701896397/36028797018963968 not 1/10), where as making the conversion explicit at least forces you to use a cast (or an explicit construction). 2) Floating point values can result in arbitrarily large integer parts to the rational, effectively running the machine out of memory. Arguably the converting constructor should guard against that, though frankly exactly how is less clear :-( Does anyone else have any strong views or insights into this? Thanks in advance, John.

8 8

[GSoC][MPL11] Post C++Now update
by Louis Dionne 04 Jun '14

04 Jun '14

Dear Boost, A lot happened during the past week in Aspen; the goal of this message is to summarize insights, changes and feedback received wrt MPL11. The slides of the presentation are available at [1]. The second part of the presentation is especially relevant to get an overview of the designs considered so far. Merging the MPL and Fusion -------------------------- After discussing the issue several times during the week, I (and others) think it might be possible to merge Fusion and the MPL into a single library. I am currently trying to write a library that does that. Since this constitutes a large reorientation, I created a new repository which is available at [2]. Those with interest should consider subscribing to the repository to be updated as I make progress. Iterator-free design -------------------- I was a bit anxious that people would complain about this, but the contrary happened. Nobody complained and some people expressed support. This design aspect will stay as-is. Request for guinea pigs ----------------------- I am looking for people with hardcore C++1y metaprogramming needs who will be willing to test the library I come up with (MPL11 or MPL + Fusion merge). I also need to see use cases for the library, so please reply even if you are not willing to test. Roadmap ------- Finish exploring the design space. If it turns out that we can merge the MPL and Fusion, then I'll be working on that for a while. If I find that this is not possible or not a good idea, I'll go back to my initial GSoC planning. In both cases, I hope to have a library in the incubator by the end of the summer. Also, this new roadmap is approved by my mentor. Feel free to reply with questions and/or comments. Regards, Louis [1]: http://ldionne.com/mpl11-cppnow-2014 [2]: http://github.com/ldionne/hana

15 34

[master] Building boost 1.56 - only 4 libs are built
by Christian Henning 04 Jun '14

04 Jun '14

When I execute the following command usually all libs are built: bjam -j8 --toolset=msvc --without-mpi variant=debug link=static runtime-link=shared define=_CRT_NONSTDC_NO_DEPRECATE define=_CRT_SECURE_NO_DEPRECATE define=_SCL_SECURE_NO_DEPRECATE define=BOOST_REGEX_MATCH_EXTRA stage > log_x86_debug.txt But on the current master only three libs are built or copied into my stage folder. libboost_container-vc120-mt-gd-1_56.lib libboost_context-vc120-mt-gd-1_56.lib libboost_exception-vc120-mt-gd-1_56.lib libboost_prg_exec_monitor-vc120-mt-gd-1_56.lib Is my command incorrect? I have been using it for many years. Regards, Christian

4 5

mpl/test/set_c.cpp mystery
by Peter Dimov 04 Jun '14

04 Jun '14

mpl/test/set_c.cpp has been failing for all my toolsets (in both master and develop) with the same error, In file included from ..\..\../boost/mpl/set/aux_/begin_end_impl.hpp:19:0, from ..\..\../boost/mpl/set/set0.hpp:29, from ..\..\../boost/mpl/set/set0_c.hpp:18, from ..\..\../boost/mpl/set/set10_c.hpp:19, from ..\..\../boost/mpl/set/set20_c.hpp:19, from ..\..\../boost/mpl/set_c.hpp:36, from set_c.cpp:14: ..\..\../boost/mpl/set/aux_/iterator.hpp:57:1: error: no type named `base` in `struct boost::mpl::set0_c<bool>` The regression report is all green though, so it was a bit of a mystery. Turned out that I needed to run "b2 headers". So there is an MPL header that b2 misses, although I don't have time at the moment to identify which one. But I decided to report the experience anyway, in case someone runs into the same problem. :-)

1 0

[quickbook] Need some help.
by Andrzej Krzemienski 04 Jun '14

04 Jun '14

Hi, Could someone help me with quickbook format? How can I nest the [section] elements so that this nesting is reflected in the table of contents and html files? I have 2 levels of nesting of element [section]: [section A] [section AA] [endsect] [section AB] [endsect] [endsect] When generatin the html docs , sections AA and AB end up in the same html file. How can I change it? (So that they land in two different files) If it is possible, can I control it by section? Regards, &rzej

3 2

status/expected_results.xml must go!
by Beman Dawes 04 Jun '14

04 Jun '14

In a discussion on the Steering Committee mailing list, Robert Ramey wrote: > I'm still having a problem with a newer library which only supports a more recent version > of C++ such as C++11. Our testing system doesn't permit me to say "don't test this compilers > which don't support C++11". With our current system, anyone who looks at test results will > get failures for compilers which don't support the version his library requires. This is incorrect, > and misleading to potential users of the library, and discourages authors from submitting > libraries which depend on modern C++ features. Also, it wastes a lot of testing time generating > this bogus information. I would ask that the powers that be try to convince the maintainers of > the boost testing setup to address this. The current way we markup expected failures is via boost-root/status/expected_results.xml. That creates two problems: * It is a maintenance nightmare as more and more libraries are added to Boost. This is library-specific information and so should be part of each module, not the super-project. * As Robert points out, we shouldn't even be running tests that are bound to fail anyhow. It would seem that each library needs to be able to tell bjam/b2 to skip certain tests, or even all tests, under certain conditions. As Marshall Clow has been pointing out, we desperately need someone to take over the regression test reporting maintenance, and redesign it to meet our current needs. --Beman

2 2

Unmerged changes in MPL
by Peter Dimov 04 Jun '14

04 Jun '14

The following commits are only in mpl:develop but not in mpl:master: C:\Projects\boost-git\boost\libs\mpl>git log master..develop commit f976861e13f0bb37dd6380c02ccc0d42140daebe Author: Paul <pfultz2(a)yahoo.com> Date: Fri May 16 02:38:50 2014 -0400 Add test for constexpr conversion operator commit ed58434c88ac03816fa0d232c679d551987b42a9 Author: Paul <pfultz2(a)yahoo.com> Date: Sun Dec 29 05:46:32 2013 -0500 Add constexpr to conversion operator for bool integral constants commit 1f482c4fa1d8fc66dc34776b04414f660cc66e76 Author: Paul <pfultz2(a)yahoo.com> Date: Sat Dec 28 23:29:09 2013 -0500 Add constexpr to conversion operator for integral constants What needs to be done with them? Release or revert?

3 2

[predef] Version 1.1 (Boost 1.56)
by Rene Rivera 04 Jun '14

04 Jun '14

FYI.. I've merged over the develop 1.1 version of Predef to master for general use. This should resolve the request from Beman to get this done ASAP :-) Changes for this release include: * Addition of `BOOST_PLAT_*` platform definitions for MinGW and Windows platform variants. * Detection of ARM architecture for Windows compilers to target mobile devices of WIndows 8. * Improved ARM detection for 64 bit ARM. * Added detection of iOS an an operating system. * Improved detection of endianess on some platforms. * Addition of exclusive plus emulated definitions for platform and compiler detection. The big change for this version is the restructuring of the definitions to avoid duplicate definitions in one category. That is, only one `BOOST_OS_*`, `BOOST_COMP_*`, and `BOOST_PLAT_*` variant will be detected (except for sub-categories). -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

2 1

Proposal: Boost.Core
by Peter Dimov 04 Jun '14

04 Jun '14

I propose the creation of a new module, Boost.Core, a repository of Boost core utilities. The criteria for inclusion into this module would be that the utility component is (a) simple, (b) used by other Boost libraries, (c) does not depend on any headers outside of Core and Config (and perhaps Assert). Its primary purpose would be to break dependencies. It will not serve as a repository of "this might be useful". Based on the interest so far, I volunteer myself, Glen Fernandes and Andrey Semashev as maintainers. The following utilities are immediate candidates for migration into the new module: - addressof - enable_if - boost/pointee.hpp - boost/indirect_reference.hpp - boost/type.hpp In addition, the following can be duplicated inside to reduce dependencies: - mpl::if_, if_c, eval_if - detail/is_incrementable.hpp - remove_cv and so on.

10 51