- Boost - lists.boost.org

[geometry][units]
by Pranam Lashkari 11 Jul '18

11 Jul '18

I am trying to use boost.geometry with the integration of boost.units. What I want to do is store a coordinate point (e.g: Cartesian or spherical) which should be unit safe.(e.g a cartesian point with length unit meter should give error with cross product is done with cartesian point with length unit millimeter). For this I am using boost::geometry::model::point. Problems I am facing: 1. If I use something like boost::geometry::model::point<UnitClass, 3 ,boost::geometry::cs::cartesian> then all the operations like cross product and dot product will fail as units can not be multiplied and if we multiply then dimensions and units will change. 2. suppose I want to use spherical 3d coordinate then boost::geometry::model::point is cable accommodate only one type of class for all the underlying dimension(eg: distance, longitude and latitude). But in real case distance should be in length and longitude and latitude should be in angle unit. Is there any way to integrate boost.units with boost.geometry for the purpose I mentioned above. Thank you, Pranam Lashkari

1 0

Boost.Graph depth_first_visit algorithm
by Brook Milligan 09 Jul '18

09 Jul '18

The documentation on the Boost.Graph depth_first_visit algorithm indicates that the first argument is a non-const reference to an Incidence Graph. See https://www.boost.org/doc/libs/1_67_0/libs/graph/doc/depth_first_visit.html. However, in contrast the code in boost/graph/depth_first_search.hpp only implements the function for a _const_ reference to an Incidence Graph. I can see that changing the graph structure mid-traversal is a problem, but I have use cases in which graph properties (not graph structure) must be changed along the traversal. Thus, it seems that a valid use case is for this algorithm to work as documented, i.e., on a non-const graph. The attached patch implements overloads for the non-const versions of depth_first_{visit|search}, including overloads for the dfs_visitor member functions. Is there some reason not to extend the implemented interface in this way to better agree with the documentation? Cheers, Brook

1 0

Clang 600 and BOOST_SYSTEM_CONSTEXPR causes error_code.hpp compile failure.
by Paul A. Bristow 09 Jul '18

09 Jul '18

Having failed to build Boost libraries using Clang 6.0.0 using b2/bjam on Windows, I am now trying instead to use Codeblocks on Windows 10 to build static libraries. It comes to grief with these messages (the berbose gory details can be posted if anyone can help). In file included from I:\modular-boost\boost/system/system_error.hpp:14: I:\modular-boost\boost/system/error_code.hpp:409:88: error: variable does not have a constant initializer template<class T> BOOST_SYSTEM_REQUIRE_CONST_INIT system_error_category cat_holder<T>::system_category_instance; ^~~~~~~~~~~~~~~~~~~~~~~~ I:\modular-boost\boost/system/error_code.hpp:409:19: note: required by 'require_constant_initialization' attribute here template<class T> BOOST_SYSTEM_REQUIRE_CONST_INIT system_error_category cat_holder<T>::system_category_instance; ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ I:\modular-boost\boost/system/error_code.hpp:392:44: note: expanded from macro 'BOOST_SYSTEM_REQUIRE_CONST_INIT' # define BOOST_SYSTEM_REQUIRE_CONST_INIT [[clang::require_constant_initialization]] ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This seems to be the ultimate cause I:\modular-boost\boost/system/error_code.hpp:226:41: note: non-constexpr constructor 'error_category' cannot be used in a constant expression BOOST_SYSTEM_CONSTEXPR explicit std_category( boost::system::error_category const * pc ): pc_( pc ) Is this because BOOST_SYSTEM_CONSTEXPR should not be defined? I note this in error_code.hpp #if defined(__GNUC__) && (__GNUC__ == 7 || __GNUC__ == 8) && __cplusplus >= 201700L // https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83835 # undef BOOST_SYSTEM_HAS_CONSTEXPR #endif should this undef list also include clang, and if so which versions 600? Or is there something about Boost.config and Codeblocks on Windows? Adding unconditional # undef BOOST_SYSTEM_HAS_CONSTEXPR seems to work. Suggestions welcome. Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830

7 13

toolset=clang-win uses clang-linux-win?
by Peter Dimov 09 Jul '18

09 Jul '18

When I try `b2 toolset=clang-win` on Appveyor, I get `clang-linux-win` instead, that is, `-win` is interpreted as version for some reason, not as platform: https://ci.appveyor.com/project/pdimov/system/build/job/sjpdq5yrir2ewuhh Is this normal, or is it a bug in the clang toolset? Is there a magic command line incantation that would let me select clang-win?

3 7

[Boost Build] clang-win, <compatibility> property?
by degski 08 Jul '18

08 Jul '18

error: Please set <compatibility> property for visual studio version! How and to what value (VS2017 - 15.7.4, Compiler Version 19.14.26431 ) do I set the <compatibility> property using a project-config.jam file? The documentation <https://boostorg.github.io/build/manual/develop/index.html#bbv2.reference.t…> does not list clang at all, which probably means it works like gcc, there is obviously no <compatibility> property there. Help would be appreciated, then I can post some build results of 1.68-rc2. degski -- *"If something cannot go on forever, it will stop" - Herbert Stein*

1 0

python::numpy not built on windows binary installers
by Nicholas Devenish 07 Jul '18

07 Jul '18

Hi All, I just downloaded the windows boost binaries from https://dl.bintray.com/boostorg/release/1.67.0/binaries/, linked from the boost downloads page. They are missing the boost_numpy library. This (silently) doesn't build if the python installation that boost finds is missing numpy. This is listed as "Third Party" so apologies if this is the wrong place to report it - but it's not clear from the page who makes them. I also couldn't find any mention of this, so don't know if it's a deliberate exclusion. Nick

2 3

[release] Boost 1.68.0 Beta 1 Release Candidate 2
by Marshall Clow 07 Jul '18

07 Jul '18

The release candidates for the second 1.68.0 beta release are now available at: <https://dl.bintray.com/boostorg/beta/1.68.0.beta1.rc2/source/> The release notes are not yet available. The updated documentation is not yet available. [ They will be available in a day or two. ] == Changes since RC1: * version.hpp now has the correct version number in it. * Boost.Wave now builds on FreeBSD * Boost.ProgramOptions should now pass tests on msvc-10.0. The SHA256 checksums are as follows: 961d2bdc74c1499c931b32098842abba8883b1a89ef5c8f8f0ab0aff771a3ce5 boost_1_68_0_b1_rc2.7z 0364846258648e39908ca7cebfc2d2216eef6980c32aaf8276d2cfe73ef012e3 boost_1_68_0_b1_rc2.tar.bz2 d99105685a68907a76b0479ecde77915423246236ef0db9cb846c5bfc09b41f3 boost_1_68_0_b1_rc2.tar.gz 6158e0e961bfb0d8adeb2ea70337b08504668258025f0a873fb21eee3436d22e boost_1_68_0_b1_rc2.zip As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. -- The Boost Release Managers

2 4

[iostreams] Merging to master
by Edward Diener 07 Jul '18

07 Jul '18

I would like to merge the iostream changes on 'develop' to 'master'. They are all green on the 'develop' tests, and have been tested for awhile now, and I have just been lax getting these to the 'master' branch.

3 4

[1.68.0 Beta1 RC1][iostreams][vs2017 preview] seekpos is not a member of std::pos
by Mateusz Loskot 07 Jul '18

07 Jul '18

Hi, I'm trying to build some of Boost libraries with the very latest VS 2017 Version 15.8.0 Preview 3.0 I've changed project-config.jam to point msvc-14.1 to the corresponding CL.EXE ``` using msvc : 14.1 : "c:\Program Files (x86)\Microsoft Visual Studio\Preview\Professional\VC\Tools\MSVC\14.15.26608\bin\HostX64\x64\cl.EXE" ; ``` In "x64 Native Tools Command Prompt for VS 2017 Preview", I do ``` .\bootstrap.bat b2 -j8 toolset=msvc-14.1 address-model=64 variant=release --with-iostreams ... compile-c-c++ bin.v2\libs\iostreams\build\msvc-14.1\release\address-model-64\link-static\threading-multi\file_descriptor.obj file_descriptor.cpp .\boost/iostreams/positioning.hpp(96): error C2039: 'seekpos': is not a member of 'std::fpos<_Mbstatet>' c:\Program Files (x86)\Microsoft Visual Studio\Preview\Professional\VC\Tools\MSVC\14.15.26608\include\iosfwd(132): note: see declaration of 'std::fpos<_Mbstatet>' ``` Is this expected? Shouldn't this be fixed by https://github.com/boostorg/iostreams/pull/57 ? Or the PR has not made it into the master? Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

2 4

[Boost PP] MSVC PP Updated Info
by degski 07 Jul '18

07 Jul '18

More info <https://blogs.msdn.microsoft.com/vcblog/2018/07/06/msvc-preprocessor-progre…> . degski -- *"If something cannot go on forever, it will stop" - Herbert Stein*

1 0