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

[boost][multiprecision] compile error with gcc 4.8.4
by Rob Conde 24 Sep '16

24 Sep '16

Please see the scenario below...am I doing something wrong or is this a gcc or multiprecision bug? Thanks, Rob Conde given the following code (multiPrecisionTest.cpp): #include <boost/multiprecision/cpp_int.hpp> #include <boost/multiprecision/cpp_bin_float.hpp> typedef boost::multiprecision::int128_t int128_t; typedef boost::multiprecision::cpp_bin_float_quad float128_t; int main() { int128_t intVal; float128_t floatVal(intVal.convert_to<float128_t>()); return 0; } -------------------------------------------------------------------------- g++ -std=c++0x -c multiPrecisionTest.cpp I get the following error: In file included from ./boost/multiprecision/cpp_int.hpp:1936:0, from multiPrecisionTest.cpp:1: ./boost/multiprecision/cpp_int/misc.hpp: In instantiation of ‘typename boost::enable_if_c<(boost::multiprecision::backends::is_trivial_cpp_int<boost::multiprecision::backends::cpp_int_backend<MinBits1, MaxBits1, SignType1, Checked1, Allocator1> >::value && boost::multiprecision::is_signed_number<boost::multiprecision::backends::cpp_int_backend<MinBits1, MaxBits1, SignType1, Checked1, Allocator1> >::value)>::type boost::multiprecision::backends::eval_convert_to(R*, const boost::multiprecision::backends::cpp_int_backend<MinBits1, MaxBits1, SignType1, Checked1, Allocator1>&) [with R = boost::multiprecision::number<boost::multiprecision::backends::cpp_bin_float<113u, (boost::multiprecision::backends::digit_base_type)2u, void, short int, -16382, 16383>, (boost::multiprecision::expression_template_option)0u>; unsigned int MinBits1 = 128u; unsigned int MaxBits1 = 128u; boost::multiprecision::cpp_integer_type SignType1 = (boost::multiprecision::cpp_integer_type)1u; boost::multiprecision::cpp_int_check_type Checked1 = (boost::multiprecision::cpp_int_check_type)0u; Allocator1 = void; typename boost::enable_if_c<(boost::multiprecision::backends::is_trivial_cpp_int<boost::multiprecision::backends::cpp_int_backend<MinBits1, MaxBits1, SignType1, Checked1, Allocator1> >::value && boost::multiprecision::is_signed_number<boost::multiprecision::backends::cpp_int_backend<MinBits1, MaxBits1, SignType1, Checked1, Allocator1> >::value)>::type = void]’: ./boost/multiprecision/number.hpp:585:40: required from ‘void boost::multiprecision::number<Backend, ExpressionTemplates>::convert_to_imp(T*) const [with T = boost::multiprecision::number<boost::multiprecision::backends::cpp_bin_float<113u, (boost::multiprecision::backends::digit_base_type)2u, void, short int, -16382, 16383>, (boost::multiprecision::expression_template_option)0u>; Backend = boost::multiprecision::backends::cpp_int_backend<128u, 128u, (boost::multiprecision::cpp_integer_type)1u, (boost::multiprecision::cpp_int_check_type)0u, void>; boost::multiprecision::expression_template_option ExpressionTemplates = (boost::multiprecision::expression_template_option)0u]’ ./boost/multiprecision/number.hpp:601:29: required from ‘T boost::multiprecision::number<Backend, ExpressionTemplates>::convert_to() const [with T = boost::multiprecision::number<boost::multiprecision::backends::cpp_bin_float<113u, (boost::multiprecision::backends::digit_base_type)2u, void, short int, -16382, 16383>, (boost::multiprecision::expression_template_option)0u>; Backend = boost::multiprecision::backends::cpp_int_backend<128u, 128u, (boost::multiprecision::cpp_integer_type)1u, (boost::multiprecision::cpp_int_check_type)0u, void>; boost::multiprecision::expression_template_option ExpressionTemplates = (boost::multiprecision::expression_template_option)0u]’ multiPrecisionTest.cpp:10:54: required from here ./boost/multiprecision/cpp_int/misc.hpp:533:138: error: no type named ‘type’ in ‘struct boost::common_type<boost::multiprecision::number<boost::multiprecision::backends::cpp_bin_float<113u, (boost::multiprecision::backends::digit_base_type)2u, void, short int, -16382, 16383>, (boost::multiprecision::expression_template_option)0u>, __int128 unsigned>’ typedef typename common_type<R, typename cpp_int_backend<MinBits1, MaxBits1, SignType1, Checked1, Allocator1>::local_limb_type>::type common_type; ^

2 17

[Ranges] Range adaptors and range lifetimes
by Álex Puchades 23 Sep '16

23 Sep '16

Hi boost users! I'm having some lifetime issues with range adaptors. It seems boost adaptors (at least, transformed_range) only store iterators from the original range, letting it go out of scope [1]. Unfortunately, this makes boost adaptors not compatible with ranges that return iterators that are only valid while the original range is in scope (ie: any iterator that references the original range). This type of ranges are useful to avoid the fat-iterator problem, as seen here [2]. Is there any reason for the current behaviour? Should I file a bug or has it been discussed before? Thanks for your help [1] https://github.com/boostorg/range/blob/develop/include/boost/range/adaptor/… [2] http://ericniebler.com/2013/11/07/input-iterators-vs-input-ranges/ -- Álex Puchades

1 0

boost coroutine 1.62 b2 deprecation typo
by Jason Mancini 23 Sep '16

23 Sep '16

Just noticing that there's probably a typo in one of the deprecation warnings, as it wants both defined: BOOST_COROUTINE_NO_DEPRECATION_WARNING BOOST_COROUTINES_NO_DEPRECATION_WARNING Jason

1 0

[Parallel BGL] Poor scalability of dijkstra and delta stepping parallel graph algorithms
by Alexander Frolov 21 Sep '16

21 Sep '16

Hi! I am evaluating scalability on various graph algorithms and found that base parallel SSSP algorithms in PBGL does not scale well in my cases. The plots for rmat (scale=20 and 22) are attached. The source code for the benchmark are attached as well. The main issue that makes me think that I'm doing smth wrong is that execution time of delta stepping algorithm is _increasing_ with node number. I tried to check the code but has not found anything suspicious. Can anybody help me with this issue? Best, Alexander

1 0

[Interprocess]: using condition variables with readers-writer lock (named_sharable_mutex)
by Chris Evans 21 Sep '16

21 Sep '16

Hi, I am trying to use condition variables to signify updated data in a managed_shared_memory segment. I have one "writer" and multiple "readers" of the shared state, so I am using a readers-writer lock as follows: using SharedMutex = bi::named_sharable_mutex; using ReadLock = bi::sharable_lock<SharedMutex>; using WriteLock = bi::scoped_lock<SharedMutex>; using NewEntryCondition = bi::named_condition_any; // With a "writer" block as follows: { WriteLock w_lock( sh_mut_ ); // Update the shared memory object sh_cond_.notify_all(); } // And a "reader" block as follows (many processes call the following simultaneously): { ReadLock r_lock( sh_mut_ ); sh_cond_.wait( r_lock, []() { std::cout << "checking predicate..." << std::endl; // predicate logic goes here... }); // Access object in shared memory here } Unfortunately, although the code compiles, the reader processes are never awakened from wait() and block forever. According to the following thread from 2011: http://lists.boost.org/boost-users/2011/02/66053.php "POSIX does not support condition variables with read-write locks (although I think Windows Vista does) so Interprocess does not offer any support for this." At the time, it appears named_condition_any didn't yet exist. Has the status of this changed in the last 5 years? Is there a suggested way of implementing readers-writer locks with condition variables using boost::interprocess? Thanks! -- Chris Evans Systems Engineer Azure Summit Technology, Inc. 3050 Chain Bridge Road, Suite 600 Fairfax, VA 22030

2 2

[compute] extending meta_kernel functionality
by Oswin Krause 20 Sep '16

20 Sep '16

Hi, I am trying to use boost.compute to extend my linear algebra library to GPUs. so far it helped me a lot with vectors as i can directly use the iterator interface. Matrices are harder. for matrices i need to overload the operator matrix(i,j)-> return the element (i,j). For this i have to return an expression which then offers operator<< with meta_kernel, for example template<class T, class IndexExpr1, class IndexExpr2> inline meta_kernel& operator<<(boost::compute::detail::meta_kernel &kernel, const matrix_element_expr<T, IndexExpr1, IndexExpr2> &expr) { return kernel << kernel.get_buffer_identifier<T>(expr.m_buffer, expr.m_address_space) << '[' << expr.m_expr1 <<"*" <<expr.m_stride1<<"+"<<expr.m_expr2<< "*"<<expr.m_stride2 << ']'; } Unfortunately all of this is in namespace boost::compute::detail, making it a no-go area. Therefore two questions: 1. How stable is i?/can meta_kernel be moved into a normal namespace? 2. Is there a different way to achieve this? (Note that the code above is only an example. I could hack it in this case using the return type of buffer_iterator but not in all cases unfortunately...)

1 0

boost::context "main" stack
by Michael Steinberg 20 Sep '16

20 Sep '16

Hello, is there some way to temporarily run a function on the main stack? I played around a bit, but failed ultimately since the first stub function to be called is getting a "null" context which I assume to be only a valid "return-context". We're facing a problem where a dialog run modally inside a context runs webkit, which triggers garbage collection, which fails miserably since it assumes we're on the "native" stack. If it were possible to run something "on-top" of the main stack, this could maybe be circumvented. Thank you, Michael

2 2

Insertion/Use of boost::multi_index
by Ram 19 Sep '16

19 Sep '16

Hi All , I have created a boost::multi_index container for my use and it compiles successfully. I would like to add my pointer objects to it. boost::multi_index does not seem to have an insert method defined which just takes one arguement which is what I would like the container to store. Maybe I didnt understand how boost::multi_index is meant to be used. Can you please explain to me how to insert an object which I wish the store in the container defined? How is it intended to be used? The container I defined is , typedef boost::multi_index_ClassX< ClassX*, boost::multi_index::indexed_by< boost::multi_index::hashed_unique< boost::multi_index::const_mem_fun<ParentOfClassX, Int64, &ParentOfClassX::getKey1>, boost::multi_index::const_mem_fun<ParentOfClassX, Int64, &ParentOfClassX::getKey2>, > > > MultiIndexedClassX; I would like to do an equivalent of, MultiIndexedClassX sample; ClassX a; sample.insert(&a); <- Since I am interested in storing a *X and I would like it to be indexed by various parameters of X. Also please let me know how to, 1. Insert *X into the container 2. Look up by a) Value of ParentOfClassX::Key1 b) Value of ParentOfClassX::Key2 Please also let me know if I have some basic understanding wrong since I am getting confused a lot in trying to use boost::multi_index. Thanks in advance, Ram

2 10

Help Required, trouble while using boost::multi_index
by Ram 19 Sep '16

19 Sep '16

Hi, I am trying to create a ClassX using "boost::multi_index" and I was successfully able to create a ClassX like, typedef boost::multi_index_ClassX< ClassX*, boost::multi_index::indexed_by< boost::multi_index::hashed_unique< boost::multi_index::const_mem_fun<ParentOfClassX, Int64, &ParentOfClassX::getKey1>, boost::multi_index::const_mem_fun<ParentOfClassX, Int64, &ParentOfClassX::getKey2>, > > > MultiIndexedClassX; This compiles perfectly with no problems. I am writing the code and compiling with Visual Studio 2005 and have included, #include <boost/multi_index_container.hpp> #include "boost/multi_index/hashed_index_fwd.hpp" #include <boost/multi_index/mem_fun.hpp> and have defined namespaces, using namespace boost::multi_index; using boost::multi_index::multi_index_container; using boost::multi_index::hashed_unique; using boost::multi_index::indexed_by; But when I create an object of that type like, MultiIndexedClassX sample; I get a big list compilation errors like, *c:\code\common\lib\boost\boost\multi_index\detail\node_type.hpp(44) : error C2903: 'node_class' : symbol is neither a class template nor a function template* * c:\code\common\lib\boost\boost\mpl\aux_\preprocessed\plain\apply_wrap.hpp(49) : see reference to class template instantiation 'boost::multi_index::detail::index_node_applier::apply<IndexSpecifierIterator,Super>' being compiled* * with* * [* * IndexSpecifierIterator=boost::mpl::v_iter<boost::mpl::vector1<boost::multi_index::hashed_unique<boost::multi_index::const_mem_fun<ParentOfClassX,GKey,ParentOfClassX::getKey1>,boost::multi_index::const_mem_fun<ParentOfClassX,Vs64,ParentOfClassX::getKey2>>>,0>,* * Super=boost::multi_index::detail::index_node_base<ClassX *,std::allocator<ClassX *>>* * ]* * c:\code\common\lib\boost\boost\mpl\aux_\preprocessed\plain\bind.hpp(207) : see reference to class template instantiation 'boost::mpl::apply_wrap2<F,T1,T2>' being compiled* * with* * [* * F=boost::multi_index::detail::index_node_applier,* * T1=boost::mpl::v_iter<boost::mpl::vector1<boost::multi_index::hashed_unique<boost::multi_index::const_mem_fun<ParentOfClassX,GKey,ParentOfClassX::getKey1>,boost::multi_index::const_mem_fun<ParentOfClassX,Vs64,ParentOfClassX::getKey2>>>,0>,* * T2=boost::multi_index::detail::index_node_base<ClassX *,std::allocator<ClassX *>>* * ]* * c:\code\common\lib\boost\boost\mpl\aux_\preprocessed\plain\apply_wrap.hpp(49) : see reference to class template instantiation 'boost::mpl::bind2<F,T1,T2>::apply<U1,U2>' being compiled* * with* * [* * F=boost::multi_index::detail::index_node_applier,* * T1=boost::mpl::_2,* * T2=boost::mpl::_1,* * U1=boost::multi_index::detail::index_node_base<ClassX *,std::allocator<ClassX *>>,* * U2=boost::mpl::v_iter<boost::mpl::vector1<boost::multi_index::hashed_unique<boost::multi_index::const_mem_fun<ParentOfClassX,GKey,ParentOfClassX::getKey1>,boost::multi_index::const_mem_fun<ParentOfClassX,Vs64,ParentOfClassX::getKey2>>>,0>* * ]* * c:\code\common\lib\boost\boost\mpl\aux_\preprocessed\plain\apply.hpp(63) : see reference to class template instantiation 'boost::mpl::apply_wrap2<F,T1,T2>' being compiled* * with* * [* * F=boost::mpl::bind2<boost::multi_index::detail::index_node_applier,boost::mpl::_2,boost::mpl::_1>,* * T1=boost::multi_index::detail::index_node_base<ClassX *,std::allocator<ClassX *>>,* * T2=boost::mpl::v_iter<boost::mpl::vector1<boost::multi_index::hashed_unique<boost::multi_index::const_mem_fun<ParentOfClassX,GKey,ParentOfClassX::getKey1>,boost::multi_index::const_mem_fun<ParentOfClassX,Vs64,ParentOfClassX::getKey2>>>,0>* * ]* * c:\code\common\lib\boost\boost\mpl\aux_\preprocessed\plain\reverse_iter_fold_impl.hpp(58) : see reference to class template instantiation 'boost::mpl::apply2<F,T1,T2>' being compiled* * with* * [* * F=boost::mpl::bind2<boost::multi_index::detail::index_node_applier,boost::mpl::_2,boost::mpl::_1>,* * T1=boost::multi_index::detail::index_node_base<ClassX *,std::allocator<ClassX *>>,* * T2=boost::mpl::v_iter<boost::mpl::vector1<boost::multi_index::hashed_unique<boost::multi_index::const_mem_fun<ParentOfClassX,GKey,ParentOfClassX::getKey1>,boost::multi_index::const_mem_fun<ParentOfClassX,Vs64,ParentOfClassX::getKey2>>>,0>* * ]* Thanks, Ram

2 5

[Graph] Is there an active maintainer for Boost.Graph?
by Rohan Shah 19 Sep '16

19 Sep '16

Hi all. I'm wondering whether Boost.Graph currently has an active maintainer. I only ask because there is a fairly active github repository ( https://github.com/boostorg/graph) but it seems that important commits fail to make it into the main release on the website. For example, I would consider this (https://github.com/boostorg/graph/commit/ 8ece8fac15560cf38cf3ffbb1d56708ef8e586a2) commit to be fairly critical - Without it part of depth_first_search seems to be somewhat broken, and that's a core algorithm. And that commit is from 2014! A conversation on #boost IRC suggested I mention this problem here. Note: I am not volunteering myself to help fix this - I'm simply not qualified for it. Sorry.

1 0