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

Re: [Boost-users] Collecting boost multi-index meta data
by Joaquin M Lopez Munoz 25 Mar '11

25 Mar '11

Gokulakannan Somasundaram <gokul007 <at> gmail.com> writes: > > > Hi, > Say i have a boost::tuple / MPL Sequence, on which i have > created a multi-index. Is it possible for me collect all the > attribute numbers on which i have declared the > IndexSpecifierList( the one passed as template parameter to > boost::multi_index::indexed_by ) ? Hi Gokul, I'm not sure I undersand your question. Have you taken a look at the index_type_list nested type? http://www.boost.org/libs/multi_index/doc/reference/multi_index_container.h… types >From this MPL sequence you can easily extract the list of key extractor types used for defining the multi_index_container, which hopefully is close to what you're after. Don't hesitate to elaborate a little more on your question and I'll see whether I can be more helpful. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

3 4

[BGL] Separating twin vertices
by Shaun Jackman 19 Mar '11

19 Mar '11

Hi, I have a directed graph where every vertex has a twin vertex. It is known ahead of time which pairs of vertices are twins. I want to remove as few vertices as possible from the graph such that no vertex and its twin is in the same connected component. Could someone suggest an appropriate algorithm? I've just started delving into the BGL. So far I'm suitably impressed! Cheers, Shaun

2 5

[iostreams] restriction device/filter
by Borko Jandras 09 Mar '11

09 Mar '11

Hello, I'm looking at the implementation of the "restriction" device, from Boost.Iostreams library, which provides access to a subsequence of the original device. When it reaches the end of the input subsequence, the restriction device start performing read()'s of size zero on the original device. Shouldn't it be returning an end-of-sequence marker (EOF) instead? I am using a restriction device as source parameter for the iostreams::copy function and this always results in an infinite loop. Am I doing something wrong? Thanks! - Borko

3 3

[GIL] gray pixel iterator in generic algorithm
by Curtis Gehman 17 Feb '11

17 Feb '11

I'm trying to use GIL pixel iterators in a generic STL-style algorithm. I'm primarily using GIL for the generic 2D iterators. And in my context, I'm only interested in grayscale images. The value_type associated with GIL iterators is a pixel type, which typically is an object representing multiple channels (e.g., colors). It makes sense that comparison operators (e.g., <) are not defined for general color pixel types. For grayscale images, however, it makes sense that common arithmetic and comparison operators would be defined for the pixel type. This seems to be the case for the 8-bit grayscale GIL type (gray8_view_t). The iterator's value_type appears to be seamlessly evaluated to an unsigned char, exactly as I would expect. When I try to use a float image view type, however, the same magic doesn't seem to happen. Below is some toy code that demonstrates the issue. When the last line is knocked out with "//", the code compiles. But with that second template instantiation (for floats) there, the compiler (gcc 4.2 and VC++2010) exits when it does not find an operator< for the iterator's value_type when instantiating for gray32fc_view_t. I suppose that I can roll my own less<iterator_traits<SrcView::x_iterator>::value_type> functors. But I just started using GIL, and I'm hoping that there is a simpler solution. Any ideas? #include <algorithm> #include <iterator> #include <vector> #include <boost/gil/gil_all.hpp> namespace g = boost::gil; using std::vector; using std::iterator_traits; template <typename SrcView> inline vector<typename iterator_traits<typename SrcView::x_iterator>::value_type> row_min(const SrcView& src) { typedef typename iterator_traits<typename SrcView::x_iterator>::value_type value_t; vector<value_t> result; for (int y = 0; y < src.height(); ++y) { result.push_back(*std::min_element(src.row_begin(y), src.row_end(y))); } return result; } // Explicit template instantiation // Works for gray8c_view_t. template vector<iterator_traits<g::gray8c_view_t::x_iterator>::value_type> row_min(const g::gray8c_view_t& src); // Compile error for gray32fc_view_t. // No operator< for iterator_traits<g::gray32fc_view_t::x_iterator>::value_type. template vector<iterator_traits<g::gray32fc_view_t::x_iterator>::value_type> row_min(const g::gray32fc_view_t& src);

3 7

Thread changes from Boost 1.38 to 1.45
by Ven Tadipatri 08 Feb '11

08 Feb '11

Hi, We upgraded our project from using Boost 1.38 to Boost 1.45 but now seem to be having some thread issues. The error doesn't happen for every run, but occasionally the wait method in condition_variable_any fails. At other times the program seems to run into an infinite loop, presumably waiting for a lock that's never released. I looked at the changes in http://www.boost.org/doc/libs/1_45_0/doc/html/thread/changes.html but don't see what could be causing the error to occur only after upgrading to Boost 1.45. Has anyone else experienced their code breaking when upgrading to the latest version of Boost? Thanks, Ven

5 10

Re: [Boost-users] multi_array and variants
by Alle Meije Wink 07 Feb '11

07 Feb '11

Dear Kris, thanks for your reply. > > What I now have is a class bisArray: > > ... > > template<typename T> > > class bisArray: public bisObject { > > typedef boost::variant > > < boost::multi_array_ref<T, 1>, > > boost::multi_array_ref<T, 2>, > > boost::multi_array_ref<T, 3>, > > boost::multi_array_ref<T, 4>, > > boost::multi_array_ref<T, 5>, > > boost::multi_array_ref<T, 6>, > > boost::multi_array_ref<T, 7>, > > boost::multi_array_ref<T, 8>, > > boost::multi_array_ref<T, 9> > > > bisArray_t; > > bisArray_t _bisArray; > > ... > > > > and a class bisImage, which has a bisArray as well as a pointer to the > > data as read from file (1-dimensional structure): > > ... > > > > template<typename T> > > > > class bisImage: public bisObject { > > > > public: > > > > /** Constructor using existing array data > > Reformats array as bisImage > > */ > > bisImage ( T* _data, size_t _dimensions, std::vector<size_t> _sizes > > ): > > data(_data), dimensions(_dimensions) { > > > > This code (or You) comes from java or C#, doesn't it? ;-) In C++ it is > supposed to be this->[...] instead of this.[...] No, it's C (which doesn't use any of this -not properly at least). The whole this[...] business was not supposed to be there anyway I realised. The reason that I went to boost:: is that I was hoping to get one class for all data types (using T) and dimensionalities (using multi_array) > Second thing: the member storage is initialized with the default constructor > (which in this case does not exist => error ), and then assigned (below). > > I suggest a change to: > bisImage([...]) : [...], storage( _data, _dimensions, _size ) { [...] > and remove the assignment from the body of the constructor > > Note also: I have read in many places, that you should not use names > beginning with an underscore (_), because they are reserved for > compiler/library implementation. One of those places was Herb Sutter's gotw > series. Ah! The underscore names come from a library that I tried to imitate which has successfully incorporated some aspects of boost(it is called MIMAS). Have not reached the stage of 'nicifying' the code yet... I moved the storage thing to where you suggested (1 line up) and that does get rid of lots of errors. However what I am stuck with seems to be, in essence, still the same thing: >>> /home/amwink/programs/cpp/bis/src/bisniftiimage.cpp||In function ‘void bis::bisReadNifti(std::string)’:| >>> /home/amwink/programs/cpp/bis/src/bisniftiimage.cpp|102|warning: unused variable ‘testimage’| >>> /usr/include/boost/variant/variant.hpp||In constructor ‘boost::variant<T0, T1, T2, T3, T4, T5, T6, T7, T8, T9, T10, T11, T12, T13, T14, T15, T16, T17, T18, T19>::variant() [with T0_ = boost::multi_array_ref<unsigned char, 1ul>, T1 = boost::multi_array_ref<unsigned char, 2ul>, T2 = boost::multi_array_ref<unsigned char, 3ul>, T3 = boost::multi_array_ref<unsigned char, 4ul>, T4 = boost::multi_array_ref<unsigned char, 5ul>, T5 = boost::multi_array_ref<unsigned char, 6ul>, T6 = boost::multi_array_ref<unsigned char, 7ul>, T7 = boost::multi_array_ref<unsigned char, 8ul>, T8 = boost::multi_array_ref<unsigned char, 9ul>, T9 = boost::detail::variant::void_, T10 = boost::detail::variant::void_, T11 = boost::detail::variant::void_, T12 = boost::detail::variant::void_, T13 = boost::detail::variant::void_, T14 = boost::detail::variant::void_, T15 = boost::detail::variant::void_, T16 = boost::detail::variant::void_, T17 = boost::detail::variant::void_, T18 = boost::detail::variant::void_, T19 = boost::detail::variant::void_]’:| >>> /home/amwink/programs/cpp/bis/src/bisarray.hpp|52|instantiated from ‘bis::bisArray<T>::bisArray(T*, size_t, std::vector<long unsigned int, std::allocator<long unsigned int> >) [with T = unsigned char]’| >>> /home/amwink/programs/cpp/bis/src/bisimage.hpp|33|instantiated from ‘bis::bisImage<T>::bisImage(T*, size_t, std::vector<long unsigned int, std::allocator<long unsigned int> >) [with T = unsigned char]’| >>> /home/amwink/programs/cpp/bis/src/bisniftiimage.cpp|126|instantiated from here| >>> /usr/include/boost/variant/variant.hpp|1198|error: no matching function for call to ‘boost::multi_array_ref<unsigned char, 1ul>::multi_array_ref()’| >>> /usr/include/boost/multi_array/multi_array_ref.hpp|623|note: candidates are: boost::multi_array_ref<T, NumDims>::multi_array_ref(T*, const typename boost::const_multi_array_ref<T, NumDims, T*>::storage_order_type&, const typename boost::const_multi_array_ref<T, NumDims, T*>::index*, const typename boost::const_multi_array_ref<T, NumDims, T*>::size_type*) [with T = unsigned char, long unsigned int NumDims = 1ul]| >>> /usr/include/boost/multi_array/multi_array_ref.hpp|469|note: boost::multi_array_ref<T, NumDims>::multi_array_ref(T*, const boost::detail::multi_array::extent_gen<NumDims>&, const boost::general_storage_order<NumDims>&) [with T = unsigned char, long unsigned int NumDims = 1ul]| >>> /usr/include/boost/multi_array/multi_array_ref.hpp|463|note: boost::multi_array_ref<T, NumDims>::multi_array_ref(T*, const boost::detail::multi_array::extent_gen<NumDims>&) [with T = unsigned char, long unsigned int NumDims = 1ul]| >>> /usr/include/boost/multi_array/multi_array_ref.hpp|417|note: boost::multi_array_ref<unsigned char, 1ul>::multi_array_ref(const boost::multi_array_ref<unsigned char, 1ul>&)| >>> ||=== Build finished: 1 errors, 1 warnings ===| So boost.variant now sugegsts that multi_array_ref() is called, a constructor with no arguments! I don't use that, and I don't even think it exists (because it produces a multi_array view of an *existing* C-style array! The only way I knew to initialise a bisArray was with using a switch statement -proper C: switch dims{ case 1: _bisarray=multi_array_ref<T,1> (data, sizes); break; case 2: _bisarray=multi_array_ref<T,2> (data, sizes); break; ... } That is the only way multi_array_ref is called! Any idea why a problem with the *default* constructor would turn up? Thanks for your suggestions! My error list already fits on one screen :) Alle Meije

3 3

MPFR in Boost 1.45.0
by Novak Elliott 05 Feb '11

05 Feb '11

Hi, I searched the boost mailing list archives on MPFR and the last query was in Feb 2010 so I think this may be worth a new thread. I'm interested in using MPFR (C library for multiple-precision floating-point computations with *correct rounding - *http://www.mpfr.org/) with some of the boost math libraries (vectors, matrices). Support is available to do this via the bindings in boost/math/bindings/mpfr.hpp<http://www.boost.org/doc/libs/1_45_0/boost/math/bindings/mpfr.hpp>. As per the documentation ( http://www.boost.org/doc/libs/1_45_0/libs/math/doc/sf_and_dist/html/math_to… ): "In order to use these bindings you will need to have installed MPFR plus it's dependency the GMP library and the C++ wrapper for MPFR known as gmpfrxx (or mpfr_class)." However, when compiling the example listed in the documentation: #include <boost/math/bindings/mpfr.hpp> #include <boost/math/special_functions/gamma.hpp> int main() { mpfr_class::set_dprec(500); // 500 bit precision // // Note that the argument to tgamma is an expression template, // that's just fine here: // mpfr_class v = boost::math::tgamma(sqrt(mpfr_class(2))); std::cout << std::setprecision(50) << v << std::endl; } I get a large number of compile errors (attached). I do have GMP, MPFR and gmpfrxx installed, although to get the gmpfrxx example to work (source: example.cpp) I had to comment out the reference to GMP_RND_MAX as this enumerated type value, present in MPFR version 2.4.2, has been removed from mpfr.h from version 3.0.0. Does anyone have any experience is getting boost 1.45.0 running with MPFR 3.0.0? I'm wondering whether this an MPFR problem, a boost bindings problem, or both. cheers, Novak.

3 5

[statechart]BitMachine with custom reactions. How to?
by vs＠spinke.de 03 Feb '11

03 Feb '11

Hello! I tried to add custom reactions to the statechart library example BitMachine. It shall not only change the state, but also perform some (self-defined) action on the transition. Could somebody tell me, where I have to add / change what in order to achieve the goal? Any hints are welcome. Thanks a lot. Volker

2 1

What's happened to Ryppl?
by Robert Jones 02 Feb '11

02 Feb '11

33 109

[boost.test] benchmarking support
by Marco Craveiro 01 Feb '11

01 Feb '11

hi boosters, i've been looking for benchmarking support for unit tests, but googling didn't produce any obvious results (and a wealth of spurious matches, so i may have missed something). what i have in mind is something akin to cppbench but for boost.test: http://blog.quibb.org/cppbench/ basically, something that allows repeating each test a number of times, and then time the total execution time per test. is this available? if not, can anyone recall any discussions on the subject? many thanks for your time, marco -- Constraint has encouraged not only economy, but also a certain elegance of design. -- Dennis Ritchie

3 4