July 2014 - Boost - lists.preview.boost.org

[unordered] valgrind reports "possibly lost" memory when not destroying the container
by Adam Romanek 07 Jul '14

07 Jul '14

Hi! I have a problem with containers from Boost.Unordered. Before I go into details please let me show you the big picture. I have a code that creates "unordered" containers in a lot of places, but these containers never really get destroyed / deleted at the end of the program. However, they are all "still reachable" through various pointers in the program and... valgrind reports them as such. This is OK for me. Now the problem is that the containers from Boost.Unordered do something clever with pointers and valgrind also reports some "possibly lost" memory blocks [1]. This only happens when the unordered containers are not destroyed before the end of the program. When I do the proper clean-up valgrind stays quiet. However, in the code base where I discovered the problem it is currently not possible to do such a clean-up. The problem became serious for me for a number of reasons. In the code base that I referred to above valgrind reports ~7000 "possibly lost" memory blocks. Some of them come from Boost.Unordered containers. I could try to suppress them via a suppressions file, but the problem is that the Boost.Unordered code gets inlined in nearly all cases and there's no simple way to suppress valgrind from reporting these "possibly lost" memory blocks. Without that I'm stuck with tons of reports that I can't really do anything about. Given the above I have a few questions: - has anyone ever encountered this problem? has anyone solved it? - is it possible to force some simpler but maybe more expensive memory management in Boost.Unordered to suppress these "possibly lost" reports? - what other options do I have? My setup is: - gcc 4.8.2 - Boost 1.55 - Ubuntu 14.04 x86_64 WBR, Adam Romanek [1] http://pastebin.com/A4fvx0K0

2 2

ASIO in the Standard (was Re: C++ committee meeting report)
by Dean Michael Berris 06 Jul '14

06 Jul '14

Cross-posting to networking(a)isocpp.org and c++std-lib-ext. On Wed, Jun 25, 2014 at 12:47 AM, Beman Dawes <bdawes(a)acm.org> wrote: > > * The Library Evolution Working Group (LEWG) voted to base the Networking > TS on Boost.ASIO. That was a major surprise, as a Networking Study Group > had been trying to build up a Networking TS from many small proposals. But > in LEWG polls, support for ASIO was overwhelming, with no one at all voting > against. This was a major vote of confidence for Boost.ASIO and Chris > Kohlhoff. And several ASIO supporters were not even in the room at the time > because Filesystem issues were being worked on elsewhere. > FWIW, I was in the room when the Boost.Asio proposal was being discussed way back in Kona. I haven't seen the most recent update to the proposal, but if my original concerns were addressed, mainly: - The io_service type was trying to be too many things at the same time (executor, ran in thread-pools, implementing IO-specific hooks, etc.) and was too prominent in the interfaces of primitive types (i.e. sockets, etc.). - There were too many leaking abstractions crossing boundaries -- being able to reach in to get native handles, buffer lifetimes crossing in-and-out, etc. - The fact that it seems the only implementation of the networking parts (and inter-operating bits implied by the interface) would be through a proactor -- how the API was only proactive, no support for just purely reactive applications. - There's no means for doing "zero-copy" I/O which is a platform-specific but modern way of doing data transfer through existing interfaces. ... then this I think is *good news*! Having worked with quite a few network applications now in the past few years, I'm happy with what Boost.Asio provides. However I think there are other systems/libraries we can learn from to inform the design here (I tried getting a comprehensive survey paper in, but that proved a little harder than I originally thought and ended up with just doing a poor job for HTTP). A few that come to mind for potential approaches here are: - Transport-level abstractions. Considering whether looking at policy-driven transport protocol abstractions (say, an http connection, a raw TCP connection, an SCTP connection with multiple streams, etc.) would be more suitable higher-level abstractions than sockets and write/read buffers. - Agent-based models. More precisely explicitly having an agent of sorts, or an abstraction of a client/server where work could be delegated, composed with executors and schedulers. I admit I haven't exactly been following through on attending the Networking SG meetings and sending in papers myself. I sincerely hope though that our collective love for Boost.Asio doesn't preclude us from thinking at higher levels of abstractions and in broadening our view/understanding of the network-programming landscape. I say this with all due respect -- while network programming sounds like it's all about sockets, buffers, event loops, and such there are the "boring" bits like addressing, network byte ordering, encoding/decoding algorithms (for strings and blobs of data), framing algorithms, queueing controls, and even back-off algorithms, congestion control, traffic shaping. There's more things to think about too like data structures for efficiently representing frames, headers, network buffers, routing tables, read-write buffer halves, ip address tries, network topologies, protocol encodings (ASN.1, MIME and friends), and a whole host of network-related concepts we're not even touching in the networking discussions. Having said this, I'm happy that we're willing to start with Boost.Asio. :) > The next C++ committee meeting is November 3rd to 8th in Urbana-Champaign, > IL, USA. As always, Boosters welcome. > Would really love to go, or at least be able to send comments to papers in time for that one. Thanks for the report Beman!

3 5

[1.56] Getting the release back on track - build errors
by John Maddock 06 Jul '14

06 Jul '14

There are several build errors when building current master, for this test I used Mingw64: * Context fails to build complaining about ml64 not being found, but since I'm building with gcc it really should be using as? * Thread fails to build complaining about missing boost/utility/detail/result_of_iterate.hpp, this is a result of: #define BOOST_PP_ITERATION_PARAMS_1 (3,(0,BOOST_RESULT_OF_NUM_ARGS,<boost/utility/detail/result_of_iterate.hpp>)) In boost/utility/result_of.hpp, we could presumably fix this by adding a dependency that Boost.Build can actually track to this header. Presumably we should do the same for all header iterations? * Coroutine fails for the same reason as thread. * Header only libraries are not installed when doing a build/stage/install all, you have to explicitly invoke b2 headers. IMO this will trip a lot of folks up. * There is no mention of the "b2 headers" option from "b2 --help". Question - I assume that if folks do a library-specific install then we *don't* want to install all headers? Can we achieve that and yet make the equivalent of "b2 headers" happen if folks do a build all? Cheers, John.

4 3

Re: [boost] ASIO into the standard (was: Re: C++ committee meeting report)
by a.hagen-zanker＠surrey.ac.uk 05 Jul '14

05 Jul '14

Sent from my HTC ----- Reply message ----- From: "Jonathan Wakely" <jwakely.boost(a)kayari.org> To: "boost(a)lists.boost.org" <boost(a)lists.boost.org> Subject: [boost] ASIO into the standard (was: Re: C++ committee meeting report) Date: Fri, Jul 4, 2014 15:45 On 4 July 2014 12:44, Niall Douglas wrote: > There are lots of things going on here. STL allocators were always > half baked because they were never finished - John Lakos is but one > of many who took them to all sorts of interesting new places, indeed > Stepanov's original design had enormous potential. Unfortunately, > we've ended up stuck with these half finished things, and now they > are creating slow path performance with std::vector<std::vector<T>> > because STL containers can't have a noexcept move constructor due to > allocators! That's not txrue, the move constructor always propagates the allocator so doesn't need to re-allocate. The reason for it not being noexcept is not because of allocators, and at the last meeting we agreed that vector and string should have noexcept move constructors, always. Move assignment might need to reallocate for non-equal allocators, so that can't always be noexcept (but the implementation can add a conditional noexcept using the propagate_on_container_move_assignment trait, if your vendor doesn't do that complain to them :-) _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

Re: [boost] ASIO into the standard
by Brian Wood 04 Jul '14

04 Jul '14

Niall Douglas writes: > Linux needs to adopt kqueues Is there any progress in this area? I'm using Arch Linux and epoll currently to support what I'm working on, but am thinking about checking out FreeBSD. It's hard to tell if FreeBSD would be a good move even though kqueue is appealing. Brian Ebenezer Enterprises - In G-d we trust. http://webEbenezer.net

2 1

boost msm with more than 10 states causes long compilation error
by Raj Sambasivan 03 Jul '14

03 Jul '14

Hi, I get a long compilation error when i include the last line, it compiles fine without the last line. i tried including #define BOOST_MPL_CFG_NO_PREPROCESSED_HEADERS #define BOOST_MPL_LIMIT_VECTOR_SIZE 30 // or whatever you need #define BOOST_MPL_LIMIT_MAP_SIZE 30 but still have the same problem, compilation error is at the bottom. any help? struct transition_table: boost::mpl::vector< Row<Empty, NewOrderRequest, PendingNew, handleNewOrderRequest>, Row<PendingNew, AckedResponse, Acked, handleAckedResponse>, Row<PendingNew, OrderRejectedResponse, OrderRejected, handleOrderRejectedResponse>, Row<PendingNew, CancelRequest, PendingCancel, handleCancelRequest>, Row<PendingCancel, CanceledResponse, Canceled, handleCanceledResponse >, Row<PendingCancel, CancelRejected, CancelRejected, handleCancelRejectedResponse>, Row<PendingReplace, ReplacedResponse, Replaced, handleReplacedResponse >, Row<PendingReplace, ReplaceRejected, ReplaceRejected, handleReplaceRejectedResponse>, Row<Acked, CancelRequest, PendingCancel, handleCancelRequest>, Row<Acked, FilledResponse, Filled, handleFilledResponse> > { }; compilation error (truncated) g++ -I/boost_1_55_0/ -c -Wall test.cpp In file included from test.cpp:1: In file included from ./Order.H:11: In file included from /boost_1_55_0/boost/msm/back/state_machine.hpp:28: In file included from /boost_1_55_0/boost/fusion/include/as_set.hpp:10: */boost_1_55_0/boost/fusion/container/set/convert.hpp:24:30: **error: * *implicit* * instantiation of undefined template 'boost::fusion::detail::as_set<11>'* typedef typename gen:: * ^* */boost_1_55_0/boost/msm/back/state_machine.hpp:1164:50: note: *in instantiation of template class 'boost::fusion::result_of::as_set<boost::mpl::s_item<Filled, boost::mpl::s_item<ReplaceRejected, boost::mpl::s_item<Replaced, boost::mpl::s_item<CancelRejected, boost::mpl::s_item<Canceled, boost::mpl::s_item<OrderRejected, boost::mpl::s_item<Acked, boost::mpl::s_item<PendingReplace, boost::mpl::s_item<PendingCancel, boost::mpl::s_item<PendingNew, boost::mpl::s_item<Empty, boost::mpl::set0<mpl_::na> > > > > > > > > > > > >' requested here typedef typename ::boost::fusion::result_of::as_set<state_list>::typ... * ^* *test.cpp:5:37: note: *in instantiation of template class 'boost::msm::back::state_machine<<anonymous>::order_, boost::parameter::void_, boost::parameter::void_, boost::parameter::void_, boost::parameter::void_>' requested here std::cout << " -> " << state_names[o.current_state()[0]] << std::endl; * ^* */boost_1_55_0/boost/fusion/container/set/detail/as_set.hpp:26:12: note: * template is declared here struct as_set; * ^* In file included from test.cpp:1: In file included from ./Order.H:11: In file included from /boost_1_55_0/boost/msm/back/state_machine.hpp:28: In file included from /boost_1_55_0/boost/fusion/include/as_set.hpp:10: */boost_1_55_0/boost/fusion/container/set/convert.hpp:25:26: **error: * *'apply'* * following the 'template' keyword does not refer to a template* template apply<typename result_of::begin<Sequence>::type>::type * ^~~~~* *test.cpp:5:38: **error: **expected ']'* *...*

2 1

Interest in a new generic matrix library with specific 3D operations?
by Fabien Picarougne 03 Jul '14

03 Jul '14

Hi, I have developed a generic matrix library with some specialization for 3D operations. I wondering if it would be of interest for me to submit it as a Boost library. There are some differences compared to the current ublas/matrix class. The dimensions of this matrix are template parameters, this allows to make specializations for particular dimensions and efficiency in some combinations of parameters. This library takes advantage of some C++11 elements and so requires a C++11 enabled compiler. I have tested it with gcc 4.8.2 and MSVC 2013. It contains a generic global matrix class (CMat) which can be specialized in a number of matrix (square matrix, vectors, 4x4 matrix.) in order to use more efficient algorithms or adding particular methods. Because I use it in a 3D rendering engine, I have built a specific CMat4x4 class with standard 3D operators on matrix and vectors. I have posted the current code here: https://bitbucket.org/fpicarougne/template-matrix-library In order to use all the specializations, include "Matrix/CMat3D.hpp" and take a look to "Matrix.cpp" for an example of usage. Fabien

4 6

[ANN] CppCon 2014 program available
by Boris Kolpackov 02 Jul '14

02 Jul '14

The CppCon 2014 Program is now available with talk titles, abstracts, and speakers: http://cppcon.org/conference-program/ The program contains over 100 one-hour sessions by over 70 speakers including plenary sessions by Scott Meyers and Herb Sutter, as well as the keynotes by C++ creator Bjarne Stroustrup on Keeping Simple Things Simple and Mark Maimone on using C++ on Mars: Incorporating C++ into Mars Rover Flight Software. We have also extended the Early Bird deadline to July 9 so you have a week to study the program and still get the Early Bird rate. Hope to see you in Bellevue! Boris

1 0

Help with understanding regression test results
by Andrzej Krzemienski 01 Jul '14

01 Jul '14

Hi, Recently I observed lots of test cases showing as failed in regression tests on branch 'develop' in Boost.Optional: http://www.boost.org/development/tests/develop/developer/optional.html When I try to inspect the results they are either empty or refer to the places in the code that do not exist anymore in branch 'develop', as though the test environments were using partial results of GIT commits. But the test dates are after the last commit, so it looks like something is broken with the testing framework. Anyone can help me with figuring out what to do? Regards, &rzej

5 19

[fusion] Definition for FUSION_MAX_MAP_SIZE
by Edward Diener 01 Jul '14

01 Jul '14

The documentation for fusion implies that FUSION_MAX_MAP_SIZE is defined whenever a fusion header is included. is this so ? Testing this out under Wave suggests it is not so. What fusion header needs to be included in order to bring in the definition for FUSION_MAX_MAP_SIZE ?

3 6