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

[Boost.LexicalCast] problem with 1.59 in Solaris
by dariomt＠gmail.com 28 Jan '16

28 Jan '16

Trying to compile file libs/date_time/src/gregorian/greg_month.cpp I get an error related to Boost.LexicalCast. I have reduced the problem to a minimal test case: #include <string> #include <boost/lexical_cast.hpp> void f(const char* s) { std::string s1(boost::lexical_cast<std::string>(s)); } My feeling is that this compiler has problems in the specializations for boost::detail::is_stdstring and boost::detail::is_char_array_to_stdstring. If I remove all those specializations the error goes away. I assume this is not the perfect solution because I guess this will miss some optimization of lexical_cast, but at least I can compile it this way :( Is there a better solution for this? Has this problem been fixed in 1.60? Error message (full instantiation stack available if needed): "/ThirdPartyLibs/boost/1_59_0/boost/lexical_cast/try_lexical_convert.hpp", line 146: Error: Ambiguous partial specialization for boost::detail::is_char_array_to_stdstring<std::string, const char*>, boost::detail::is_char_array_to_stdstring<boost::container::basic_string<boost::detail::CharT, boost::detail::Traits, boost::detail::Alloc>, const boost::detail::CharT*> and boost::detail::is_char_array_to_stdstring<std::basic_string<boost::detail::CharT, boost::detail::Traits, boost::detail::Alloc>, const boost::detail::CharT*>. "/ThirdPartyLibs/boost/1_59_0/boost/lexical_cast.hpp", line 42: Where: While instantiating "boost::conversion::detail::try_lexical_convert<std::string, const char*>(const char*const&, std::string &)". "/ThirdPartyLibs/boost/1_59_0/boost/lexical_cast/try_lexical_convert.hpp", line 134: Error: Ambiguous partial specialization for boost::detail::is_stdstring<std::string>, boost::detail::is_stdstring<boost::container::basic_string<boost::detail::CharT, boost::detail::Traits, boost::detail::Alloc>> and boost::detail::is_stdstring<std::basic_string<boost::detail::CharT, boost::detail::Traits, boost::detail::Alloc>>. "/ThirdPartyLibs/boost/1_59_0/boost/lexical_cast.hpp", line 42: Where: While instantiating "boost::conversion::detail::try_lexical_convert<std::string, const char*>(const char*const&, std::string &)".

5 9

Regression with boost::python 1.60
by Emmanuel 28 Jan '16

28 Jan '16

Hello, I am not sure if this is the right place to do it, but I will try :-). I am having a regression in boost 1.60, I documented a small reproducer here: http://stackoverflow.com/questions/35056398/typeerror-when-iterating-over-a… Does anyone have a clue ? Cheers, Emmanuel

1 0

[Odeint] Stiff System of differential equations
by jules 25 Jan '16

25 Jan '16

Hi all, I am currently working with a very large set of differential equations; it is a disease model with 20160 classes depending on which vaccine has been admnistered, history of infection, and age. To solve this I have been using the runge_kutta_fehlber78 controlled stepper with the integrate_const function. There I need to set the absolute_error, relative_error and the step_size. My issue is that the results from the solver seems to depend highly on the step_size and whether or not an observer is provided. Since the solver is adaptive I feel like the results should not depend on step_size and they should definitely not depend on the presence of an observer. My question is why would the results be related to the step_size or the observer? How would it be possible to get the same results regardless of the step_size and the presence of an observer? Could this be related to the system being stiff and if so how would it be possible to solve it (The jacobian is too complicated to calculate because of the population dynamics)? Any help would be appreciated. Many thanks, Jules

3 5

BGL, shortest path between two nearby nodes in a huge graph
by Paolo Bolzoni 25 Jan '16

25 Jan '16

Dear list, I am a happy user of BGL, but recently I got stuck in a strange problem. I think I am missing the obvious, so I'll be happy to read the fine manual if it's the case. Just point me to the right direction. I need to find the shortest path between two nodes, for doing so I am using dijkstra with a custom visitor that stops the search (throwing an exception) when examine_vertex is called on the destination node. It worked fine, but it run strangely slow. After some profiling, it is clear that most of the time is used in the initialize_vertex function. The graph is fairly large, but the path I am looking for are fairly small (10 edges tops usually). It is possible to skip the initialize phase? Cheers, Paolo

3 5

Some help for betweenness centrality for undirected weighted graph
by Xinran Wang 25 Jan '16

25 Jan '16

Hi everyone, this is from Jason. I am a new user of Boost library. Nowadays, I am doing a research about betweenness centrality measure. I am very confused about how to use boost to calculate the betweenness centrality. I need to calculate the centrality score based on a undirected and weighted graph. The following code is what I tried to do. But this block of code can only be used for calculated for unweighted graph. Could anyone here can offer me examples? Thanks for any reply. #include <boost/graph/betweenness_centrality.hpp> #include <boost/graph/adjacency_list.hpp> #include <boost/graph/graphviz.hpp> typedef boost::property<boost::edge_weight_t, float> EdgeWeightProperty; typedef boost::adjacency_list < boost::listS, boost::vecS, boost::undirectedS, boost::no_property, EdgeWeightProperty > Graph; typedef boost::graph_traits < Graph >::vertex_descriptor vertex_descriptor; typedef boost::graph_traits < Graph >::edge_descriptor edge_descriptor; typedef std::pair<int, int> Edge; typedef std::map<Edge, int> StdEdgeIndexMap; void betweennessCentrality() { Graph g; Graph::vertex_descriptor a1 = boost::add_vertex(g); Graph::vertex_descriptor a2 = boost::add_vertex(g); Graph::vertex_descriptor a3 = boost::add_vertex(g); Graph::vertex_descriptor a4 = boost::add_vertex(g); Graph::vertex_descriptor a5 = boost::add_vertex(g); Graph::vertex_descriptor a6 = boost::add_vertex(g); Graph::vertex_descriptor a7 = boost::add_vertex(g); EdgeWeightProperty weight0 = 1; boost::add_edge(a1, a2, weight0, g); EdgeWeightProperty weight1 = 1; boost::add_edge(a1, a3, weight1, g); EdgeWeightProperty weight2 = 1; boost::add_edge(a2, a3, weight2, g); EdgeWeightProperty weight3 = 1; boost::add_edge(a3, a4, weight3, g); EdgeWeightProperty weight4 = 1; boost::add_edge(a4, a5, weight4, g); EdgeWeightProperty weight5 = 1; boost::add_edge(a5, a6, weight5, g); EdgeWeightProperty weight6 = 1; boost::add_edge(a5, a7, weight6, g); EdgeWeightProperty weight7 = 1; boost::add_edge(a6, a7, weight7, g); typedef boost::property_map< Graph, boost::vertex_index_t>::type VertexIndexMap; VertexIndexMap v_index = get(boost::vertex_index, g); std::vector< double > v_centrality_vec(boost::num_vertices(g), 0.0); boost::iterator_property_map< std::vector< double >::iterator, VertexIndexMap > v_centrality_map(v_centrality_vec.begin(), v_index); brandes_betweenness_centrality( g, v_centrality_map); }

1 0

[math/stat] generating t-distributed random numbers
by U.Mutlu 22 Jan '16

22 Jan '16

Hi, I've an old code that creates a normal-distributed random number between 0 and 1 (by using the polar method). Is it possible to convert this number to a t-distributed number (with v=5) using boost? Or, alternatively: how to generate t-distributed random numbers in the range 0 to 1 with v=5 (ie. degrees of freedom = 5) in boost?

1 1

[fusion] [mpl] binary MPL transform on empty fusion vectors
by Nathan Ridge 22 Jan '16

22 Jan '16

Hi, I've run into an error in code involving MPL and Fusion which I've reduced to the following: #include <boost/mpl/transform.hpp> #include <boost/fusion/container/vector.hpp> #include <boost/fusion/mpl.hpp> struct predicate { template <typename T, typename U> struct apply { typedef T type; }; }; typedef boost::mpl::transform< boost::fusion::vector<>, boost::fusion::vector<>, predicate> ::type Result; This simple piece of code tries to perform a binary MPL transform on two fusion vectors of size 0. It produces the error reproduced below, with both gcc 5.1 and clang 3.7. My boost version is 1.60. I'm quite sure that this used to work with an older boost and compiler version combination, though I don't recall which exactly (something in the vicinity of boost 1.54 / gcc 4.8). Did I run into a regression, or should I not be expecting this to work in the first place? Should I be special-casing zero-length vectors? Thanks, Nate In file included from test.cpp:2: In file included from boost/include/boost/fusion/container/vector.hpp:12: In file included from boost/include/boost/fusion/container/vector/vector.hpp:28: In file included from boost/include/boost/fusion/container/vector/detail/at_impl.hpp:12: boost/include/boost/fusion/container/vector/detail/value_at_impl.hpp:50:57: error: no matching function for call to 'value_at_impl' typedef typename mpl::identity<decltype(seq::template value_at_impl<N::value>(boost::declval<seq*>()))>::type::type type; ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ boost/include/boost/fusion/container/vector/detail/value_of_impl.hpp:30:61: note: in instantiation of template class 'boost::fusion::extension::value_at_impl<boost::fusion::vector_tag>::apply<boost::fusion::vector<>, mpl_::int_<0>>' requested here typedef typename value_at_impl<vector_tag>::template apply<vector, index>::type type; ^ boost/include/boost/fusion/iterator/value_of.hpp:52:15: note: in instantiation of template class 'boost::fusion::extension::value_of_impl<boost::fusion::vector_iterator_tag>::apply<boost::fusion::vector_iterator<boost::fusion::vector<>, 0>>' requested here : extension::value_of_impl<typename detail::tag_of<Iterator>::type>:: ^ boost/include/boost/fusion/iterator/mpl/fusion_iterator.hpp:47:45: note: in instantiation of template class 'boost::fusion::result_of::value_of<boost::fusion::vector_iterator<boost::fusion::vector<>, 0>>' requested here typedef typename fusion::result_of::value_of<Iterator>::type type; ^ boost/include/boost/mpl/iterator_category.hpp:27:22: note: in instantiation of template class 'boost::mpl::fusion_iterator<boost::fusion::vector_iterator<boost::fusion::vector<>, 0>>' requested here typedef typename Iterator::category type; ^ boost/include/boost/mpl/pair_view.hpp:152:20: note: in instantiation of template class 'boost::mpl::iterator_category<boost::mpl::fusion_iterator<boost::fusion::vector_iterator<boost::fusion::vector<>, 0>>>' requested here typename iterator_category<iter1_>::type ^ boost/include/boost/mpl/aux_/has_tag.hpp:20:1: note: in instantiation of template class 'boost::mpl::pair_view<boost::fusion::vector<>, boost::fusion::vector<>>' requested here BOOST_MPL_HAS_XXX_TRAIT_NAMED_DEF(has_tag, tag, false) ^ boost/include/boost/mpl/has_xxx.hpp:245:65: note: expanded from macro 'BOOST_MPL_HAS_XXX_TRAIT_NAMED_DEF' , boost::mpl::aux::type_wrapper<BOOST_MSVC_TYPENAME U::name>* = 0 \ ^ boost/include/boost/mpl/aux_/has_tag.hpp:20:1: note: while substituting deduced template arguments into function template 'test' [with U = boost::mpl::pair_view<boost::fusion::vector<>, boost::fusion::vector<>>] BOOST_MPL_HAS_XXX_TRAIT_NAMED_DEF(has_tag, tag, false) ^ boost/include/boost/mpl/has_xxx.hpp:253:18: note: expanded from macro 'BOOST_MPL_HAS_XXX_TRAIT_NAMED_DEF' sizeof(gcc_3_2_wknd::test(static_cast<t_*>(0))) \ ^ boost/include/boost/config/suffix.hpp:394:72: note: expanded from macro 'BOOST_STATIC_CONSTANT' # define BOOST_STATIC_CONSTANT(type, assignment) static const type assignment ^ boost/include/boost/mpl/sequence_tag.hpp:112:30: note: in instantiation of template class 'boost::mpl::aux::has_tag<boost::mpl::pair_view<boost::fusion::vector<>, boost::fusion::vector<>>, mpl_::bool_<false>>' requested here ::boost::mpl::aux::has_tag<Sequence>::value ^ boost/include/boost/mpl/O1_size.hpp:30:30: note: in instantiation of template class 'boost::mpl::sequence_tag<boost::mpl::pair_view<boost::fusion::vector<>, boost::fusion::vector<>>>' requested here : O1_size_impl< typename sequence_tag<Sequence>::type> ^ boost/include/boost/mpl/fold.hpp:34:25: note: in instantiation of template class 'boost::mpl::O1_size<boost::mpl::pair_view<boost::fusion::vector<>, boost::fusion::vector<>>>' requested here ::boost::mpl::O1_size<Sequence>::value ^ boost/include/boost/mpl/transform.hpp:75:7: note: in instantiation of template class 'boost::mpl::fold<boost::mpl::pair_view<boost::fusion::vector<>, boost::fusion::vector<>>, boost::fusion::vector<>, boost::mpl::bind2<boost::mpl::push_back<mpl_::na, mpl_::na>, mpl_::arg<1>, boost::mpl::bind2<predicate, boost::mpl::bind1<boost::mpl::first<mpl_::na>, mpl_::arg<2>>, boost::mpl::bind1<boost::mpl::second<mpl_::na>, mpl_::arg<2>>>>>' requested here : fold< ^ boost/include/boost/mpl/transform.hpp:114:1: note: in instantiation of template class 'boost::mpl::aux::transform2_impl<boost::fusion::vector<>, boost::fusion::vector<>, predicate, boost::mpl::back_inserter<boost::fusion::vector<>>>' requested here BOOST_MPL_AUX_INSERTER_ALGORITHM_DEF(4, transform2) ^ boost/include/boost/mpl/aux_/inserter_algorithm.hpp:52:7: note: expanded from macro 'BOOST_MPL_AUX_INSERTER_ALGORITHM_DEF' : if_< has_push_back< typename clear<P1>::type> \ ^ boost/include/boost/mpl/eval_if.hpp:38:22: note: in instantiation of template class 'boost::mpl::transform2<boost::fusion::vector<>, boost::fusion::vector<>, predicate, mpl_::na>' requested here typedef typename f_::type type; ^ boost/include/boost/mpl/transform.hpp:138:1: note: in instantiation of template class 'boost::mpl::eval_if<boost::mpl::or_<boost::mpl::is_na<predicate>, boost::mpl::is_lambda_expression<boost::fusion::vector<>>, boost::mpl::not_<boost::mpl::is_sequence<boost::fusion::vector<>>>, mpl_::bool_<false>, mpl_::bool_<false>>, boost::mpl::transform1<boost::fusion::vector<>, boost::fusion::vector<>, predicate>, boost::mpl::transform2<boost::fusion::vector<>, boost::fusion::vector<>, predicate, mpl_::na>>' requested here AUX778076_TRANSFORM_DEF(transform) ^ boost/include/boost/mpl/transform.hpp:125:22: note: expanded from macro 'AUX778076_TRANSFORM_DEF' typedef typename eval_if< \ ^ test.cpp:13:17: note: in instantiation of template class 'boost::mpl::transform<boost::fusion::vector<>, boost::fusion::vector<>, predicate, mpl_::na>' requested here boost::mpl::transform< ^ boost/include/boost/fusion/container/vector/vector.hpp:275:30: note: candidate template ignored: could not match 'store' against 'vector' mpl::identity<U> value_at_impl(store<N, U>*); ^

2 2

Boost Log: Use of operator<<
by Florian Lindner 21 Jan '16

21 Jan '16

Hello, I want to put a custom object called DynamicVector on the BOOG_LOG_SEV stream. For that I defined an operator<< template<typename Vector> typename std::enable_if<tarch::la::IsVector<Vector>::value, std::ostream&>::Type operator<< (std::ostream & os, const Vector & vector); IsVector<Vector> will be true, since template<typename Scalar> struct IsVector<DynamicVector<Scalar> > { static const int value = true; }; The operator itself is working: // getCoords returns a DynamicVector<double> std::cout << inMesh->vertices()[j].getCoords(); // compiles just fine. but BOOST_LOG_SEV(_log, boost::log::trivial::severity_level::error) << inMesh->vertices()[j].getCoords(); gives an compile error: /usr/include/boost/log/utility/formatting_ostream.hpp:799:19: error: invalid operands to binary expression ('ostream_type' (aka 'basic_ostream<char_type, traits_type>') and 'const tarch::la::DynamicVector<double>') strm.stream() << value; str.stream() seems to be an ostream_type which is an basic_ostream<char_type, traits_type>. I wonder why this isn't convertible to std::ostream, like http://stackoverflow.com/questions/17269499/overloading-operator-for-boost-… and the comment at http://www.boost.org/doc/libs/1_54_0/boost/log/utility/formatting_ostream.h… suggest. Any help appreciated! Thanks, Florian

1 0

Re: [Boost-users] [boost] Boost.Operators issue: polluting namespace of caller through argument-dependent lookup
by John M. Dlugosz 21 Jan '16

21 Jan '16

On 1/20/2016 10:41 AM, Daniel Frey wrote: > In a way it makes library collections like Boost harder and I still think you should use > qualified lookup in your specific case, No, I specifically don't want to qualify every use, as explained originally. The code needs compatibility with some configurations that require the tr1 namespace and others that prohibit it. Qualifying every reference is bad; rather, import them in one place. You are basically saying that `using N::foo;` is never right because someone may happen to use the name foo in an unrelated library and ADL is a misfeature? I think that doesn't scale. It should be SOP to isolate classes that are meant to be used as base classes by library consumers, and treat unqualified lookup of names pulled in to the local scope via `using` as something that is a useful feature that ought to work. > but as I already said in another mail I’m willing to fix it. I just need to figure out > where to commit and merge stuff as the last time I worked on it we were still using svn > and the branching model was different. I hope to be able to find the time somewhere in > the next days. Regards, Daniel Looking forward to it in 1.62 or whatever. Thanks! —John

1 0

[locale] boost::locale::format number formatting on OS X and Windows
by Michael Smith 21 Jan '16

21 Jan '16

Using Boost.Locale from Boost 1.60.0 (installed via homebrew, so it uses icu) on Mac OS X 10.11.2, I seem to be getting unexpected behavior for some of the boost::format number formatting. A short example program #include <boost/locale.hpp> int main(int argc, char** argv) { boost::locale::format fmt("{1,number} should be 1,25."); fmt % 1.25; boost::locale::generator gen; std::cout << fmt.str(gen("fr-fr.UTF-8")) << std::endl; return 0; } That produces 1,25 on Linux, and 1.25 on Windows (using mingw-w64) and Mac. Any idea why they'd represent it differently?

1 0