- Boost - lists.preview.boost.org

[move] const rvalue failure.
by Mostafa 25 Aug '14

25 Aug '14

The following fails to compile on both g++ 4.8.2 and VS2005 using Boost 1.56: #include <boost/move/core.hpp> #include <boost/move/utility.hpp> struct MOC { MOC() : value(121) {} MOC(BOOST_RV_REF(MOC) rhs) : value(rhs.value) {} int value; private: //Declared and purposefully not defined. MOC & operator=(MOC); private: BOOST_MOVABLE_BUT_NOT_COPYABLE(MOC) }; MOC moveonlyMutableRValue() { return MOC(); } MOC const moveonlyConstRValue() { return MOC(); } int main() { MOC m(moveonlyConstRValue()); return 0; } with g++, I get the following error messages: boost_move_const_rvalue.cc: In function ‘int main()’: boost_move_const_rvalue.cc:28:30: error: invalid user-defined conversion from ‘const MOC’ to ‘boost::rv<MOC>&’ [-fpermissive] MOC m(moveonlyConstRValue()); ^ In file included from boost_move_const_rvalue.cc:1:0: /home/HPC/boost_installed/v1_56_0/include/boost/move/core.hpp:219:7: note: candidate is: MOC::operator boost::rv<MOC>&() <near match> operator ::boost::rv<TYPE>&() \ ^ boost_move_const_rvalue.cc:13:3: note: in expansion of macro ‘BOOST_MOVABLE_BUT_NOT_COPYABLE’ BOOST_MOVABLE_BUT_NOT_COPYABLE(MOC) ^ /home/HPC/boost_installed/v1_56_0/include/boost/move/core.hpp:219:7: note: no known conversion for implicit ‘this’ parameter from ‘const MOC*’ to ‘MOC*’ operator ::boost::rv<TYPE>&() \ ^ boost_move_const_rvalue.cc:13:3: note: in expansion of macro ‘BOOST_MOVABLE_BUT_NOT_COPYABLE’ BOOST_MOVABLE_BUT_NOT_COPYABLE(MOC) ^ boost_move_const_rvalue.cc:28:30: error: passing ‘const MOC’ as ‘this’ argument of ‘MOC::operator boost::rv<MOC>&()’ discards qualifiers [-fpermissive] MOC m(moveonlyConstRValue());

1 2

[serialization] get_helper documentation
by Joaquin M Lopez Munoz 24 Aug '14

24 Aug '14

Hi, I see the Loading and Saving Archive concepts in Boost.Serialization have been augmented with helper support via get_helper<Helper>(). However, this is only explicitly documented for *Loading* Archives, http://www.boost.org/libs/serialization/doc/archives.html when indeed Saving Archives must and do also provide such a member function. Best, Joaquín M López Muñoz Telefónica

1 0

[type_traits] is_character<T> trait
by Antony Polukhin 24 Aug '14

24 Aug '14

Hi, Boost.LexicalCast has a trait boost::detail::is_character<T>, that evaluates to true if T is char, char16_t, wchar_t, unsigned char or any other character type. If this trait looks useful, I can move it to TypeTraits library, add docs and tests. Is there any interest in such trait? -- Best regards, Antony Polukhin

3 2

Re: [boost] [Boost-users] [Chrono] The default BOOST_CHRONO_VERSION is still 1
by Vicente J. Botet Escriba 24 Aug '14

24 Aug '14

Le 24/08/14 01:49, DonM a écrit : > -------- Original Message -------- > Subject: Re: [Boost-users] [Chrono] The default BOOST_CHRONO_VERSION > is still 1 > From: "Vicente J. Botet Escriba" <vicente.botet(a)wanadoo.fr> > Date: 8/23/2014 6:28 AM > To: boost-users(a)lists.boost.org >> >> Le 23/08/14 01:41, DonM a écrit : >>> The docs (boost_1_56_0/doc/html/chrono/reference.html) say: >>> >>> "The default value for BOOST_CHRONO_VERSION will be changed to 2 >>> since Boost 1.55. " >>> >>> However, it still has the value 1 in both 1.55 and 1.56. >>> >>> Not a big deal, I just noticed and figured I'd mention it. >>> >> Hi, >> >> I must remove this comment as as there is a incompatibility this will >> break user code. I planned to do a smooth trarnsition, but there were >> some complains. >> >> Thanks for pointing this issue, >> Vicente > > Are you saying that you never intend to change the default value? That > would be a mistake, in my opinion. Version 2 is much better -- the I/O > stuff works. If users need backwards compatibility, they can define > version 1, but encourage people to use version 2. Just my $0.02. > What others think? Vicente

1 0

[math] pull request for boost::math::round bug in corner cases
by Robin Eckert 24 Aug '14

24 Aug '14

Hello, I found two corner cases in which boost::math::round doesn't round correctly. For double types, these are the numbers directly beneath 0.5: +/- 0.499999999999999944488848768742172978818416595458984375 (which get rounded to 1.0 although their aboslute value is smaller than 0.59) and odd integral numbers on the edge of the mantissa length: +/- 4503599627370497.0 +/- 4503599627370499.0 +/- 4503599627370501.0 ... +/- 9007199254740989.0 +/- 9007199254740991.0 +/- 9007199254740993.0 These get rounded to the next bigger/smaller integral value. For a detailed explanation and a fix, see the description of the pull request on https://github.com/boostorg/math/pull/8 Regards, Robin

1 0

[test] Using BOOST_CHECK_EQUAL with enum
by Edward Diener 23 Aug '14

23 Aug '14

In code I have the expression: BOOST_CHECK_EQUAL(cnew,e_test_third); where 'cnew' is: test_enum cnew; and test_enum is: enum test_enum { e_test_default, e_test_first, e_test_second, e_test_third }; This is giving me the error: ..\..\../boost/test/test_tools.hpp:100:1: error: expected ')' before 'do' do { \ ^ ..\..\../boost/test/test_tools.hpp:169:5: note: in expansion of macro 'BOOST_CHECK_WITH_ARGS_IMPL' BOOST_CHECK_WITH_ARGS_IMPL( ::boost::test_tools::tt_detail::equal_impl_frwd(), "", CHECK, CHECK_EQUAL, (L)(R) ) ^ test_auto_value.cpp:64:4: note: in expansion of macro 'BOOST_CHECK_EQUAL' BOOST_CHECK_EQUAL(cnew,e_test_third); ^ Is Boost Test incapable of checking that an enumeration object equals an enumerated value ? Is this a known problem ? How do I work around it ?

1 1

[iterator] Merge pull request
by Andrey Semashev 23 Aug '14

23 Aug '14

Hi, Some time ago I made this pull request: https://github.com/boostorg/iterator/pull/6 It makes some of the implementation details of Boost.Iterator public. These components are already used in Boost.Range and Boost.Tokenizer and the intent is to further patch these libs to use public interfaces instead of the implementation details. Could this pull request be merged?

2 6

[filesystem] Epoch of trivial_clock
by Bjorn Reese 23 Aug '14

23 Aug '14

The filesystem::trivial_clock type is implementation-defined [1]. That means that the epoch is also implementation-defined. How do we determine the epoch of trivial_clock? For instance, we may need to represent the last_write_time() timestamp to the end-user, or transfer it to another node when we implement a network file system. PS: I am looking at the std::filesystem proposal, but I assume that boost::filesystem will be update accordingly. [1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4097.html#8

5 7

GSOC: Boost.Math: hypergeometric functions
by Anton Bikineev 22 Aug '14

22 Aug '14

Hi all, I'm glad to represent my GSoC project work about implementation of hypergeometric functions: https://github.com/BoostGSoC14/boost.math I would like to thank everybody who helped me, essentially my mentor Christopher Kormanyos, my advisors John Maddock, Paul Bristow and, of course, Niall Douglas. The concentration of the project was mostly confluent hypergeometric function 1f1. Some essential algorithms were implemented and research works were done. A few short articles may be read in my blog: http://antoha-bikineev.blogspot.com Of course, it's gonna be updated while researching. The most important thing for me is that this work opened new ideas, ways and approaches for development and investigation of new numerical algorithms. Some of them are intended to reduce probability of cancellation errors in power series and to reduce round-off errors for recurrence relations at unstable directions. So there are plenty of stuff to do and improve.

1 0

[graph] Faster strong_components-implementation
by Alexander Lauser 22 Aug '14

22 Aug '14

Hi all, reimplementing Tarjan's dfs-visitor used in Boost.Graph's algorithm to compute strong components yielded a performance gain of about 15 to 20% (for adjacency_list-graphs). The problem is that due to bug #10231 [1], this implementation does not work with a current vanilla version of Boost. (See below for some details explaining my changes and the reason it is affected by the bug.) Is there interest in the faster implementation? If so, what's the best way to proceed? Wait until the bug is fixed and then incorporate the changes in a pull request? Create a pull request and hope that is not merged before the bug is fixed? Btw, my feeling is that the bug's not too involved and I tried to fix it myself. It seems that it is not even in Boost.Graph itself, but in Boost.TTI (in the macro-depths of which I got lost). Should I file a separate bug for Boost.TTI? For the details: My implementation is a back-to-the-root-approach, following the classical formulations of Tarjan's algorithm more closely. The current implementation somewhat "simulates" edge events upon leaving a vertex by an additional loop over all edges incident to the vertex. This can be avoided by using finish_edge -- which suffers from the above mentioned bug. (In addition to the performance-boost, I think it is also more natural to implement Tarjan's algorithm using finish_edge.) Cheers, Alex [1] https://svn.boost.org/trac/boost/ticket/10231

1 0