- Boost-users - lists.boost.org

[boost] [compute] Review period extended till December 30 + sum up
by Antony Polukhin 23 Dec '14

23 Dec '14

Hi, Review period of Compute library extended till December 30. Some notes and answers to them that were pointed out during review so far: * Some of the algorithms could be tuned for a specific hardware - Library author is working on a auto-tuning solution and improves existing algos * Why OpenCL C API used instead of C++ API? - C++ API had issues, C API allows a bit more control. No C++ API for OpenCL 2.0 * API is not N4105 compatible, library is not N*** compatible - This could be easily fixed by a library that will use Compute as a backend * Some of the algorithms return futures while other work with command queues - This is because of the OpenCL design + async chains/futures would be probably added later * Not all the types of the Khronos API are supported - A few types are not documented yet, there's a patch in the works which would allow the Khronos C++ types to be passed into Compute algorithms * A few type related errors could be detected at compile time - This will be fixed, more asserts would be added to runtime only checkable places. Report issues to the tracker https://github.com/kylelutz/compute/issues * On small data sets CPU algorithm would work faster than a GPGPU. How about implicitly dispatching algo on CPU in those cases? - The call on whether to execute the algorithm should be left up to the user. While library author agrees that this would be a useful feature, he just don't think Compute is the right place for that logic. * How about providing way to do chains of async operations - This is a big task that will be solved some day. * How about providing Boost.ASIO like error handling via throw and error_code - Implementing an approach like ASIO's wouldn't be that difficult. Thanks to all the reviewers for spending their time and providing useful comments so far! -- Best regards, Antony Polukhin

1 0

interprocess::rbtree_best_fit assertion failure with vector resize
by John Harris 22 Dec '14

22 Dec '14

I encountered this with 1.56 and 1.57 under heavy allocation load where I repeatedly resize an interprocess vector<unsigned char>. The only way I was able to get around it was to switch to the simple_seq_fit allocation algorithm. The assertion is assert(FALSE), and so I'm wondering if the algorithm doesn't handle all cases where there is a single-byte type for the vector. The stack below is from a core dump, and so the "Cannot access memory" errors are not necessarily indicative of bad pointers. #3 0x0000003dc2a2b820 in __assert_fail () from /lib64/libc.so.6 #4 0x00007f869a166793 in boost::container::container_detail::insert_value_initialized_n_proxy<boost::interprocess::allocator<unsigned char, boost::interprocess::segment_manager<char, boost::interprocess::rbtree_best_fit<boost::interprocess::mutex_family, boost::interprocess::offset_ptr<void, long, unsigned long, 0ul>, 0ul>, boost::interprocess::iset_index> >, unsigned char*>::copy_n_and_update (this=0x7f8698264b80) at /home/jharris/usr/local/boost/include/boost-1_57/boost/container/detail/advanced_insert_int.hpp:118 #5 0x00007f869a165fd6 in boost::container::vector<unsigned char, boost::interprocess::allocator<unsigned char, boost::interprocess::segment_manager<char, boost::interprocess::rbtree_best_fit<boost::interprocess::mutex_family, boost::interprocess::offset_ptr<void, long, unsigned long, 0ul>, 0ul>, boost::interprocess::iset_index> > >::priv_forward_range_insert_expand_backwards<boost::container::container_detail::insert_value_initialized_n_proxy<boost::interprocess::allocator<unsigned char, boost::interprocess::segment_manager<char, boost::interprocess::rbtree_best_fit<boost::interprocess::mutex_family, boost::interprocess::offset_ptr<void, long, unsigned long, 0ul>, 0ul>, boost::interprocess::iset_index> >, unsigned char*> > ( this=0x7f85adc00a40, new_start=0x7f85adc165a0 <error: Cannot access memory at address 0x7f85adc165a0>, new_capacity=199624, pos=0x7f85adc31974 <error: Cannot access memory at address 0x7f85adc31974>, n=101192, insert_range_proxy=...) at /home/jharris/usr/local/boost/include/boost-1_57/boost/container/vector.hpp:2783 #6 0x00007f869a164c0b in boost::container::vector<unsigned char, boost::interprocess::allocator<unsigned char, boost::interprocess::segment_manager<char, boost::interprocess::rbtree_best_fit<boost::interprocess::mutex_family, boost::interprocess::offset_ptr<void, long, unsigned long, 0ul>, 0ul>, boost::interprocess::iset_index> > >::priv_forward_range_insert_no_capacity<boost::container::container_detail::insert_value_initialized_n_proxy<boost::interprocess::allocator<unsigned char, boost::interprocess::segment_manager<char, boost::interprocess::rbtree_best_fit<boost::interprocess::mutex_family, boost::interprocess::offset_ptr<void, long, unsigned long, 0ul>, 0ul>, boost::interprocess::iset_index> >, unsigned char*> > (this=0x7f85adc00a40, pos=..., n=101192, insert_range_proxy=...) at /home/jharris/usr/local/boost/include/boost-1_57/boost/container/vector.hpp:2265 #7 0x00007f869a1639ec in boost::container::vector<unsigned char, boost::interprocess::allocator<unsigned char, boost::interprocess::segment_manager<char, boost::interprocess::rbtree_best_fit<boost::interprocess::mutex_family, boost::interprocess::offset_ptr<void, long, unsigned long, 0ul>, 0ul>, boost::interprocess::iset_index> > >::priv_forward_range_insert<boost::container::container_detail::insert_value_initialized_n_proxy<boost::interprocess::allocator<unsigned char, boost::interprocess::segment_manager<char, boost::interprocess::rbtree_best_fit<boost::interprocess::mutex_family, boost::interprocess::offset_ptr<void, long, unsigned long, 0ul>, 0ul>, boost::interprocess::iset_index> >, unsigned char*> > (this=0x7f85adc00a40, pos=..., n=101192, insert_range_proxy=...) at /home/jharris/usr/local/boost/include/boost-1_57/boost/container/vector.hpp:2328 #8 0x00007f869a16241a in boost::container::vector<unsigned char, boost::interprocess::allocator<unsigned char, boost::interprocess::segment_manager<char, boost::interprocess::rbtree_best_fit<boost::interprocess::mutex_family, boost::interprocess::offset_ptr<void, long, unsigned long, 0ul>, 0ul>, boost::interprocess::iset_index> > >::priv_forward_range_insert_at_end<boost::container::container_detail::insert_value_initialized_n_proxy<boost::interprocess::allocator<unsigned char, boost::interprocess::segment_manager<char, boost::interprocess::rbtree_best_fit<boost::interprocess::mutex_family, boost::interprocess::offset_ptr<void, long, unsigned long, 0ul>, 0ul>, boost::interprocess::iset_index> >, unsigned char*> > (this=0x7f85adc00a40, n=101192, insert_range_proxy=...) at /home/jharris/usr/local/boost/include/boost-1_57/boost/container/vector.hpp:2365 #9 0x00007f869a1604e5 in boost::container::vector<unsigned char, boost::interprocess::allocator<unsigned char, boost::interprocess::segment_manager<char, boost::interprocess::rbtree_best_fit<boost::interprocess::mutex_family, boost::interprocess::offset_ptr<void, long, unsigned long, 0ul>, 0ul>, boost::interprocess::iset_index> > >::priv_resize<boost::container::value_init_t> (this=0x7f85adc00a40, new_size=178780, u=...) at /home/jharris/usr/local/boost/include/boost-1_57/boost/container/vector.hpp:2151 #10 0x00007f869a15de56 in boost::container::vector<unsigned char, boost::interprocess::allocator<unsigned char, boost::interprocess::segment_manager<char, boost::interprocess::rbtree_best_fit<boost::interprocess::mutex_family, boost::interprocess::offset_ptr<void, long, unsigned long, 0ul>, 0ul>, boost::interprocess::iset_index> > >::resize (this=0x7f85adc00a40, new_size=178780) at /home/jharris/usr/local/boost/include/boost-1_57/boost/container/vector.hpp:1213 #

1 0

[Random] normal distribution different behaviour 1.55 vs 1.57
by Thomas M 21 Dec '14

21 Dec '14

Hi, I have just switched an existent project from boost 1.55.0 to 1.57.0 and my test suites diagnosed a divergence in program (a simulation) results. I have tracked down the issue to different behaviour in the normal distribution random variates generator. Below is a simple program (run under VS 2012, Update 4) that outputs random variates for a uniform and a normal distribution; comparing the output between 1.55.0 and 1.57.0 it turns out that the first bunch of uniformly distributed variates is identical, and then all others variates (both bunches of normally distributed variates as well as the second bunch of uniformly distributed variates) diverge. Neither for 1.56.0 nor 1.57.0 does the change-log list an update to the random numbers library, so first I am puzzled why the libraries behave differently (though [Math] has undergone some changes -> propagation to [Random]?). Second, it is not clear to me why for the first bunch of uniformly distributed variates the results are identical, while for the second, after normally distributed variates were generated, the are not. It appears that the generation of normally distributed variates changes the whole state of the random numbers engine in a different manner [e.g multiple engine calls ??]. Any insight into what is going on here is much appreciated. And foremost: Is any of 1.55 or 1.57 bugged, that is one should be clearly preferred over the other? many thanks, Thomas #include <ostream> #include <iostream> #include <fstream> #include "boost/random.hpp" void test_rng() { typedef boost::mt19937 rnengine_t; typedef boost::uniform_01<double> uniform_distr_t; typedef boost::normal_distribution<double> normal_distr_t; typedef boost::variate_generator<rnengine_t &, uniform_distr_t> uniform_gen_t; typedef boost::variate_generator<rnengine_t &, normal_distr_t> normal_gen_t; uniform_distr_t uniformDistr; normal_distr_t normalDistr(0, 1); rnengine_t rnEngine; rnEngine.seed(100); uniform_gen_t uniformGen(rnEngine, uniformDistr); normal_gen_t normalGen(rnEngine, normalDistr); std::ofstream outFile("randomNumbers.txt"); outFile.precision(16); int n = 20; for (int outer = 0; outer < 2; ++outer) { for (int i = 0; i < n; ++i) outFile << "Uniform-distr variate #" << (n*outer) + i + 1 << ": " << uniformGen() << std::endl; for (int i = 0; i < n; ++i) outFile << "Normal-distr variate #" << (n*outer) + i + 1 << ": " << normalGen() << std::endl; } } int main() { test_rng(); return 0; }

5 8

Boost.container iterator_traits and flat_map
by gast128 21 Dec '14

21 Dec '14

Hello all, I have a problem here which boils down to the non-constness of iterator_traits for const_iterator of flat_map: void Foo() { typedef boost::container::flat_map<int, int> Int2IntFmap; Int2IntFmap::const_iterator it2; std::iterator_traits<Int2IntFmap::const_iterator>::value_type::first_type& r2 = it2->first; } 1>d:\develop\shared\main\test\testcommon\testgeneral\nctstgenhmhandlemap.cpp(59): error C2440: 'initializing' : cannot convert from 'const int' to 'int &' Anyone an idea or should I use decltype instead?

1 0

[multi_index] any interests extending ord_index_node to argumented ord_index_node
by fractal 19 Dec '14

19 Dec '14

dear all: i'm a game developer, and my projects used a lot of multi_index(thanks, it's a great library). one of main problems of game development is to rank players according to they level. usually we use boost::interprocess::map for the task. but more, players should know which rank they are and who is at rank 10000 (for example). these requirements lead to two new methods for map: iterator find_by_rank(int idx) int rank(iterator i) i implemented an argumented rbtree data structure according to "Algorithms and Data Structures " (see the attachment rank_tree.hpp), and latter i find coutertree which is in boost review schedule. but IMHO, the best way is to integrate it to multi_index, and if anyone interests, i can do this by some efforts. yours sincerely

1 0

RFC: library for fractal algorithms
by legalize+jeeves＠mail.xmission.com 17 Dec '14

17 Dec '14

[Please do not mail me a copy of your followup] I'm interested in talking with other folks about the best way to generalize various fractal algorithms in the style of the standard library: iterators, containers and algorithms. If there are any libraries that already exist that apply to this sort of code, I'd love to hear about them. Most fractals consist of iterating a sequence for a point in the complex plane. The iterating sequence is parameterized for each point in the complex plane and some characteristic of the iterating sequence is used to color that point. The result is an image. For instance, the classic Mandelbrot fractal is: z <- z^2 + c z0 := 0 The complex number 'c' changes for each point in the complex plane. This sequence is iterated until norm(z) > 4, or some maximum iteration count is reached. Pixels in the image correspond to each value of 'c' and are typically colored according to the number of iterations needed until norm(z) exceeded 4. There are a couple things that make for interesting variation in the algorithms used in rendering fractal images: - choice of formula to iterate in the complex plane - parameters for deciding the "bailout" criteria: - iteration counts - predicate function on z, i.e. [](complex<float> z){ return norm(z) > 4; } Iterating until the bailout test passesis the simplest mechanism, but there are gains to be made by applying more sophisticated mechanisms. A significant optimization is to look for cycles in the sequences. With very large iteration counts, detecting cycles in the iteration can save significant amounts of time. The cycle detection algorithm is basically from Knuth and isn't specific to fractals but ends up being mixed together with the Mandelbrot set computation in most programs. This seems to be another opportunity to use generic composition in order to apply this orthogonal feature to any iterated formula in the complex plane. I did a little experiment casting the Mandelbrot formula as an iterator and got the code at the end of this message. Ideally I'd like to explore approaches that result in code that is ignorant of the underlying representation of a complex number in order to have algorithms that can be applied to arbitrary precision numeric types. My little experiment works, but even just looking at this little experiment makes me think that the mandelbrot iterator is doing too much: it is performing the z <- z^2 + c business, but it is also doing the bailout test and these seem to be separate responsibilities. #include <complex> #include <iostream> #include <iterator> #include <vector> class mandelbrot : public std::iterator< std::input_iterator_tag, std::complex<float>, unsigned> { public: mandelbrot() : c_{}, iter_{}, max_iter_{}, bailout_{}, z_{}, bailed_out_{true} { } mandelbrot(std::complex<float> const& c, int max_iter = 256, float bailout = 2.0f) : c_{c}, max_iter_{max_iter}, bailout_{bailout*bailout}, iter_{0}, z_{0.f, 0.f}, bailed_out_{false} { } mandelbrot& operator++() { z_ *= z_; z_ += c_; bailed_out_ = ++iter_ > max_iter_ || std::norm(z_) >= bailout_; return *this; } bool operator==(mandelbrot const& rhs) const { if (bailed_out_ && rhs.bailed_out_) { return true; } if (bailed_out_ != rhs.bailed_out_) { return false; } return z_ == rhs.z_; } std::complex<float> const& operator*() const { return z_; } private: std::complex<float> c_; int const max_iter_; float const bailout_; int iter_; std::complex<float> z_; bool bailed_out_; }; bool operator!=(mandelbrot const &lhs, mandelbrot const &rhs) { return !(lhs == rhs); } int main() { float const r_min = -3.0f; float const r_max = 1.0f; float const i_min = -2.0f; float const i_max = 2.0f; std::vector<float> imag; imag.resize(24); for (int y = 0; y < 24; ++y) { imag[y] = i_min + (i_max - i_min)*(23 - y)/24.0f; } std::vector<float> real; real.resize(80); for (int x = 0; x < 80; ++x) { real[x] = r_min + (r_max - r_min)*x/80.0f; } std::string printables; for (int i = 32; i < 128; ++i) { printables.push_back(char(i)); } for (int y = 0; y < 24; ++y) { float const im = imag[y]; for (int x = 0; x < 80; ++x) { float const re = real[x]; mandelbrot end; mandelbrot it{std::complex<float>{re, im}}; unsigned count = std::distance(it, end); std::cout << printables[count % printables.size()]; } std::cout << '\n'; } } -- "The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline> The Computer Graphics Museum <http://computergraphicsmuseum.org> The Terminals Wiki <http://terminals.classiccmp.org> Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>

1 1

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