- Boost - lists.boost.org

Best home for cxx11_char_types.hpp?
by Beman Dawes 09 Jul '14

09 Jul '14

I'm working on an update of Boost.Filesystem that adds support for the C++11 char16_t, char23_t, u16string, and u32string types. For compilers that don't yet support these types, a header cxx11_char_types.hpp (see attached) provides emulation that is good enough for filesystem, and is probably useful for other libraries and for user code too. We discussed this header several years ago, and I've been using it since then. Where should this header live? It can certainly go in libs/filesystem/include/boost/filesystem, but that doesn't really expose it to general Boost users. Is there a better place, but without introducing unwanted dependencies? --Beman

2 2

[type_erasure] Force any to have typedef
by Benedek Thaler 09 Jul '14

09 Jul '14

Hi, Assume I have the following function template: template <typename Container> typename Container::value_type get_front(const Container& c) { return c.front(); } Is there a way I can force type_erasure::any<> to have a `value_type` typedef? I can create a concept which requires the underlying type to have it, but I'd like to make `any` to have such a typedef. Thanks, Benedek

2 2

search folder by using filesystem namespace
by dd 09 Jul '14

09 Jul '14

Hi all, I want to search for a folder in a particular directory in any level. Is there any direct api to search folder by using filesystem namespace? If not, will boost api support to iterate directories in sorting order? Please provide code snippet if available. Thanks, dd

2 1

[1.56.0] Release notes
by Daniel James 08 Jul '14

08 Jul '14

Hello all, If you haven't written up your release notes yet, now is a good time. You can create a pull request on github by clicking on 'edit' on this page while logged in: https://github.com/boostorg/website/blob/master/feed/history/boost_1_56_0.q… Alternatively, you can clone the site locally and do it using the normal git procedure, or you can email me and I'll add it for you. thanks, Daniel

1 0

Re: [boost] [polygon] examplefile compilation failed
by J Stark 08 Jul '14

08 Jul '14

Hello Boost Polygon Folk, First off, I have to say, boost polygon is pretty great. Thanks for all the hard work you've put into it. I'm replying to a forum message here: http://boost.2283326.n4.nabble.com/template/NamlServlet.jtp?macro=reply&nod… which notes that the example files don't compile. It was posted in 2009. I'm noticing that the example here: http://www.boost.org/doc/libs/1_55_0/libs/polygon/doc/gtl_custom_polygon.htm still doesn't compile properly on a mac using Apple LLVM version 5.0 (clang-500.2.79) I think the examples are extremely important, as template programming can be confusing all by itself, and so having a working example to start with is really a time saver. Does this example work properly with other compilers making it hard to fix for the universal/general case? It seems that the original post from 2009 contains the fix that works; "typedef int coordinate_type;" needs to be inserted in point_mutable_traits like so: template <> struct point_mutable_traits<CPoint> { typedef int coordinate_type; static inline void set(CPoint& point, orientation_2d orient, int value) { if(orient == HORIZONTAL) point.x = value; else point.y = value; } static inline CPoint construct(int x_value, int y_value) { CPoint retval; retval.x = x_value; retval.y = y_value; return retval; } }; } } My question is if the documentation example here: http://www.boost.org/doc/libs/1_55_0/libs/polygon/doc/gtl_custom_polygon.htm can be updated to include this fix, and save time for folks who are trying to get that example to work, or if this solution isn't valid for some combination of other more popular compilers? Thanks again for all the hard work on the library, and very best of regards, J PS: please advise if I'm posting to the wrong forum, sending mail in the wrong way, or in any way going at this the wrong way :) I have more questions/concerns to follow up with :) -- View this message in context: http://boost.2283326.n4.nabble.com/polygon-examplefile-compilation-failed-t… Sent from the Boost - Dev mailing list archive at Nabble.com.

1 0

[atomic] Structs with default constructor
by Marcel Raad 08 Jul '14

08 Jul '14

Boost.Atomic 1.55 accepted structs with a user-defined default constructor as template argument, the version from the 1.56 test build doesn't (because of the union_cast). Is this by design? I could be wrong, but I thought the only requirement for structs to use them in atomics was that they were trivially coyable.

3 8

Re: [boost] Test build for 1.56 available
by Matthew Musto 08 Jul '14

08 Jul '14

Marshall, I had good luck building boost-1_56_0a1c2 on Windows 8.1 with Visual Studio 2013 Ultimate. There are a number of warnings about 'round' but the standard .\b2 build completed without issue. I am going to run a few of my programs with this version as the include and let you know if I run into any issues. -Matt > From: Marshall Clow <mclow.lists <at> gmail.com> > Subject: Re: Test build for 1.56 available <http://news.gmane.org/find-root.php?message_id=CAMBqOsjj%5fn3HSJ7755eOUxrXC…> > Newsgroups: gmane.comp.lib.boost.devel <http://news.gmane.org/gmane.comp.lib.boost.devel> > Date: 2014-07-07 18:56:57 GMT (6 hours and 6 minutes ago) > Ok, here are rc2s. > Fixed (I believe) are: > * Now includes winapi library > * Underscores instead of periods in the names > * No more weit metadata in the tar file. > https://dl.dropboxusercontent.com/u/11048326/boost/boost-1_56_0a1c2.zip <https://dl.dropboxusercontent.com/u/11048326/boost/boost-1_56_0a1c2.zip>> https://dl.dropboxusercontent.com/u/11048326/boost/boost-1_56_0a1c2.tar.gz <https://dl.dropboxusercontent.com/u/11048326/boost/boost-1_56_0a1c2.tar.gz> > Please check them out, let me know what problems you have. > Thanks to people who checked out the previous builds and reported problems. > — Marshall -- -------------------- Matthew Musto matthew.musto(a)gmail.com

2 1

Missing regression test results
by Eric Niebler 08 Jul '14

08 Jul '14

Xpressive's test results appear to be missing for develop. When I got here: http://www.boost.org/development/tests/develop/developer/xpressive.html I see "Error extracting file: The specified zipfile was not found." What could be causing the problem? -- Eric Niebler Boost.org http://www.boost.org

2 2

[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