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

[move] interest: the pass-by-value and swap idiom, and explicit copy constructors
by Krzysztof Czainski 20 Feb '14

20 Feb '14

Hello, I would like to ask about interest in an idea of mine. I described it in detail [1] and implemented it as part of my cz libraries [2]. In short, the idea presents: - an alternative to implicitly copyable and movable types: making them explicitly copyable; - a protocol for explicitly stating in code, where a copy is to be made (boost::copy()), which compliments the protocol for explicitly stating in code, where a move is allowed (std::move() or boost::move()); - a Boost.move extension for implementing movable types with use of the pass-by-value and swap idiom, backwards-compatible with C++98, which allows to choose copying policies (and eases changing between these policies during maintenance): - movable but not copyable, - movable and explicitly-copyable, - movable and copyable; - an example, showing how simply a CloneablePtr can thereby be implemented. This extension to Boost.move is hosted and developed as part of my cz libraries [2], but it isn't tied to them at all. It only consists of two headers. I extracted the two headers together with samples and docs, and they are available as a zip archive [3]. I would be most excited if there was interest in adding this functionality to Boost.move, but in any case, all comments are much appreciated. Regards, Kris [1] http://kristoczaj.bitbucket.org/cz/copy_move_types.html [2] http://kristoczaj.bitbucket.org/cz/index.html [3] http://bitbucket.org/kristoczaj/cz/downloads/move-0.7.1.zip

5 10

[build] Headers rule does both too much and too little
by John Maddock 20 Feb '14

20 Feb '14

Folks I don't think the headers rule is working very well at present - it seems to both do too much and too little depending on the context: Too much: If I build the type_traits tests so everything is up to date, and then touch say type_with_alignment.hpp, then in libs/type_traits/test do: bjam add_const_test And for some strange reason bjam thinks there's a dependency on type_with_alignment.hpp from add_const_test, and there really isn't. In fact *every* test seems to be out of date now. Too little: The headers under boost/config/ are included via macros so aren't placed in the dependency graph. I can fix this easily enough in the Boost.Config tests, but ideally this should be fixed at the top level by making everything under boost/config/ a dependency of boost/config.hpp. This is currently causing some Boost.Config tests to fail in the online matrix, I bet there are others as well. Anyone any ideas? Thanks, John.

7 17

[move] [range] move algorithm (was: interest: the pass-by-value...)
by Krzysztof Czainski 20 Feb '14

20 Feb '14

2014-02-15 1:05 GMT+01:00 Adam Wulkiewicz <adam.wulkiewicz(a)gmail.com>: > Hi, > > Krzysztof Czainski wrote: > >> 2014-02-14 18:16 GMT+01:00 Lars Viklund <zao(a)acc.umu.se>: >> >> On Fri, Feb 14, 2014 at 05:52:53PM +0100, Krzysztof Czainski wrote: >>> >>>> - a protocol for explicitly stating in code, where a copy is to be made >>>> (boost::copy()), which compliments the protocol for explicitly stating >>>> in >>>> >>> Note that boost::copy already exists as the widely used Range-based >>> complement of std::copy algorithm. >>> >>> I just want to get this out of the way so people can focus on the actual >>> proposal and not parrot this over and over again. >>> >>> Good point, thanks Lars. >> >> Note, that an algorithm boost::move also exists: >> http://www.boost.org/doc/libs/1_55_0/doc/html/move/move_algorithms.html >> And I'm not sure how a Range-based complement to the move algorithm could >> look like, but it may also turn out useful. >> > > Probably like this: > boost::move(range, out_it) ; > > Regards, > Adam Hmm, how about: boost::copy( range | movable, out_it ); Regards, Kris

6 22

[Boost.Test] Assertion changes in trunk? [WAS: Call for Review: Boost.Test documentation rewrite]
by Dominique Devienne 19 Feb '14

19 Feb '14

On Wed, Jan 22, 2014 at 11:25 AM, Alexander Lamaison <awl03(a)doc.ic.ac.uk>wrote: > [...] As for as I'm aware, the only change is > to the assertion macros, which move to a more natural syntax: > > BOOST_CHECK_EQUAL(a, b) becomes BOOST_TEST(a == b) > BOOST_CHECK_LT(a, b) becomes BOOST_TEST(a < b) > ... etc. > BOOST_REQUIRE_EQUAL(a, b) becomes BOOST_TEST_REQUIRE(a == b) > ... etc. > BOOST_WARN_EQUAL(a, b) becomes BOOST_TEST_WARN(a == b) > But don't we then miss better messages which actually show the values themselves when the assert fails? I do BOOST_CHECK(a == b) only when a and b lack the op<<, but otherwise greatly prefer BOOST_CHECK_EQUAL(a, b). And what's the point of going from BOOST_REQUIRE(expr) to BOOST_TEST_REQUIRE(expr), i.e. make it longer / more typing? What am I missing? --DD

11 17

Meeting C++ 2014 - Call for Papers
by Jens Weller 19 Feb '14

19 Feb '14

Hello boost community, Meeting C++ 2014 has been announced today, it will be in Berlin on the 5th and 6th December! More details on the conference in the official announcement: http://meetingcpp.com/index.php/newsreader/items/announcing-meeting-c-2014-… With the announcement, also the call for paper is now again open till April 20th. This years theme track of the conference is "Scientific Programming with C++". I'm looking for a diverse set of talks about C++, talks about boost, Qt, STL, any libraries, testing, the C++ language (C++11/14/1y) or any other C++ related topic. More details on the call for papers: http://meetingcpp.com/index.php/newsreader/items/call-for-papers-meeting-c-… Kind regards, Jens Weller

1 0

[GSoC 2014] [ B-tree + Trie ]
by Cosmin Boaca 19 Feb '14

19 Feb '14

Hello, I am a second year BS student at Politehnica University of Bucharest and I am interested in contributing to boost during GSoC 2014. I would like to work at implementing the B-Tree data structure and continuing the work at the Trie data structure implemented in last year's gsoc. I would like to hear your opinion about this project and I would be glad to discuss with someone that is willing to be a mentor for it. Thank you, Cosmin Boaca

3 2

[type_traits] Should namespace boost::align be namespace boost::detail::align?
by Glen Fernandes 18 Feb '14

18 Feb '14

I was working on a tiny library, Boost.Align, which would provide (among other things) a boost::align (that would be std::align if BOOST_NO_CXX11_STD_ALIGN is not defined, or a reasonably non-portable implementation otherwise) and found that type_with_alignment.hpp uses the identifier 'align' for a namespace within namespace 'boost'. Was this namespace intended to not be within boost::detail? If it can be, I'll send a pull request; if not, I'll choose a different identifier over 'align'. Glen

2 3

Release script module
by Daniel James 18 Feb '14

18 Feb '14

Now that we have a separate module the release scripts we should remove them from the super project. I'll do that if there are no objections. Do we want to keep it as a submodule, or just completely separate? A lot of the scripts seem to be subversion specific, so can they just be deleted?

4 5

[trac] Resolving tickets
by Ahmed Charles 18 Feb '14

18 Feb '14

https://svn.boost.org/trac/boost/ticket/9415 I've never used trac before and I'm trying to resolve this ticket, but I don't think I can. Do I need a 'trac id' to be able to resolve tickets? Or am I simply missing something?

2 1

Re: [boost] Just another GSoC project idea: Create a Bjam clone based on the Boost libraries
by Brian Wood 17 Feb '14

17 Feb '14

Niall Douglas writes: > (My only request is that if you do do this, please stick a great big > auto-generated warning on the top of every bjam file output. I've got > nobbled by my build script changes getting eaten too many times in my > life!) I'm not sure. I generate both headers and source files. Currently in the headers, I have such a warning. But all of the generated files have a "zz." prefix. I could either put the big warning also in the source files or remove it from the header files. It seems to me that the naming convention might be enough of a warning. Also, I've liked the prefix since it groups the generated code together. -- Brian Ebenezer Enterprises - In G-d we trust. http://webEbenezer.net

1 0