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

[ANN] Registration for CppCon 2014 is Open
by Boris Kolpackov 18 Mar '14

18 Mar '14

CppCon, The C++ Conference Opening Keynote by Bjarne Stroustrup September 7–12, 2014 Bellevue, Washington, USA Registration is now open for CppCon 2014 to be held September 7–12, 2014 at the Meydenbauer Center in Bellevue, Washington, USA. This year the conference starts with the keynote by Bjarne Stroustrup titled "Make Simple Tasks Simple!" CppCon is the annual, week-long face-to-face gathering for the entire C++ community. The conference is organized by the C++ community for the community. You will enjoy inspirational talks and a friendly atmosphere designed to help attendees learn from each other, meet interesting people, and generally have a stimulating experience. Taking place this year in the beautiful Seattle neighborhood and including multiple diverse tracks, the conference will appeal to anyone from C++ novices to experts. What you can expect at CppCon: * Invited talks and panels: CppCon keynote by Bjarne Stroustrup will start off a week full of insight from some of the world’s leading experts in C++. Still have questions? Ask them at one of CppCon's panels featuring those at the cutting edge of the language. * Presentations by the C++ community: What do embedded systems, game development, high frequency trading, and particle accelerators have in common? C++, of course! Expect talks from a broad range of domains focused on practical C++ techniques, libraries, and tools. * Lightning talks: Get informed at a fast pace during special sessions of short, informal talks. Never presented at a conference before? This is your chance to share your thoughts on a C++-related topic in an informal setting. * Evening events and "unconference" time: Relax, socialize, or start an impromptu coding session. CppCon’s goal is to encourage the best use of C++ while preserving the diversity of viewpoints and experiences, but other than that it is non-partisan and has no agenda. The conference is a project of the Standard C++ Foundation, a not-for-profit organization whose purpose is to support the C++ software developer community and promote the understanding and use of modern, standard C++ on all compilers and platforms. For more information about the conference and to register, visit: http://cppcon.org

1 0

[Boost.polygon.voronoi] [Boost.multiprecision] higher precision voronoi
by Weatherby,Gerard 17 Mar '14

17 Mar '14

I'm attempting to following the http://www.boost.org/doc/libs/1_53_0_beta1/libs/polygon/doc/voronoi_advance… to compile boost::polygon::voronoi using 64 bit integer input. I'm using the boost::multiprecision library to do so. Using boost version 1.53 and Microsoft Visual Studio 2012. The error message is: 1>d:\workspace\movingboundary\boost_1_53_0\boost\polygon\detail\voronoi_robust_fpt.hpp(60): error C2665: 'sqrt' : none of the 3 overloads could convert all the argument types 1> C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\include\math.h(588): could be 'long double sqrt(long double)' 1> C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\include\math.h(540): or 'float sqrt(float)' 1> C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\include\math.h(127): or 'double sqrt(double)' 1> while trying to match the argument list '(const boost::multiprecision::detail::expression<tag,Arg1,Arg2,Arg3,Arg4>)' 1> with 1> [ 1> tag=boost::multiprecision::detail::multiplies, 1> Arg1=boost::multiprecision::detail::expression<boost::multiprecision::detail::multiplies,boost::multiprecision::detail::expression<boost::multiprecision::detail::plus,boost::multiprecision::detail::expression<boost::multiprecision::detail::multiply_immediates,boost::multiprecision::number<boost::multiprecision::backends::cpp_dec_float<48>>,boost::multiprecision::number<boost::multiprecision::backends::cpp_dec_float<48>>,void,void>,boost::multiprecision::detail::expression<boost::multiprecision::detail::multiply_immediates,boost::multiprecision::number<boost::multiprecision::backends::cpp_dec_float<48>>,boost::multiprecision::number<boost::multiprecision::backends::cpp_dec_float<48>>,void,void>,void,void>,boost::multiprecision::detail::expression<boost::multiprecision::detail::plus,boost::multiprecision::detail::expression<boost::multiprecision::detail::multiply_immediates,boost::multiprecision::number<boost::multiprecision::backends::cpp_dec_float<48>>,boost::multiprecision::number<boost::multiprecision::backends::cpp_dec_float<48>>,void,void>,boost::multiprecision::detail::expression<boost::multiprecision::detail::multiply_immediates,boost::multiprecision::number<boost::multiprecision::backends::cpp_dec_float<48>>,boost::multiprecision::number<boost::multiprecision::backends::cpp_dec_float<48>>,void,void>,void,void>,void,void>, 1> Arg2=boost::multiprecision::detail::expression<boost::multiprecision::detail::plus,boost::multiprecision::detail::expression<boost::multiprecision::detail::multiply_immediates,boost::multiprecision::number<boost::multiprecision::backends::cpp_dec_float<48>>,boost::multiprecision::number<boost::multiprecision::backends::cpp_dec_float<48>>,void,void>,boost::multiprecision::detail::expression<boost::multiprecision::detail::multiply_immediates,boost::multiprecision::number<boost::multiprecision::backends::cpp_dec_float<48>>,boost::multiprecision::number<boost::multiprecision::backends::cpp_dec_float<48>>,void,void>,void,void>, 1> Arg3=void, 1> Arg4=void == reference line is template <typename T> T get_sqrt(const T& that) { return (std::sqrt)(that); //<-- line 60 } == code == #pragma warning (disable: 4996 4267) #include <cmath> #include <boost/multiprecision/cpp_int.hpp> #include <boost/multiprecision/cpp_dec_float.hpp> #include <boost/polygon/voronoi.hpp> #include <limits> #include <gtest/gtest.h> #include <iostream> using namespace boost::polygon; namespace vcellVoronoiImpl { typedef boost::multiprecision::number<boost::multiprecision::cpp_dec_float<48>> floatingType; struct FloatingConverter { template <typename T> floatingType operator( )(T x) const { return static_cast<floatingType>(x); } }; struct compareFloatingType { enum Result { LESS = -1, EQUAL = 0, MORE = 1 }; Result operator()(floatingType a, floatingType b, unsigned int maxUlps) const { if (a > b) { return a - b <= maxUlps ? EQUAL : LESS; } return b - a <= maxUlps ? EQUAL : MORE; } }; struct voronoi_ctype_traits { typedef boost::int64_t int_type; typedef boost::multiprecision::int128_t int_x2_type; typedef boost::multiprecision::uint128_t uint_x2_type; typedef boost::multiprecision::int512_t big_int_type; typedef floatingType fpt_type; typedef floatingType efpt_type; typedef compareFloatingType ulp_cmp_type; typedef FloatingConverter to_fpt_converter_type; typedef FloatingConverter to_efpt_converter_type; }; struct vcell_vd_traits{ typedef voronoi_ctype_traits::fpt_type coordinate_type; typedef voronoi_cell<coordinate_type> cell_type; typedef voronoi_vertex<coordinate_type> vertex_type; typedef voronoi_edge<coordinate_type> edge_type; typedef struct { public: enum { ULPS = 128 }; bool operator()(const vertex_type &v1, const vertex_type &v2) const { return (ulp_cmp(v1.x(), v2.x(), ULPS) == compareFloatingType::EQUAL && ulp_cmp(v1.y(), v2.y(), ULPS) == compareFloatingType::EQUAL); } private: compareFloatingType ulp_cmp; } vertex_equality_predicate_type; }; } using namespace vcellVoronoiImpl; TEST(highv,build) { voronoi_builder<boost::int64_t, vcellVoronoiImpl::voronoi_ctype_traits> vb; voronoi_diagram<boost::int64_t,vcell_vd_traits> vd; vb.construct(&vd); } Gerard Weatherby Appllication Architect Virtual Cell, Center for Cell Analysis and Modeling (CCAM) University of Connecticut Health Center 860-679-2065

3 4

Re: [Boost-users] boost::geometry::index::rtree with CoordinateSystem
by Ola Martin Lykkja 16 Mar '14

16 Mar '14

>> Hi, >> >> I am trying to build a rtree index with a collection of waypoint >> (about 30.000) each represented by longitude and latitude. When I use >> Cartesian coordinates rtree.query works as expected. However the >> results are slightly wrong because of my use of longitude,latitude in >> the cartesian domain. >> >> I then tried to refine the datatypes to use spherical_equatorial and >> geographic CoordinateSystem. Now I encounter two problems: >> a)With geographic, it does not compile. >> b)With spherical_equatorial query(nearest) gives clearly wrong results. >> >> Do you have any clues on what I am doing wrong? > >Everything you're doing is ok. > >The support for coordinate systems other than cartesian is limited for now. As you noticed the nearest query gives >wrong results. Also the internal structure of the rtree may be not-optimal. At least the nearest query for spherical >CS should be fixed in upcoming Boost 1.56. Do you need some quick workaround? > >As for geographic CS, it fails to compile because the default distance strategy isn't defined for this CS. It >probable that distance() is just not implemented yet for geographic CS but I must confirm it. > >Could you please create tickets for those issues? > >Regards, >Adam First: I am pretty impressed with the index::rtree template. It is *VERY* useful in my current project! Thanks for your reply! For my application, I am ok, for the moment, with the relatively small errors that using the cartesian domain gives me. I have created two tickets (9758 and 9759) What is the difference between spherical_equatorial and geographic and spherical? The documentation is rather unclear. Kind regards, Ola Martin

2 1

[multi-array] Is default initialization guaranteed?
by Eugenio Bargiacchi 15 Mar '14

15 Mar '14

Hello, I'm trying to figure out whether boost::multi_array does guarantee any initialization on its elements, since I can't find an explicit mention of this in the docs. I've noticed that all constructors of boost_multi array call the function allocate_space(), which is defined as follows: void allocate_space() { typename Allocator::const_pointer no_hint=0; base_ = allocator_.allocate(this->num_elements(),no_hint); this->set_base_ptr(base_); allocated_elements_ = this->num_elements(); std::uninitialized_fill_n(base_,allocated_elements_,T()); } Thus, std::uninitialized_fill_n should set all values to their default ones, right? For example, a boost::multi_array containing doubles is guaranteed to be zeroed at constructions, am I correct? Or are there cases where there's no guarantee of initialization, and that is why the documentation does not mention it? Thanks in advance. Best regards, Eugenio Bargiacchi

1 0

Boost Log
by Manuel Torres 14 Mar '14

14 Mar '14

Hello, I am using Boost Log 1.55 with MinGW 32-bits (GCC v.4.8.1) under Windows 7 64-bits and it seems that the "AutoFlush" parameter is not working when a settings file is used. I thought it might have to do with the "Asynchronous" parameter but, after setting four sinks with the combinations of "AutoFlush" and "Asynchronous", I got the same result: the log files are only created after the application is closed. I would appreciate if someone could help. This is the settings file I am testing with: [Core] DisableLogging=false Filter="%Severity% < 6" [Sinks.ConsoleSink] Destination=Console Format="[%TimeStamp%] <%Severity%> %Channel%: %Message%" Asynchronous=true AutoFlush=true [Sinks.TextFileSink0] Destination=TextFile FileName="0_%Y%m%d%H%M%S_Node_%N.log" Format="[%TimeStamp%] <%Severity%> %Channel%: %Message%" Asynchronous=true AutoFlush=true Target="../log" RotationSize=1000000 RotationTimePoint="00:00:00" MaxSize=10000000 [Sinks.TextFileSink1] Destination=TextFile FileName="1_%Y%m%d%H%M%S_Node_%N.log" Format="[%TimeStamp%] <%Severity%> %Channel%: %Message%" Asynchronous=true AutoFlush=false Target="../log" RotationSize=1000000 RotationTimePoint="00:00:00" MaxSize=10000000 [Sinks.TextFileSink2] Destination=TextFile FileName="2_%Y%m%d%H%M%S_Node_%N.log" Format="[%TimeStamp%] <%Severity%> %Channel%: %Message%" Asynchronous=false AutoFlush=true Target="../log" RotationSize=1000000 RotationTimePoint="00:00:00" MaxSize=10000000 [Sinks.TextFileSink3] Destination=TextFile FileName="3_%Y%m%d%H%M%S_Node_%N.log" Format="[%TimeStamp%] <%Severity%> %Channel%: %Message%" Asynchronous=false AutoFlush=false Target="../log" RotationSize=1000000 RotationTimePoint="00:00:00" MaxSize=10000000

2 2

[asio] resolver::cancel() problem
by Matthew Edwards 14 Mar '14

14 Mar '14

In my application (and a separate test program) it seems as though the cancel() function on the resolver does not work as intended. For async resolves, the cancel functionality should abort them immediately and pass an 'operation aborted' error code to the callback handler. In my tests, I will resolve an invalid domain (this causes the resolve to take a few seconds, to demonstrate the problem), sleep for 100ms, then call cancel on the resolver object. No cancelling actually occurs, and the callback is simply triggered after a few seconds with a "No host found" error code, not the expected operation aborted. Has anyone experienced this before, or know how I might be using the resolver incorrectly?

3 2

[Graph] Guarantee on bidirectional graphs
by Sensei 14 Mar '14

14 Mar '14

Dear all, I am implementing my custom algorithm for path discovery (as in a recent post), and I'd like to know one simple thing. My graph is a bidirectional sparse compressed row graph, and I need to represent a *directed* graph with that (I need in and out edges). So, is the order of nodes in an edge guaranteed to generate the correct in/out adjacent nodes? I do not care about ordering of nodes, just distinguishing nodes that belong to in and out edges. For instance, given a directed graph that has node 4 with two out edges to 5 and 6, and 4 in edges from 1, 2, and 3, am I guaranteed that, even if the graph is bidirectional, the in and out edges will be unaffected and won't be swapped? Moreover, when I dump the indices of out edges, the results seem to be right, but when I dump the in edges, results are erroneous. I must be doing something really wrong... And one more thing: I have tried my code with just using the stream output as in http://programmingexamples.net/wiki/CPP/Boost/BGL/DirectedGraph, just using std::cout << neighbors_out.first << std::endl; clang complains: main.cpp:165:19: error: invalid operands to binary expression ('ostream' (aka 'basic_ostream<char>') and 'boost::detail::csr_out_edge_iterator<boost::compressed_sparse_row_graph<boost::bidirectionalS, boost::no_property, boost::no_property, boost::no_property, unsigned long, unsigned long> >') std::cout << neighbors_out.first << std::endl; ~~~~~~~~~ ^ ~~~~~~~~~~~~~~~~~~~ while if I use the following, it compiles just fine (but as I said, the output is wrong): std::cout << neighbors_out.first->idx << std::endl; See the snippet for an example. Thanks & Cheers! typedef boost::compressed_sparse_row_graph<boost::bidirectionalS> boost_graph; typedef boost::graph_traits<boost_graph>::vertex_iterator vertex_iterator; typedef boost::graph_traits<boost_graph>::adjacency_iterator adjacency_iterator; typedef boost::graph_traits<boost_graph>::out_edge_iterator outward_iterator; typedef boost::graph_traits<boost_graph>::in_edge_iterator inward_iterator; // ... std::vector<std::pair<std::size_t, std::size_t>> results; results.push_back(std::make_pair( 0, 1)); results.push_back(std::make_pair( 0, 3)); results.push_back(std::make_pair( 1, 4)); results.push_back(std::make_pair( 2, 4)); results.push_back(std::make_pair( 3, 4)); results.push_back(std::make_pair( 4, 5)); results.push_back(std::make_pair( 4, 6)); results.push_back(std::make_pair( 5, 7)); results.push_back(std::make_pair( 7, 8)); results.push_back(std::make_pair( 8, 9)); results.push_back(std::make_pair( 8, 11)); results.push_back(std::make_pair( 8, 12)); results.push_back(std::make_pair( 9, 10)); results.push_back(std::make_pair(12, 10)); // Create the graph boost_graph graph(boost::edges_are_unsorted_multi_pass, results.begin(), results.end(), 13); std::cout << "Outward adjacents" << std::endl; std::pair<outward_iterator, outward_iterator> neighbors_out; neighbors_out = boost::out_edges(boost::vertex(4, graph), graph); for(; neighbors_out.first != neighbors_out.second; ++neighbors_out.first) { std::cout << neighbors_out.first->idx << std::endl; } std::cout << "Inward adjacents" << std::endl; std::pair<inward_iterator, inward_iterator> neighbors_in; neighbors_in = boost::in_edges(boost::vertex(4, graph), graph); for(; neighbors_in.first != neighbors_in.second; ++neighbors_in.first) { std::cout << neighbors_in.first->idx << std::endl; } == OUTPUT == Outward adjacents 5 6 Inward adjacents 2 3 4

2 4

cpp_rational memory bloat with repeated construction and destruction
by W Randolph Franklin 14 Mar '14

14 Mar '14

Hi, My application, overlay, constructs and destroys millions of cpp_rational variables. As overlay executes, its memory continually grows. My variables don't have that many digits, but each time that they are constructed or destroyed, they are slightly wider or narrower. W/o studying the cpp_rational source, I surmise that it uses a heap that gets badly fragmented. Apart from the space, each single allocation is probably taking ever more time. That's annoying because overlay otherwise would take linear time. What should I do? Are there easy ways to control this problem? Are other rational implementations better? Boost gives me a choice of several. Are there better implementations outside boost? ----- Not that it's relevant, but FYI, my application is to overlay two planar graphs, intersecting all the edges to find the output faces. There might be 100,000 edges. Roundoff error is a serious problem that causes topological impossibilities. The idea is to use rationals to prevent roundoff. Upon reading each input float, I use a continued fraction approximation to convert it to the closest rational justified by the number of significant digits. That entails constructing and destroying variables of varying widths as the approximation converges. This is probably what is thrashing the memory. However if I don't do that, the values start by having perhaps 20 digits, which doubles each time as line equations are computed and lines intersected. Perhaps I could restructure my code to avoid that. However IMHO, it is quite well structured now, and making it ugly to be fast would be a pity. Help? Thanks.

2 1

Indirectly 'recursive' type erasure
by Samuel Christie 13 Mar '14

13 Mar '14

I'm trying to create a type erasure concept for a type that has a member function which can return a custom collection of itself. Having had little luck with the general formulation, I tried simplifying it to: BOOST_TYPE_ERASURE_MEMBER((has_collection), collection, 0); typedef any< mpl::vector< copy_constructible<>, typeid_<>, relaxed, has_collection<vector<_self>()> > > test; class Test { public: vector<test> collection(); }; However, I get conversion errors if the Test::collection method returns either vector<Test> or vector<test>; it only seems to match if I have it literally return vector<_self>, which implies to me that I'm not understanding what I'm doing, and that _self isn't getting substituted in this case. What do I need to do in order to be able to return types that are dependent on the erasure type? My actual code uses a more indirect relationship, with the collection method returning a custom erased collection type that has an erased iterator that can dereference to the equivalent of Test. However, since there is still a form of cyclic dependency, I'm not really sure what I can do about it. I've tried using a custom struct based concept that had direct template arguments in the place of 'boost type erasure member', but I think I understand that technique even less, and it didn't seem to help much. It looked like there might be something useful under the Associated Types section of the type erasure documentation, but I couldn't quite figure it out. Any assistance would be most helpful. Thanks, -sc

2 5

[Coroutine] Assertion when coroutine is not run
by Brian Ravnsgaard Riis 13 Mar '14

13 Mar '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I've been toying with Boost.Coroutine lately. For starters I have tried to implement a message parser using the library. For this purpose I have two coroutine<char>::push_type in a containing class. These are initialized at class construction with a lambda. One coroutine parses the message header, the other the body. This all worked fine. Until I had a test case where I was only interested in the message header, so I never called the message-body-coroutine. At object destruction I get a this assertion: replyparser: /usr/local/include/boost/coroutine/detail/push_coroutine_object.hpp:167: void boost::coroutines::detail::push_coroutine_object<char, <lambda at src/replyparser.cpp:303:22>, boost::coroutines::detail::standard_stack_allocator, std::allocator<boost::coroutines::push_coroutine<char> >, boost::coroutines::pull_coroutine<char> >::run() [X = char, Y = <lambda at src/replyparser.cpp:303:22>, Z = boost::coroutines::detail::standard_stack_allocator, V = std::allocator<boost::coroutines::push_coroutine<char> >, W = boost::coroutines::pull_coroutine<char>]: Assertion `hldr_from->data' failed. The message-body coroutine is really simple; it just takes the characters and stuffs them into a std::string until the string size is equal to the expected length of the body (parsed from the header): [&](coroutine<char>::pull_type& c) { content.push_back(c.get()); while(content.size() != contentLength) { c(); content.push_back(c.get()); } validResult = true; } This works just fine when I parse the message body, but when I (choose to) ignore the message body, so the coroutine is never called, I get the above assertion. I have a feeling I'm missing some obvious detail about this. Of course I would normally not skip the message body, but there is a chance the length is 0, i.e. there *is* no message body. I'd prefer to have no assertions in that case. What am I doing wrong? /Brian Riis -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTHQlPAAoJEFES4N8QrEodJ+MH/1z+N+YnXrCm3xPnp7wAlM+w 3RZkeNOOJ0h67nmBHRJXj3A3+t/Hy+FZV/SUBDMtCwx/zIH5fZZtsBaw89frAsdI SPmLiwG6NgBoBSV8Pih4gD+k4LvTbYh5AQLF2ssB/WAVZODk92iz4sNrNFVwThFn S68NStkEyyXElrCzkd3w0QQD8sD2OGWAW0YlHLGhUXlsouWRyd9VKAbEXdrTKLVQ I0ciL87AzOKsfrfV89U1eQh5uHEgg8ZcDa459ieqeOISXhNJI/ba8rv6mkXGEseB U7wRr7M1XMdHolPiFlUEKrUocdAPLS/AjeVfcGkJSzc2bhka08qu4EMTgqkOhtY= =G1Y2 -----END PGP SIGNATURE-----

2 10