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

[Serialization] link error in 1.56
by Tobias Loew 25 Aug '14

25 Aug '14

Hi, linking the serialization lib fails in version1.56 with unresolved symbols due to the missing implementation of boost::archive::detail::shared_ptr_helper::shared_ptr_helper(void) boost::archive::detail::shared_ptr_helper::~shared_ptr_helper(void) up to version 1.55 those symbols were defined in libs\serialization\src\shared_ptr_helper.cpp, but now this file is excluded from the build and contains the implementation of a nowhere defined class shared_ptr_helper_base. Is there a replacement for shared_ptr_helper, is it redundant or is serialization broken in 1.56? Tobias -- View this message in context: http://boost.2283326.n4.nabble.com/Serialization-link-error-in-1-56-tp46668… Sent from the Boost - Dev mailing list archive at Nabble.com.

2 2

[container] New container: why is everybody silent?
by Alexander Kuprijanov 25 Aug '14

25 Aug '14

Hi boost community! Please tell me something about my container, don't be silent. I firmly intend to offer it to boost, because it's much faster than competitors (by a constant factor). It's intended to replace std::vector in cases, when an application requires multiple insertion/deletion. It takes O(log(N)) for insertion/deletion. Docs: http://alexkupri.github.com/array/ Code: https://github.com/alexkupri/array Best regards, Aleksandr Kupriianov

10 22

[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