- Boost-users - lists.preview.boost.org

c++/cli & file.h
by It neophyte 16 Dec '14

16 Dec '14

hi quick question: could boost headers (.h) be complied in c++/cli project? I was told, no by someone, but need further feedback to be sure. Thanks

10 13

[endian] Heads up: breaking name changes coming
by Beman Dawes 15 Dec '14

15 Dec '14

Boost.Endian develop branch is about to have major changes merged in as part of the preparation for a mini-review. AFAICR, the breaking changes are limited to header, class, and function name changes, but there are a lot of hopefully non-breaking changes so I could easily be wrong about that. If you are currently using Boost.Endian develop branch, you will need to change your code accordingly. It would make sense to wait a few days until the mini-review merge is complete and any fixes required by regression test failures are fixed. Thanks for your patience, --Beman

1 0

Does shared_ptr support interface pointers without a virtual destructor
by John Selbie 15 Dec '14

15 Dec '14

What is the general guidance with using shared_ptr on interfaces that do not have virtual destructor? Take the following code sample: class IFoo{public: virtual void M1() = 0;}; class Foo : public IFoo{public: void M1() {} Foo() { std::cout << "Foo constructor\n";} ~Foo(){std::cout << "~Foo destructor\n";}}; I think we all know that this is not safe: { IFoo *pFoo = new Foo(); delete pFoo;} Since IFoo is missing a virtual destructor, then ~Foo() will not be invoked in the above case. So let's switch to using std::shared_ptr { std::shared_ptr<IFoo> spFoo(new Foo());} std::shared_ptr has a templated constructor that creates a "deleter". So when "spFoo" goes out of scope, the ~Foo destructor is properly invoked even though it's of type shared_ptr<IFoo>. But since my code targets older compilers, I have made use of Boost. But attempting this: { boost::shared_ptr<IFoo> spFoo(new Foo());} Generates a lot of scary warnings when compiling with -Wall. In file included from /home/jselbie/boost_1_57_0/boost/checked_delete.hpp:15:0, from /home/jselbie/boost_1_57_0/boost/smart_ptr/shared_ptr.hpp:26, from /home/jselbie/boost_1_57_0/boost/shared_ptr.hpp:17, from main.cpp:9:/home/jselbie/boost_1_57_0/boost/core/checked_delete.hpp: In instantiation of ‘void boost::checked_delete(T*) [with T = Foo]’:/home/jselbie/boost_1_57_0/boost/smart_ptr/detail/shared_count.hpp:134:38: required from ‘boost::detail::shared_count::shared_count(Y*) [with Y = Foo]’/home/jselbie/boost_1_57_0/boost/smart_ptr/shared_ptr.hpp:271:47: required from ‘void boost::detail::sp_pointer_construct(boost::shared_ptr<X>*, Y*, boost::detail::shared_count&) [with T = IFoo; Y = Foo]’/home/jselbie/boost_1_57_0/boost/smart_ptr/shared_ptr.hpp:349:58: required from ‘boost::shared_ptr<T>::shared_ptr(Y*) [with Y = Foo; T = IFoo]’main.cpp:36:44: required from here/home/jselbie/boost_1_57_0/boost/core/checked_delete.hpp:34:5: warning: deleting object of polymorphic class type ‘Foo’ which has non-virtual destructor might cause undefined behaviour [-Wdelete-non-virtual-dtor] Now despite the warning about the non virtual destructor, the correct behavior of having ~Foo() invoked works. The interesting thing is that marking the destructor of the *derived* class (virtual ~Foo) makes the warning go away. It's like it's warning me that if I ever inherit from Foo, then I might run into issues - not of any immediate problems. Should I never user shared_ptr with interface pointers that lack a virtual destructor? Always declare a virtual destructor? What is the guidance here? jrs

2 1

[boost] [compute] Review period starts today December 15, 2014, ends on December 24, 2014
by Antony Polukhin 15 Dec '14

15 Dec '14

Dear All, Review of the Compute library starts today on Mon 25st of December 2014 and will last for ten days. The Compute library provides a C++ interface to multi-core GPGPU and CPU computing platforms based on OpenCL. The project is hosted on GitHub at https://github.com/kylelutz/compute. Docs are available at http://kylelutz.github.io/compute/ Sources could be downloaded as a ZIP archive via https://github.com/kylelutz/compute/archive/master.zip Some pre-official reviews could be found in Boost Library Incubator: http://rrsd.com/blincubator.com/reviews/?library_id=669 Please, answer the following questions in your review: 1. What is your evaluation of the design? 2. What is your evaluation of the implementation? 3. What is your evaluation of the documentation? 4. What is your evaluation of the potential usefulness of the library? 5. Did you try to use the library? With what compiler? Did you have any problems? 6. How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? 7. Are you knowledgeable about the problem domain? And finally, every review should answer this question: 8. Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. -- Best regards, Antony Polukhin

1 0

[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