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

[Range] New I/O functions for ranges
by Indiana 25 Nov '14

25 Nov '14

I'm currently putting together a proposal to the standards committee about a set of range I/O functions, but i think they would make a good addition to Boost as well. They would probably fit in the Range library - i don't think they warrant a library all of their own. The stuff i wrote for the standards proposal is available at http://cpp.indi.frih.net/rangeio/ - it goes into quite a bit of detail about the interface, and links to a sample implementation. But here's the executive summary: There is a single output function - currently called "write_all" - that takes a range and, optionally, a delimiter, like this: // BEGIN CODE ///////////////////////// auto const r = std::array<int, 4>{1, 2, 3, 4}; cout << write_all(r); // prints "1234" cout << "{ " << write_all(r, ", ") << " }"; // prints "{ 1, 2, 3, 4 }" // END CODE /////////////////////////// It takes anything that works with range-for, so it works with range adaptors: // BEGIN CODE ///////////////////////// struct is_even { auto operator()(int x) const -> bool { return x % 2 == 0; } }; cout << write_all(r | reversed | filtered(is_even{})); // prints "42" // END CODE /////////////////////////// Note also that the delimiter doesn't have to be a string (there are some examples in the reference of that). Why not just use std::copy() and stream iterators? Several reasons - the most obvious of which you can see above: this syntax is much cleaner, much less error-prone, well-integrated with the existing stream I/O mechanisms, and it produces properly delimited output (unlike the delimited version of ostream_iterator). But also, stream formatting is properly handled: // BEGIN CODE ///////////////////////// auto const r = std::array<int, 3>{1, 2, 3}; std::cout.width(3); std::cout.fill('0'); // --------------------------- // The old way: using std::begin; using std::end; std::copy(begin(r), end(r), std::ostream_iterator<int>{std::cout, ", "}); // even with Boost.Range, this just reduces to: //boost::copy(r, std::ostream_iterator<int>{std::cout, ", "}); // prints: "001, 2, 3, " // --------------------------- // The new way: std::cout << write_all(r, ", "); // prints "001, 002, 003" // END CODE /////////////////////////// And of course this works as expected in chained expressions: // BEGIN CODE ///////////////////////// auto const r = array<int, 3>{1, 2, 3}; cout.width(3); cout.fill('0'); cout << '(' << setw(3) << setfill('0') << write_all(r, ',') << ')'; // prints: "(001,002,003)" // END CODE /////////////////////////// It is also possible to get more information about errors, and react better to them. If there is an error in the formatting or in the stream during an output operation using std::copy() and ostream_iterator, the algorithm will chug merrily along until it's all the way through the range even though it's no longer writing anything. You will have no way to detect where the problem occurred - did it fail after the first element was written, or *before*, or did it fail after the millionth element? If the range is begin lazy-generated, that could be particularly wasteful, or even problematic. By contrast, write_all() stops immediately when there is an error in the output stream. It is even possible get more information about the last range write operation by capturing the temporary object, like this: // BEGIN CODE ///////////////////////// auto const r = array<int, 3>{1, 2, 3}; auto p = write_all(r); cout << p; if (!cout) { cerr << "only " << p.count << " elements written\n"; cerr << "next element would have been " << *p.next << '\n'; } // END CODE /////////////////////////// On the input side, there are 7 functions: * overwrite * back_insert * front_insert * insert * back_insert_n * front_insert_n * insert_n Overwrite simply replaces the contents of a range with whatever is read from input: // BEGIN CODE ///////////////////////// auto r = array<int, 100>{}; cin >> overwrite(r); // reads up to 100 ints // END CODE /////////////////////////// The *insert functions map to the *insert_iterators in the standard library, using push_back(), push_front(), or insert(). In each case: in >> ???insert(r[, i]); is basically equivalent to: copy(istream_iterator<value_type_of_r>{in}, // use braces on the next line, or face the most vexing parse istream_iterator<value_type_of_r>{}, ???inserter(r[, i])); The *insert_n functions are for the common case where you know in advance how many elements will be read, at maximum - or for when you want to limit the amount of elements read in a single read operation. This: in >> ???insert_n(r[, i], n); is conceptually equivalent to: copy_n(istream_iterator<value_type_of_r>{in}, n, ???inserter(r[, i])); except it can handle formatting and errors properly. The reference at http://cpp.indi.frih.net/rangeio/ goes into much more detail, of course. Why add it to Boost? Because these operations (reading/writing ranges) are so common they are almost universal, and there is no standard facility that handles them easily or well. They are not *difficult* to implement, but they are far from trivial - for example, you might think write_all() is just a simple range-for loop or for_each(), and it is... up until you add error checking, the delimiter, and formatting awareness. A sample implementation already exists - it can be implemented portably in pure standard C++11. (Can it be implemented in C++03 with? Good question. It might be possible with some Boost help, but it might require dependencies on libraries other than Boost.Range. If this proposal finds approval, that's something i can look into.) Would there be any interest in adding these functions to Boost.Range?

5 13

Changes in Boost.Optional
by Dean Michael Berris 24 Nov '14

24 Nov '14

Suppose I have the following type: struct container { boost::optional<uint16_t> optional() const { return value_; } private: boost::optional<uint16_t> value_; }; struct value_wrapper { value_wrapper(const container& c) : c_(c) {} operator uint16_t () { return 1; } operator boost::optional<uint16_t>() { return c_.optional(); } private: const container& c_; }; And that I have the following function: value_wrapper value(const container& c) { return value_wrapper(c); } The following used to work in MSVC 2010: container c; // leave c.value_ alone. boost::optional<uint16_t> some_value = value(c); assert(!some_value); Now with Boost 1.56, this breaks because the constructor for some_value from a temporary optional is now marked explicit. What is the work-around for the previous behavior to be regained? All the following changes cause the assertion to fail: boost::optional<uint16_t> some_value(value(c)); assert(!some_value); // some_value's constructor will use the uint16_t conversion operator, therefore some_value == 1 boost::optional<uint16_t> some_value = static_cast<boost::optional<uint16_t> >(value(c)); assert(!some_value); // same problem as above, the temporary created will favor the uint16_t conversion operator Help? PS. For better context, see https://github.com/cpp-netlib/cpp-netlib/blob/0.11-devel/boost/network/prot…

8 26

Ticketspam
by Daniel Frey 17 Oct '14

17 Oct '14

One more to remove: <https://svn.boost.org/trac/boost/ticket/10560> Thanks, Daniel

10 18

It's that time again already - Boost 1.57.0 schedule
by Marshall Clow 08 Oct '14

08 Oct '14

It’s that time again. Here’s the schedule for the upcoming 1.57 release. If you’ve got changes that you’ve been putting off making, now’s the time to get busy. * 13-Oct Last day for significant changes * 20-Oct Beta build * 27-Oct Automatic merging turned off, build an RC * 3-Nov Release Boost 1.57.0 Questions? Ask them here. — The Boost release managers. P.S. We’ll be updating the calendar on boost.org/development soon.

5 5

Submodules of Boost libraries
by Mathias Gaunard 07 Oct '14

07 Oct '14

Hi folks, I'd like to ready my library for inclusion into Boost. My library is made of several modules, and I'd like to keep that into Boost. How does Boost handles multiple submodules within a library submodule?

7 11

[modularization] LocalFunction and ScopedExit cycle
by Vicente J. Botet Escriba 06 Oct '14

06 Oct '14

2 3

[static_if] Is there interest in a `static if` emulation library?
by Lorenzo Caminiti 01 Oct '14

01 Oct '14

Hello all, With C++14 generic lambdas, it is possible to implement a sort of `static if` (see also N3613): template< typename T > void assign ( T& x, T const& y ) { x = y; static_if<boost::has_equal_to<T>::value>( std::bind([] ( auto x, auto y ) { assert(x == y); std::cout << "asserted for: " << typeid(T).name() << std::endl; }, x, y) ).else_( [] ( ) { std::cout << "cannot assert for: " << typeid(T).name() << std::endl; } ); } The bind around the generic lambda is a bit verbose... but this code compiles, asserts when called on int, and does not assert when called on x_t (tested on clang 3.4.2): int i = 1; struct x_t { } x; assign(i, i); // asserts assign(x, x); // does not assert I have attached a reference implementation. Thank you. --Lorenzo P.S. I didn't do much background research... sorry if this topic has already been considered and discussed in Boost.

17 43

[move] Build failures in develop
by Andrey Semashev 01 Oct '14

01 Oct '14

Hi, I'm seeing lots of build errors that originate from Boost.Move, such as: In file included from ../libs/log/src/text_file_backend.cpp:41: In file included from ../boost/filesystem/path.hpp:28: In file included from ../boost/iterator/iterator_facade.hpp:12: In file included from ../boost/iterator/interoperable.hpp:11: In file included from ../boost/mpl/or.hpp:23: ../boost/mpl/aux_/nested_type_wknd.hpp:27:10: error: no type named 'type' in 'boost::move_detail::is_rv<boost::rv<boost::log::v2_mt_posix::aux::light_function<void ()> > >' : T::type ~~~^~~~ See the full error logs: http://www.boost.org/development/tests/develop/developer/output/marshall-ma… http://www.boost.org/development/tests/develop/developer/output/teeks99-08b… http://www.boost.org/development/tests/develop/developer/output/teeks99-tes… I didn't change Boost.Log for quite some time, so there seems to have been some breaking change. Could this be fixed?

3 7

[thread] Build failures in develop
by Andrey Semashev 01 Oct '14

01 Oct '14

Hi, Boost.Thread currently fails to build on MSVC, which affects other libraries: http://www.boost.org/development/tests/develop/developer/output/teeks99-08d… Could it be fixed?

4 6

[modularization] request for a new modularization status for develop branch
by Vicente J. Botet Escriba 01 Oct '14

01 Oct '14

Hi Peter, could you upload a new modularization status, as in http://www.pdimov.com/tmp/report-d53f656/module-levels.html ? Best, Vicente

4 7