- Boost - lists.boost.org

Stand-alone Boost.Python
by Stefan Seefeld 18 Jun '16

18 Jun '16

Hello, I have started working on a new SCons-based build infrastructure for Boost.Python that allows the Boost.Python code to be compiled stand-alone against a pre-installed Boost. I have checked in a first version to the develop branch, and have enabled Travis-CI to use that. While this works reasonably well, and provides a much simpler workflow for developers wanting to contribute to Boost.Python, it isn't (yet) entirely feature-complete. Notably, running this on Windows (using MSVC) produces errors. I'd appreciate any help with this, especially from Windows users who are more familiar with MSVC than I am (that shouldn't be hard, given I have next to no experience with using MSVC :-) ). Building Boost.Python is now very simple: * clone the repo via `git clone https://github.com/boostorg/python.git` and switch to the 'develop' branch * configure a build via `scons config --python=... --boost-prefix=...` * build and test via `scons test` Hopefully this will make it much simpler to contribute and test patches, so we can work down the list of accumulated PRs and issues. (For avoidance of doubt: for the immediate future I have no intentions to replacing the official bjam-based build system. But once the new one has proven to be stable enough, I expect to actually build stand-alone releases for Boost.Python.) Thanks, Stefan -- ...ich hab' noch einen Koffer in Berlin...

1 0

Using Boost with VS 14.0 update 3 RC and Clang 3.8.0 (from CodeBlocks IDE) compile fails in MS type_traits is_assignable
by Paul A. Bristow 15 Jun '16

15 Jun '16

I am trying to check a program that compiles on VS with 14.0 update 3 RC and on Codeblocks IDE GCC 5.3 compile OK, but CodeBlocks Clang 3.8.0 fails: C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include\type_traits:524:45: error: '_To' does not refer to a value : integral_constant<bool, __is_assignable(_To, _From)> I:\modular-boost\boost\mpl\aux_\preprocessed\plain\or.hpp|58|error: pasting formed 'BOOST_PP_TUPLE_ELEM_O_3(', an invalid preprocessing token [-Winvalid-token-paste] and terminally many more. clang++.exe -Wall -std=c++14 -m64 -fexceptions -O4 -m64 -std=c++14 -fms-extensions -Wall -m64 -fms-compatibility-version=19.00 -II:\modular-boost -c J:\Cpp\hellos\fixed_point_constexpr\fixed_point_constexpr.cpp -o obj\Release\fixed_point_constexpr.o I see some discussion of similar problem on https://groups.google.com/forum/#!topic/boost-list/MvqaK4SDy_c and a possible apparent fix on https://github.com/boostorg/type_traits/pull/24 Any suggestions for working around this problem? Paul PS I may try to use a *nix platform for this. --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830

2 1

[density] new library
by Giuseppe Campana 14 Jun '16

14 Jun '16

Hi to all, I'm working to density, a C++11 header-only library for heterogeneous containers and lifo memory management. It is not complete, but it is very close (and usable already). Just to avoid confusion, the test project of density contains a sub-module called testity, that in a near future will become a separate library. I'm wondering if it may become a valid proposal for a new library. In any case, any kind of feedback is welcome. Source code at https://github.com/giucamp/density Documentation at http://peggysansonetti.it/tech/density/html/index.html Regards, Giuseppe Campana.

6 9

[property_tree] Quoting documentation
by alainm 13 Jun '16

13 Jun '16

Hi, I am using property_tree for a project, and I'd like to provide a description of the format. That text is exactly what I need: http://www.boost.org/doc/libs/1_61_0/doc/html/property_tree/parsers.html#pr… I am going to provide a link to the doc, but would need to insert the text into the documentation pdf too (some people actually still read paper). Is it possible and what kind of copyright text should I use ? Thanks Alain

2 1

Start to contribute to Boost.
by Зайцев Александр 11 Jun '16

11 Jun '16

Hello. I very want to start contribute to Boost library. I want to help this project. And... maybe for start i can try to fix some bugs. Can you give me some pieces of advice, what i can do at start? Thanks. -- С уважением, Зайцев Александр.

3 2

Pimpl Again?
by Vladimir Batov 10 Jun '16

10 Jun '16

Don't laugh but it is only fairly recently at work that I managed to move all our supported platforms to C++11. So, then, I started moving our code to C++11 (what a delight!) and stumbled upon my old pimpl which is used quite a bit around my workplace for all its good properties... :-) Now C++11-ed piml turned out to be very small and very basic. So basic it felt it did not have the right to exist. Still, it encapsulates and enforces the "proper" pimpl properties and behavior, reduces implementation minutia and offers a recognizable deployment pattern (helps other people reading the code). Over the years IMO the technique has been proven as legitimate and useful, a basic but important building block... rather than a curiosity item. Unfortunately, despite many articles and a few Sutter's GotWs about it there is nothing ready-to-go like std::unique_ptr. I feel that pimpl and its deployment pattern need to be codified, described, "standardized" and in our toolboxes to stop/avoid everyone re-inventing the pimpl and making the same mistakes. IMO Boost is best positioned for that. Do you think we might review what I've got and/or maybe collectively come up with something better... It's no MPL or Hana but as std::unique_ptr it's one of the first "little things" I personally reach out for in my everyday work. IMO having pimpl in Boost would save quite a few hours of frustration for many. Thoughts? No pressure. I am easy either way. :-) https://github.com/yet-another-user/pimpl Docs are freshened up but still somewhat out of date. Apologies.

15 84

[config] Changes needed for VC++ 2015 Update 3?
by Beman Dawes 09 Jun '16

09 Jun '16

The VS 2015 Update 3 release candidate has been announced. See https://blogs.msdn.microsoft.com/vcblog/2016/06/07/compiler-improvements-in… (The following is partially for Boost developers who care about msvc, and partially to remind myself of what may need to be done to support update 3. It will be several weeks before I can work on this, so if any of the other config maintainers want to step in, please do so.) Update 3 supports standards versioning switches similarly to gcc, clang, and other compilers. We probably want to update Boost.Config accordingly. See https://blogs.msdn.microsoft.com/vcblog/2016/06/07/standards-version-switch… Update 3 fixes lots of constexpr bugs, so we need to review whether or not BOOST_NO_CXX11_CONSTEXPR is still required. Note that in develop there is an undocumented config macro BOOST_MSVC_CXX11_CONSTEXPR that turns off BOOST_NO_CXX11_CONSTEXPR to facilitate testing. Update 3 fixes the expression SFINAE issues that were causing most of the Boost develop test failures. https://blogs.msdn.microsoft.com/vcblog/2016/06/07/expression-sfinae-improv… Quoting from that: There are still three failing tests in the Boost [develop] test suite when compiling with MSVC. Two test failures relate to using the noexcept operator in a template type argument. We currently parse it immediately, even in a dependent context. One test failure is a Boost library issue that we’ve reported to the [library's] maintainers. There are still known update 3 expression SFINAE issues (see "What remains to be done?" in the blog article) so do we continue to define BOOST_NO_SFINAE_EXPR? There is an undocumented BOOST_MSVC_SFINAE_EXPR macro in develop that turns off BOOST_NO_SFINAE_EXPR, so it is easy for developers to use msvc expression SFINAE if the want to. But our usual criteria for a _NO_ macro is not full compliance, but whether or not Boost code works with a feature. So using that criteria for update 3 we would remove BOOST_NO_SFINAE_EXPR. Opinions? --Beman <aside> We always urged Microsoft to test their releases against Boost. For update 3 expression SFINAE, they did exactly that. Thanks to Microsoft's Andrew Pardoe for coordinated the effort and to Xiang Fan for running the tests and tracking down the reason for each test failure. An undocumented Boost.Config macro BOOST_MSVC_SFINAE_EXPR to support their testing. The approach was to run tests for all libraries with the normal test setup, and then run again with BOOST_MSVC_SFINAE_EXPR defined. If the problem was with the Boost library, Xiang then reported it to me. I need to review a long series of email exchanges with him to make sure I alerted library maintainers to any Boost problems. </aside>

5 9

Boost Best Practice text download option fails.
by Fletcher, John P 08 Jun '16

08 Jun '16

This is a very interesting item to me. https://svn.boost.org/trac/boost/wiki/BestPracticeHandbook This has an option at the end to download as plain text. This fails on my browser (Firefox) with "Corrupted Content Error" which I have never seen before. Please sort this out someone. John

2 1

[variant] spirit broken
by Jürgen Hunold 08 Jun '16

08 Jun '16

Hi Antony, according to git bisect, your commit ----------- commit b3650685f941a0c35cadfd878a185f274e132788 Author: Antony Polukhin <antoshkka(a)gmail.com> Date: Sat May 28 01:29:52 2016 +0300 Variant constructors and assignment operators now do not participate in overload resolutions if variant can not hold the input type (trac 5871, trac 11602) ------------ broke Boost.Spirit. The test failures can be seen in the regression matrix. For example: http://www.boost.org/development/tests/develop/developer/output/Flast-FreeB… fails with ../boost/variant/variant.hpp:1152:7: note: while substituting deduced template arguments into function template 'operator=' [with T = boost::variant<boost::spirit::info::nil_, std::__1::basic_string<char>, boost::recursive_wrapper<boost::spirit::info>, boost::recursive_wrapper<std::__1::pair<boost::spirit::info, boost::spirit::info> >, boost::recursive_wrapper<std::__1::list<boost::spirit::info, std::__1::allocator<boost::spirit::info> > > >] class variant ^ ../boost/spirit/home/support/info.hpp:29:12: note: definition of 'boost::spirit::info' is not complete until the closing '}' struct info It seems that the commit somehow disabled support for recursive variant usage. To reproduce this, just run the Spirit regression test. 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

2 5

[Spirit] real_policies<> and 1.0#NAN
by Pete Bartlett 08 Jun '16

08 Jun '16

Hi, Boost.Spirit is not sure of itself when it comes to parsing representations of infs and nans such as “1.0#NAN”. The docs [1] for the default real_policies<T> for parsing numbers say: “[…] with the additional detection of NaN and Inf as mandated by the C99 Standard and proposed for inclusion into the C++0x Standard: nan, nan(...), inf and infinity (the matching is case-insensitive). This corresponds to the following grammar:” The first sentence suggests that 1.0#NAN etc will not be parsed. But the grammar itself then says: <quote> nan = -lit("1.0#") >> no_case["nan"] >> -('(' >> *(char_ - ')') >> ')') ; inf = no_case[lit("inf") >> -lit("inity")] ; </quote> suggesting that "#1.0NAN" is intended to parsed, but "#1.0INF" is not! Then the in-code docs [2] however suggest that both "1.0#NAN" and "1.0#INF" are intended to be parsed: <quote> // The second call allows to recognize representation formats starting // with a 1.0 (such as 1.0#NAN or 1.0#INF etc.). </quote> However, the actual code fails to parse either of these these. This is because in [3] the presence of the "0" causes frac_digits to be non-zero and so the "traits::is_equal_to_one(..)" condition is never tested. In the case "1.#NAN" (without a zero) frac_digits is zero so the condition is tested and we enter the traits::parse_nan code, but now the text parsed to this sub-parser is "#NAN" and the parser does not cater for the initial "#". Could the maintainers state which behaviour is intended...hopefully I may be able to supply a patch to docs/code/tests knowing that. Regards, Pete [1] http://www.boost.org/doc/libs/1_61_0/libs/spirit/doc/html/spirit/qi/referen… [2] <boost/spirit/home/qi/numeric/real_policies.hpp> [3]<boost/spirit/home/qi/numeric/detail/real_impl.hpp>

2 1