- Boost-users - lists.boost.org

[endian] Boost.Endian library added for 1.57.0
by Beman Dawes 14 Dec '14

14 Dec '14

The library provides integer and floating point types and conversion functions for portable byte ordering regardless of processor endianness. Although the primary uses are for file or network I/O, it is also useful for unaligned integers or floats, or for 3, 5, 6, and 7 byte integers. The library's predecessors have been in use for thirty years and developed independently multiple times. The repository is https://github.com/boostorg/endian The documentation is online at https://boostorg.github.io/endian/ See https://boostorg.github.io/endian/index.html#Release-history for changes since the Formal Review. No need to report "Inspection Report" problems; those will be cleaned up before 1.57.0 ships. Please do report any other problems or concerns, since the time between now and when the 1.57.0 beta ships in effect acts a mini-review period. If anyone has access to a big-endian platform with a modern C++ compiler, please, please run the endian test suite and report the results. All testing and use in recent years has been on little-endian platforms, so big-endian platform testing is a worry. Thanks for you patience, --Beman

3 2

:typedef mt19937, normal_distribution, variate_generator & data storage into vector
by It neophyte 14 Dec '14

14 Dec '14

hi all, does someone know why my vstore vector returns a 0 value? any suggestion to improve the code would be appreciated.cheers. *aim*: *generating 260 random numbers following a standard normal distribution, then store the values into a vector (here: vstore)* vector<double>vstore; vstore.resize(260); typedef mt19937 ALEA; typedef normal_distribution<double> STGAUSSIAN; typedef variate_generator<ALEA,STGAUSSIAN> GENALEA; ALEA ale; STGAUSSIAN stgauss(0,1); GENALEA gen(ale,stgauss); for (int i=0;i<=260;i++) { //cout<<gen()<<endl; //system("pause"); vstore.push_back(gen()); cout<<vstore[i]<<endl; }

2 2

[serialization] slow compile times with archive register_type
by Elizabeta 14 Dec '14

14 Dec '14

Hi I am using custom archive classes. Problem is BOOST_CLASS_EXPORT_GUID is not working with the custom archive classes, i.e I am getting unregistered class exceptions all over the place, when saving derived class with base pointer. Here is link to my question http://boost.2283326.n4.nabble.com/BOOST-CLASS-EXPORT-GUID-with-custom-arch… about this. So I found other way for exporting the classes, i.e with archive register type. Exporting the classes with register_type is working well, no more unregistered_class exceptions, but probelm is it increase the compile times of my project by more than half. Project compile time with register_type is 40-45 minutes, and without 18-19 minutes. Here is how I am using the register_type : //RegisterMyTypes.h template<class Archive> void register_all_types(Archive&); //RegisterMyTypes.cpp #include "A.h" #include "B.h" // other classes includes template<class Archive> void register_all_types(Archive& a) { ar.register_type (); ar.register_type(); ..... all other classes which is maybe 100 } // explicit instiantion of all my archive classess template void register_all_types(XmlWOArchive& ar); template void register_all_types(XmlWIArchive& ar); template void register_all_types(DbgXmlWOArchive& ar); template void register_all_types(DbgXmlWIArchive& ar); template void register_all_types(BinaryOArchive& ar); template void register_all_types(BinaryIArchive& ar); template void register_all_types(CloneBinaryOArchive & ar); template void register_all_types(CloneBinaryIArchive & ar); template void register_all_types(DuplicateBinaryOArchive & ar); template void register_all_types(DuplicateBinaryIArchive & ar); I am calling register_all_types before doing the serialization/deserialization. And I am doing the serialization/deserialization in multiple functions in my project not just in one place, but this should not be problem, I mean I have the registration done only in one cpp file i.e RegisterMyTypes.cpp, so the templates should be instantiated only in this file, and it should be slow, right ? Thank you for any help -- View this message in context: http://boost.2283326.n4.nabble.com/serialization-slow-compile-times-with-ar… Sent from the Boost - Users mailing list archive at Nabble.com.

2 4

Re: [Boost-users] Using static code checkers against the Boost code base
by Niall Douglas 13 Dec '14

13 Dec '14

On 11 Dec 2014 at 13:38, boost-users(a)lists.boost.org wrote: > I was given some time to implement automated nightly testing for > Boost.Thread which is now integrated and appears as a dashboard on > https://github.com/boostorg/thread/tree/develop. > > I'll mux in the clang and MSVC static analysers later today. This now done, and as can be seen on the Boost.Thread CI dashboard we currently see 30 of 90 build targets have problems. We'll get to fixing those over the next few days. After that we'll hopefully keep everything all blue from now on. Thanks for raising the problem, it caused resources to be made available. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

1 0

[Test] Reviving BOOST_*_CLOSE_COLLECTIONS request
by Ghyslain Leclerc 13 Dec '14

13 Dec '14

Hello, We are in the process of creating unit tests for our in-house application development and have selected Boot.Test as a library. I’ve been toying with the library for a while now and there is one feature that I feel is missing. It is the capacity to check a whole collection for close values, i.e. the “close” equivalent of BOOST_*_EQUAL_COLLECTIONS. From what I can tell, this has already been discussed (old threads from 2007 http://boost.2283326.n4.nabble.com/Boost-Test-request-BOOST-CLOSE-COLLECTIO…) and did not end-up in the library (at least from what I can tell from my version of boost (1.57). Other more recent threads (2012, http://boost.2283326.n4.nabble.com/test-BOOST-TEST-universal-testing-tool-t…) seem to suggest that the library is undergoing under the hood changes (I might be wrong here). So this request might be completely inappropriate, given the timing. Nevertheless, I have come up with an implementation for those macros. I wanted to share them here on the list (code at the end of the mail). It might be useful for some people. If Gennadiy (library maintainer) reads this mail and finds the macros adequate for use, great. If not, too bad. Anyhow, thanks. Ghyslain namespace boost_hlp { template <typename Left, typename Right> inline ::boost::test_tools::predicate_result close_coll_impl( Left lt_begin, Left lt_end, Right rt_begin, Right rt_end, ::boost::test_tools::percent_tolerance_t<double> tolerance ) { ::boost::test_tools::predicate_result res( true ); ::std::size_t pos = 0; for( ; lt_begin != lt_end && rt_begin != rt_end; ++lt_begin, ++rt_begin, ++pos ) { if( !(::boost::test_tools::check_is_close( *lt_begin, *rt_begin, tolerance )) ) { res = false; res.message() << "\nMismatch in a position " << pos << ": " << *lt_begin << " != " << *rt_begin; } } if( lt_begin != lt_end ) { std::size_t r_size = pos; while( lt_begin != lt_end ) { ++pos; ++lt_begin; } res = false; res.message() << "\nCollections size mismatch: " << pos << " != " << r_size; } if( rt_begin != rt_end ) { std::size_t l_size = pos; while( rt_begin != rt_end ) { ++pos; ++rt_begin; } res = false; res.message() << "\nCollections size mismatch: " << l_size << " != " << pos; } return res; } } // namespace boost_hlp #define CLOSE_COLLECTIONS_IMPL( L_begin, L_end, R_begin, R_end, tolerance, TL ) \ BOOST_TEST_TOOL_IMPL( \ check_impl,\ ::boost_hlp::close_coll_impl( (L_begin), (L_end), (R_begin), (R_end), \ ::boost::test_tools::percent_tolerance_t<double>((tolerance) )), "", TL, CHECK_EQUAL_COLL ), \ 5, \ BOOST_STRINGIZE( L_begin ), BOOST_STRINGIZE( L_end ), \ BOOST_STRINGIZE( R_begin ), BOOST_STRINGIZE( R_end ),\ BOOST_STRINGIZE( ::boost::test_tools::percent_tolerance_t<double>((tolerance) ) ) ) \ /**/ #define WARN_CLOSE_COLLECTIONS( L_begin, L_end, R_begin, R_end, tolerance ) \ CLOSE_COLLECTIONS_IMPL( (L_begin), (L_end), (R_begin), (R_end), (tolerance), WARN ) #define CHECK_CLOSE_COLLECTIONS( L_begin, L_end, R_begin, R_end, tolerance ) \ CLOSE_COLLECTIONS_IMPL( (L_begin), (L_end), (R_begin), (R_end), (tolerance), CHECK ) #define REQUIRE_CLOSE_COLLECTIONS( L_begin, L_end, R_begin, R_end, tolerance ) \ CLOSE_COLLECTIONS_IMPL( (L_begin), (L_end), (R_begin), (R_end), (tolerance), REQUIRE )

3 3

Re: [Boost-users] [Test] Reviving BOOST_*_CLOSE_COLLECTIONS request
by Ghyslain Leclerc 13 Dec '14

13 Dec '14

> Hello, > > We are in the process of creating unit tests for our in-house application > development and have selected Boot.Test as a library. ?I?ve been toying > with the library for a while now and there is one feature that I feel is > missing. ?It is the capacity to check a whole collection for close values, > i.e. the ?close? equivalent of BOOST_*_EQUAL_COLLECTIONS. Devel Boost.Test can do much better: BOOST_AUTO_TEST_CASE(foo) { vector<float> a, b; BOOST_TEST( a == b, tolerance(1e-5) ); BOOST_TEST( a <= b, percent_tolerance = 1e-5 ); } BOOST_TEST_DECORATOR( -tolerance = 1e-7 ) BOOST_AUTO_TEST_CASE(goo) { vector<float> a, b; BOOST_TEST( a > b ); BOOST_TEST( a != b ); } e.t.c. Gennadiy Gennadiy, thanks for pointing it out and taking the time to answer. I had read some of that in the archive threads. When is the devel Boost.Test expected to become the main version ? How can I get the devel version of the code ? Sorry if these seem like newbie questions. Again, thanks for the info. Ghyslain

2 1

Thread prioritization on OSX
by Alexander Carôt 13 Dec '14

13 Dec '14

Hello all, according to this: http://www.boost.org/doc/libs/1_57_0/doc/html/thread/thread_management.html #thread.thread_management.tutorial.attributes I tried to change the thread priority to SCHED_RR on OS X via: boost::thread::attributes attrs; pthread_attr_setschedpolicy(attrs.get_native_handle(), SCHED_RR); sendThread = boost::thread(attrs,&sender::sendItThreadFunction,this); In that context I noticed that get_native_handle is not known so I used attr.native_handle(), which compiled ok but finally threw an error here: /boost/boost/bind/bind.hpp:313:9: Type 'boost::thread_attributes' does not provide a call operator I am still using boost 1.45 and wonder if this is the actual problem or if something else is wrong. Any help appreciated, thanks Alex Am 20.11.14 10:53 schrieb "Ben Pope" unter <benpope81(a)gmail.com>: >On Thursday, November 20, 2014 05:27 PM, Alexander Carôt wrote: >> Hello all, >> >> is it correct that boost does not offer thread prioritization ? > >There's nothing directly on the interface. > >> I am dealing with an application with a number of threads, which all >> depend on the realtime-scheduled sound card callback thread. >> >> These threads must have the same realtime scheduling priority. >> >> Is there a way to achieve this ? > >Basically there's a platform specific back door: native_handle. > >http://www.boost.org/doc/libs/1_57_0/doc/html/thread/thread_management.htm >l#thread.thread_management.tutorial.attributes > >Ben > > > >_______________________________________________ >Boost-users mailing list >Boost-users(a)lists.boost.org >http://lists.boost.org/mailman/listinfo.cgi/boost-users

2 9

BOOST_CLASS_EXPORT_GUID with custom archive
by Elizabeta 13 Dec '14

13 Dec '14

Hi I am using boost 1.49. I have custom archives derived from the boost binary archives. However it seems that when using BOOST_CLASS_EXPORT_GUID the types are not actually registered for the custom archive types, and I am getting unregistered_class exception when serializing derived class from base pointer. If I am using the boost binary original archives this is not the case. My custom archive classes are defined in in its own header file and at the end of the file I am including BOOST_SERIALIZATION_REGISTER_ARCHIVE, according to this in the documentation : " The newly created archive will usually be stored in its own header module. All that is necessary is to include the header and construct an instance of the new archive. EXCEPT for one special case. Instances of a derived class are serialized through a base class pointer. Such instances are not "registered" neither implicitly nor explicitly. That is, the macro BOOT_CLASS_EXPORT is used to instantiate the serialization code for the included archives. To make this work, the following should be included after the archive class definition. #define BOOST_SERIALIZATION_REGISTER_ARCHIVE(Archive) Failure to do this will not inhibit the program from compiling, linking and executing properly - except in one case. If an instance of a derived class is serialized through a pointer to its base class, the program will throw an unregistered_class exception." here is my archive h file : ------------------- customarchive.h -------------------- #include <boost/archive/binary_iarchive.hpp> #include <boost/archive/binary_oarchive.hpp> #include <boost/archive/binary_oarchive_impl.hpp> #include <boost/archive/binary_iarchive_impl.hpp> #include <boost/archive/shared_ptr_helper.hpp> class CloneBinaryIArchive : // don't derive from binary_oarchive !!! public boost::archive::binary_iarchive_impl< CloneBinaryIArchive, std::istream::char_type, std::istream::traits_type >, public boost::archive::detail::shared_ptr_helper { typedef CloneBinaryIArchive derived_t; typedef boost::archive::binary_iarchive_impl< CloneBinaryIArchive, std::istream::char_type, std::istream::traits_type > base_t; public: CloneBinaryIArchive(std::istream & is,unsigned int flags = 0) : base_t(is, flags) {} CloneBinaryIArchive(std::streambuf & bsb, unsigned int flags = 0) : base_t(bsb, flags) {} int foo; }; BOOST_SERIALIZATION_REGISTER_ARCHIVE(CloneBinaryIArchive) and here is the cpp file in each I am registering all classes : -------------- register.cpp --------------- #include "customarchive.h" #include <boost/serialization/export.hpp> #include "A.h" BOOST_CLASS_EXPORT_GUID(A,"A") -- View this message in context: http://boost.2283326.n4.nabble.com/BOOST-CLASS-EXPORT-GUID-with-custom-arch… Sent from the Boost - Users mailing list archive at Nabble.com.

2 1

share_ptr and Container compilation error on new version
by JB 13 Dec '14

13 Dec '14

Hello all, I'm trying to build an application. This isn't an app that I wrote but rather inherited. I'm currently porting it from Fedora 15 to Fedora 20. It compiled well on gcc 4.6.3 with boost 1.46.0. However, Fedora 20 has gcc 4.8.3 and boost 1.54. I'm new to boost and have never used it before but it looks very comprehensive. As far as I know boost/shared_ptr is the only header this component of the application is including. I'm wondering if boost changes might be causing this or maybe gcc changes but it's difficult to tell from the documentation and I'm a little under the gun at the moment. This code: template<typename Container> class DefinableVectorFinalizer: public XmlFinalizer { typedef typename Container::value_type contained_value_type; typedef typename Container::value_type::value_type value_type; .... } g++ is throwing this error which seems to have some sort of problem with Container::value_type::value_type: ../../../../../devel/include/xcl/io/DefinableVectorFinalizer.h:31:54: error: no type named ‘value_type’ in ‘xclApp::DefinableVector<boost::shared_ptr<simApp::Project> >::value_type {aka class boost::shared_ptr<mainApp::Project>}’ typedef typename Container::value_type::value_type value_type; xclApp::DefinableVector looks like this: class DefinableVector { public: typedef typename std::vector<T>::size_type size_type; typedef typename std::vector<T>::value_type value_type; typedef value_type& reference; typedef const value_type& const_reference; typedef typename std::vector<T>::iterator iterator; typedef typename std::vector<T>::const_iterator const_iterator; .... } Any insight into this would be hugely appreciated!!!

3 4

intrusive bug: equal_range implementation vs bounded_range precondition
by Matei David 12 Dec '14

12 Dec '14

In the absence of a bug tracker, I'll post the potential bug here: I'm seeing some strange results out of `multiset::equal_range`. I didn't isolate a test case, but looking at the code something seems wrong: The `bstree_algorithms::equal_range(const KeyType &, KeyValueCompare)` method is currently implemented (in `bstree_algorithms.hpp`) as a call to `bstree_algorithms::bounded_range(header, key, key, comp, true, true)`. However, `bounded_range` states as prerequisite: If 'lower_key' == 'upper_key', ('left_closed' or 'right_closed') must be false. Either the `equal_range` implementation or the `bounded_range` precondition is wrong. Matei

2 3