- Boost - lists.boost.org

[Range] 1.68 master/beta MSVC compilation error with /fpermissive-
by Vinnie Falco 13 Jul '18

13 Jul '18

When compiling using /fpermissive- (enable strict conformance) I get the following compilation error: boost\boost\range\concepts.hpp(257): error C3646: 'n': unknown override specifier boost\boost\range\concepts.hpp(264): note: see reference to class template instantiation 'boost::range_detail::RandomAccessIteratorConcept<Iterator>' being compiled boost\libs\beast\include\boost\beast\core\string.hpp(87): note: see reference to class template instantiation 'boost::basic_string_view<char,std::char_traits<char>>' being compiled boost\boost\range\concepts.hpp(257): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int boost\boost\range\concepts.hpp(257): error C3646: 'n': unknown override specifier boost\boost\range\concepts.hpp(264): note: see reference to class template instantiation 'boost::range_detail::RandomAccessIteratorConcept<Iterator>' being compiled I'm using the tip of master, digest 000bd8507f8a17ada2c1fef19158e16cdeabd631 Thanks

6 14

[Boost.Serialization] Help with PR fixing a memory leak in the current version
by Alexander Grund 12 Jul '18

12 Jul '18

Hi, TLDR: I would like https://github.com/boostorg/serialization/pull/105 to be merged for the next Boost release to fix a memory leak and need someone to review this or help getting it merge-ready. Details: Some time ago I made an analysis of a crash introduced in Boost 1.65.0 in the serialization part. The details are quite complicated as the cause is static initialization/destruction order in shared libraries which may even depend on compilers (could not confirm) or standard libraries (dito, observed in all tested versions). It boils down to a violation of the expected destruction order in the case of shared libraries. I observed how 2 global instances of the same type but from different shared libs are destroyed together although the 2nd should not yet be which causes a use-after-free from another global instance. The Singletons involved did have methods to detect, whether they are active or destroyed but they were kinda optimized away in Boost 1.65 leading to a crash which makes the whole library unusable. Not understanding the root cause of the crash lead to changing the singleton to use dynamic allocation, but not freeing it which leads to the memory leak that is currently in Boost. The current state of the develop-branch changed this back to the crash situation we had before making it unsuitable for the next release. Another pair of eyes would be great to check the PR and get this finally fixed. Thanks, Alex

6 33

[rational, spirit] 1.68.0 beta 2 bug report
by James E. King III 12 Jul '18

12 Jul '18

A bug reported by someone using a version of 1.68.0 (not specified): https://github.com/qtumproject/cpp-eth-qtum/issues/31#issuecomment-404257256 Seems to have something to do with the new pow template that was added to rational. This came from an old pull request that was simplified, however it seems pow is now a template defined in the namespace boost, and seems to have caused some issues. I'd guess this is only an issue inside boost namespace (so all boost headers) and not external namespaces. Not sure at the moment if the fix should be in rational or spirit. We could instead back out the change to rational for 1.68.0 where pow() was added into namespace boost. https://github.com/boostorg/rational/pull/21 - Jim

2 1

boost/context/all.hpp missing in 1.68.0beta1
by Roger Leigh 11 Jul '18

11 Jul '18

Is this intentional, or an unintentional regression? I was using this header in the CMake component checks to verify the presence of Boost.Context, and this is now breaking. I can update it to use a different header which has been present since 1.61, but this seems like a compatibility break, hence the question. Thanks, Roger

2 1

Fwd: [Range] 1.68 master/beta MSVC compilation error with /fpermissive-
by degski 11 Jul '18

11 Jul '18

It did go off-list. ---------- Forwarded message ---------- From: degski <degski(a)gmail.com> Date: 11 July 2018 at 19:16 Subject: Re: [boost] [Range] 1.68 master/beta MSVC compilation error with /fpermissive- To: Mateusz Loskot <mateusz(a)loskot.net> On 11 July 2018 at 18:56, Mateusz Loskot <mateusz(a)loskot.net> wrote: > (was your response intentionally direct and off-list?) > No, not intentionally, but it depends on how you send the email (because I pushed reply), like on this one (it would have gone off-list again). I had to add the mailing list back in. This doesn't happen with most posts. I'm not sure what you mean, but I meant the driver that Vinnie mentioned > I'm not totally sure what Vinnie mentions. But I'm talking about this one for stable <https://releases.llvm.org/6.0.1/LLVM-6.0.1-win64.exe> and this one for (almost) trunk <http://prereleases.llvm.org/win-snapshots/LLVM-7.0.0-r336178-win64.exe>. I have the impression Vinnie is talking about Clang/C2 <https://blogs.msdn.microsoft.com/vcblog/2016/04/06/clangc2-we-need-your-adv…>, but like I said it's not clear to me, that compiler, however, is discontinued. degski --- *"If something cannot go on forever, it will stop" - Herbert Stein*

1 0

[Histogram] Status of the review schedule
by Mateusz Loskot 11 Jul '18

11 Jul '18

Hi, Following some discussion in January this year, Hans Dembinski's Histogram library was scheduled for review in March. AFAICT, no review happened. What is the current status of the proposal? Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

2 4

[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