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

Boost 1.60: boost::archive::iterators bug?
by Ernest Zaslavsky 02 Feb '16

02 Feb '16

Hi, Recently I've noticed that Base64 encoded data produced by implementation I use and implementation used by chromium project sometimes are not the same. It happened only once but it was enough for me to start worrying. The implementation is quite simple, and I guess borrowed it from somewhere, like SO or something. The code as following: using it_base64_t = bai::base64_from_binary<bai::transform_width<std::string::const_iterator, 6, 8>>; namespace bai = boost::archive::iterators; auto writePaddChars = (3 - input.length() % 3) % 3; std::string base64(it_base64_t(input.begin()), it_base64_t(input.end())); base64.append(writePaddChars, '='); simple and elegant. However, today I wrote a short test which takes a chapter from 'Alice's Adventures in Wonderland' and encodes it. As well, I used two different online encoder to encode the same text, both online encoders produce the same data. However above code produced the same code until character 1029 and then it is different from what it should be. Then later, it gets back to the same output as produced by online encoders. So my question is, any chance it is a bug in archive::iterators or it is something in the above code? Coliru is down, so, full code is here http://pastebin.com/JxMsMeV2 [Read More]<http://feeds.feedburner.com/~r/sizmek-blog/~6/1> [http://www.sizmek.com/Sizmek.png]<http://www.sizmek.com/>

1 0

Building Boost 1.60 with VS2015 - 32 bit compiler is always selected
by Tiago Gehring 01 Feb '16

01 Feb '16

Hi, I'm trying to build Boost 1.60 with Visual Studio 2015 Update 1 in 64-bit mode but it seems to be ignoring the address-model=64 parameter and always builds a 32-bit version (I called b2 from the VS2015 Native tools for x64 command prompt): -- C:\Users\Tiago\code\boost_1_60_0>*b2 --toolset=msvc-14.0 variant=release link=static threading=multi address-model=64 architecture=x86* Performing configuration checks *- 32-bit : yes* - arm : no - mips1 : no - power : no - sparc : no - x86 : yes .... C:\Users\Tiago\code\boost_1_60_0>*cl* Microsoft (R) C/C++ Optimizing Compiler *Version 19.00.23506 for x64* Copyright (C) Microsoft Corporation. All rights reserved. usage: cl [ option... ] filename... [ /link linkoption... ] --- I saw in some ond discussion mentions to explicitly select the compiler version (I also have VS2010 and VS2012 installed) and environment variables batch file (in the project-config.jam file) but this didn't help either. Any help is really appreciated. Best regards, Tiago Gehring

4 4

Re: [Boost-users] asio: implementing sock->receive like behavior eith async_read_some
by Bjorn Reese 01 Feb '16

01 Feb '16

On 01/28/2016 01:56 PM, Lloyd wrote: > I am using asio to read some data from SSL socket. asio tcp socket > implements a "receive" function, but ssl socket doesn't have an > implementation for "receive". In the code sample given below I wish to > implement this kind of behavior. > > eg > > { > ... > sock.async_read_some(...); > //continue the execution only after the above call finishes. > } Why are you using an asynchronous operation instead of simply calling ssl::stream::read_some()?

2 1

C++Now 2016 Registration is Open
by Jon Kalb 28 Jan '16

28 Jan '16

Boost Users, Registration is now open for this year¹s C++Now (put on by Boost). http://cppnow.org/2016-conference/announcements/2016/01/28/registration-is-o pen.html The conference has sold out the last three years and is expect to do say again this year. Do not put off registering. Note that session submitters should not register until they receive instructions from Marshall Clow, our conference registrar. See you in Aspen! Jon

1 0

asio: implementing sock->receive like behavior eith async_read_some
by Lloyd 28 Jan '16

28 Jan '16

Hi, I am using asio to read some data from SSL socket. asio tcp socket implements a "receive" function, but ssl socket doesn't have an implementation for "receive". In the code sample given below I wish to implement this kind of behavior. eg { ... sock.async_read_some(...); //continue the execution only after the above call finishes. } Whats the best way to do this? I tried "future" but the code blocks/dead locks some how, The I tried "spawn", but in this case also I don't know the method to wait for the coroutine to finish. Some tips are greatly appreciated. Thanks, Lloyd

1 0

[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