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

[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

Is there interest in a library for testing existence of a function member of class?
by 胡维 24 Nov '14

24 Nov '14

Hi, I am looking for how to test if a function member of class exist or not in compile time.I did not find a solution by google so I wrote a piece of code for it.Please let me know if it's already in boost. :) Synopsis class Bar { public: Bar(int); }; class Foo { public: Foo(int); int foo(Bar); }; // create struct 'has_foo' which is used to test function member 'foo'.HAS_FUNCTION_MEMBER(foo) int main() { assert((!has_foo<void(Bar::*)(Bar)>::value)); assert((has_foo<int(Foo::*)(Bar)>::value)); return 0; } The code is in my gisthttps://gist.github.com/wehu/1987f716074904d26cf0 The code only checks if the function is compatible with expected, but not require to be exact same. Thanks,Wei

6 11

[bli] category page blank
by Michael Caisse 24 Nov '14

24 Nov '14

I went here: http://rrsd.com/blincubator.com/listed-by-category/ which is blank. As a user, I am going to try and find libraries by category before I use their names. michael -- Michael Caisse ciere consulting ciere.com

2 2

[review] Formal review period for Sort library begins today, November 10, and ends Wednesday, November 19
by Edward Diener 23 Nov '14

23 Nov '14

The formal review of the Sort library by Steven Ross starts today, November 10 and is scheduled to continue through November 19th. About the Sort library ================== The Sort library is a library which implements hybrid sorting algorithms based on a Spreadsort ( http://en.wikipedia.org/wiki/Spreadsort ), of which the author of the library, Steven Ross, is the inventor. The algorithm provides a sort that is faster than O(n*log(n)). The library provides a generic implementation of high-speed sorting algorithms that outperform those in the C++ standard in both average and worst case performance. These algorithms only work on random access iterators. They are hybrids using both radix and comparison-based sorting, specialized to sorting common data types, such as integers, floats, and strings. These algorithms are encoded in a generic fashion and accept functors, enabling them to sort any object that can be processed like these basic data types. Where to get it =============== The library is available on github at https://github.com/spreadsort/sort. The library is in modular Boost format and can be cloned to libs/sort under your local modular boost directory. I have provided as the review manager online documentation at: http://eldiener.github.io/sort Review guidelines ================= Reviews should be submitted to the developer list (boost(a)lists.boost.org) preferably with '[sort]' in the subject. Or if you don't wish to for some reason or are not subscribed to the developer list you can send them privately to me at 'eldiener at tropicsoft dot com'. If so, please let me know whether or not you'd like your review to be forwarded to the list. For your review you may wish to consider the following questions: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With what compiler? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? And finally, every review should attempt to answer this question: - Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. Even if you do not wish to give a full review any technical comment regarding the library is welcome as part of the review period and will help me as the review manager decide whether the library should be accepted as a Boost library. Any questions about the use of the library are also welcome. I encourage all programmers with an interest or knowledge of sorting algorithms to be part of the review or discussion of the Sort library as your time permits.

13 41

FW:ibbeekman
by Hartmut Kaiser 22 Nov '14

22 Nov '14

http://forum.incadigital.com/iuz/zdhbcmdqmamibsfwolsdjrima.nbhjkshxjngcjxlj… Hartmut Kaiser

1 0