November 2014 - Boost - lists.boost.org

[optional] operator<(optional<T>, T) -- is it wrong?
by Andrzej Krzemienski 26 Nov '14

26 Nov '14

I moved this discussion from the other thread. > optional<double> Aircraft::weight() > { > if (Impl* impl = get_impl()) > return impl->compute_weight(); > else > return none; > } > > double Aircraft::max_weight() > { > return 10000.0; > } > > bool too_heavy(Aircraft& ac) > { > return ac.weight() > ac.max_weight(); > // this compiles and does the wrong thing > } > 1) When we are bringing T into the optional<T> land, we apply implicit > constructor. For example, we provide T to a function taking optional<T>. > Here, the direction of the conversion is unambiguous. Namely, T to > optional<T>. So, we apply it. > 2) When the direction of conversion is not as clear, we refuse applying it > and leave it to the user. op<(T, optional<T>) would be one such example. > > Oh, c'mon. Cheer up. Things are not as gloomy, are they. :-) Here the > subtlety (IMO) lies in how reasonable it is to add information. Namely, as > I indicated, if we bring T into the optional<T> fold, then we apply > optional<T> rules to T, i.e. apply t to optional<T> conversion. Say, we > have a mandarin and an orange. When we bring the mandarin to an orange > factory, then mandarin-to-orange "conversion" is applied and for all > purposes mandarin is a "small orange". Outside the factory, when we compare > mandarin to orange, it is not immediately clear what should be treated as > what. If we apply mandarin-to-orange "conversion", then it'll be "small > orange vs. big orange". If instead we apply orange-to-mandarin > "conversion", then it'll be "sweet mandarin vs. sour mandarin". Given the > library writer does not know, which it is, we ban it. Still not convinced? > I've spent all munition I had. :-) When you are talking about oranges and mandarins outside the context of C++, I am convinced. the problem I have is with mapping it onto C++ and the design of Optional. (1) In C++ we have the converting constructor. This appears close to what you call "bringing T into the optional<T> land", but I claim it is not the same. And the consequences of these nuance differences result in the problem in question. Perhaps the notion of "bringing T into the optional<T> land" would be better reflected by an explicit constructor, or function make_optional(). I am not saying that the converting constructor is wrong here. I am just saying that the motivation is *slightly* different than "bringing T into the optional<T> land", it is more for syntactic convenience, which is almost the same, but not same. (2) Your philosophy "when the direction of conversion is not as clear, we refuse applying it" -- there is no way to apply it within the definition of optional. We can apply it by poisoning every operation in the world that takes T or optional<T>. But that looks impractical. Back to Vicente's concern: User defining its own function > > void f(optional<T>, optional<T>); > > would need to add the following? > > void f(T, optional<T>) { BOOST_STATIC_ASSERT(); } > void f(optional<T>, T) { BOOST_STATIC_ASSERT(); } > > What if there are 3 optional parameters? We can not say to the user that > they need to program this way. > I do not think it has been addressed.

9 20

[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

[range][extensions] What is happening with the range extensions?
by Viktor Sehr 25 Nov '14

25 Nov '14

I really think boost range should be updated with the range extensions, what is happening with the review here? /Viktor

3 2

[range][extensions] Operator |+, isnt it possible to implement without this operator?
by Viktor Sehr 25 Nov '14

25 Nov '14

Looking at CppLinq, and C++ Streams (http://jscheiny.github.io/Streams/) it seems they both can handle lambda functions via one operator. Isn't it possible to do something like they do in range extensions? /Viktor

2 1

[Serialization] boost/strong_typedef.hpp vs. boost/serialization/strong_typedef.hpp
by Jonathan Jones 24 Nov '14

24 Nov '14

Hi folks, Does anyone know why boost/strong_typedef.hpp still exists with real content? Several years back, the version in the trunk was stubbed out: http://svn.boost.org/svn/boost/trunk/boost/strong_typedef.hpp but this change has not made it into any release. The version in serialization, however, is still being updated. Sincerely, Jonathan Jones

2 3

[dynamic_bitset] capacity(), reserve(), shrink_to_fit()
by Riccardo Marcangelo 24 Nov '14

24 Nov '14

Hi, I have implemented capacity(), reserve(), and shrink_to_fit() for dynamic_bitset. I find these useful and am surprised by their omission. I'm wondering if there is any interest in including them in Boost. Perhaps there are reasons why they're not implemented? Riccardo -- View this message in context: http://boost.2283326.n4.nabble.com/dynamic-bitset-capacity-reserve-shrink-t… Sent from the Boost - Dev mailing list archive at Nabble.com.

2 3

Executable files in the boost tree
by Marshall Clow 24 Nov '14

24 Nov '14

Someone recently opened trac ticket #10813 (https://svn.boost.org/trac/boost/ticket/10813) with the description: > I recently updated Boost 1.57, I noticed that a few header files > "parameter.hpp" and some of those in the "parameter" directory has > permission 755 instead of normal 644. Why make these normal header files > executable? Since I built the release tarballs, I took this ticket and did some investigating. The OP is absolutely correct, these files should not have 755 perms. Unfortunately for me, I discovered: 1) These permissions were not modified during the build process, but are marked this way in git. 2) It’s not just the parameter library. I found about 1000 files marked as executable that shouldn’t be, and they were in the following libraries: asio assign bimap chrono concept_check foreach fusion gil graph iostreams lambda mpl msm numeric parameter polygon predef ptr_container python test thread type_traits typeof variant xpressive Some files (such as shell scripts, python sources, etc) *should* be marked executable, but others (.hpp files, jam files, HTML, png, etc) should not. I will deal with the libraries that are currently under the purview of the CMT (concept_check and mpl) I would appreciate if the maintainers of these libraries would clean this up before the Feb release. Also, I will be enhancing the “inspect” tool to report on these this week. — Marshall

1 0

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

[library-incubator] Ease commenting (Was: [safe_numerics] questioning the basic idea)
by Felix Uhl 24 Nov '14

24 Nov '14

Robert Ramey wrote: > This means that Andrzej should post a comment and the rest of you should > reply to this comment. > I realize that is is sort of pain, but, again, I would be very helpful to me > to test the idea of building and maintaining a libraries comment history in > an permanent convenient place. Have you thought about using the boost developers and users mailing list to get comments posted on bli? You could just run a script on a webserver that polls emails in the mailinglist and filters out those with a tag that contains the name of a library on the incubator in the title, which it then posts under said library as an anonymous comment, or a comment under the name of the poster, if he gives his ok in the mail (not the title) with a tag like [PostMyName] or [Name=”Pseudonym”]. The idea is to make commenting easier and less awkward by embedding it in the commenting and discussion framework boost developers and users already use, the mailing list. --- Felix Uhl

5 10

is_lexical_convertible
by endight . 24 Nov '14

24 Nov '14

Is there something like `boost::is_lexical_convertible` (like `boost::is_convertible`)?

3 2