- Boost - lists.preview.boost.org

github issues tracking listing
by Vicente J. Botet Escriba 09 May '16

09 May '16

Hi, I would like to have the possibility to have github issues in my boost modules (thread/chrono/ratio). I see that Boost.Hana has its own issue list. What I need to do to add the possibility to add issues? Best, Vicente

3 3

Boost 1.61.0 Release Candidate 1
by Vladimir Prus 09 May '16

09 May '16

The release candidates for the 1.61.0 release are now available at: http://boost.cowic.de/rc/boost_1_61_0_rc1.zip http://boost.cowic.de/rc/boost_1_61_0_rc1.7z http://boost.cowic.de/rc/boost_1_61_0_rc1.tar.bz2 http://boost.cowic.de/rc/boost_1_61_0_rc1.tar.gz The SHA256 checksums are as follows: dcd11a91a412b2e8a78678b38cb2a74857e61f9bfe2577de9fd70be770100d54 boost_1_61_0_rc1.7z 476937369c7a82103b734ccae85d35a523cdb7f8462c5f2fe1217ff0c8e2a7df boost_1_61_0_rc1.tar.bz2 e60dee39ebb29d24bf8a4ef9aec34dbb8c1b9b219d4737ea4b358f38b1aab2b7 boost_1_61_0_rc1.tar.gz e5f662f44a65c5c19450b8a1c07f75c7d5f16e58667871e856ba3984ec082006 boost_1_61_0_rc1.zip As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. The signed list of checksums is also attached, signed with the following key: https://pgp.mit.edu/pks/lookup?op=get&search=0xDA472E8659753BA4 Key fingerprint C5F0 F367 AA66 616F B839 806E DA47 2E86 5975 3BA4 Thanks! -- The release managers

14 38

[Style] Import a C function with wrong signature on purpose
by Klemens Morgenstern 08 May '16

08 May '16

Hi, for the boost.process library I need WinAPI functions which take an enumerator. Problem is: the forward-declaration doesn't work here, even with C++11. I.e. this code is still illegal, because X has a non-fixed type: enum X {}; enum X : typename std::underlying_type<X>::type ; I do however know which values the enum has take, thus I can redeclare it and have the reasonable expectation, that it will use the same underlying type. So theoretically, I could import the function into a seperate namespace (using extern "C") and use it, while having it declared with another enum type. I.e. you have in some C code the declaration: enum X { a,b,c}; void f(X); And I'll write in my code without including the other header: namespace import_thingy { extern "C" { enum X { a,b,c}; void f(X); } To be absolutely sure, I'd add an test, which asserts that the underlying types are equal. Now of course, that would never be accepted into the boost/winapi module, but I could just add this in my library. Would this be a dealbreaker for a library attempting to become a boost-library? If so, I'd need to put it into a source file and include windows.h there, but I'd really like the library to be header-only and under no circumstances include windows.h there. Thanks, Klemens

2 6

What to do about std::binary_function and std::unary_function?
by Nick Matteo 07 May '16

07 May '16

std::binary_function and std::unary_function are deprecated, and scheduled to be removed from the standard in C++17. That means it's possible that code using these might soon fail to compile when targeting this standard. These are still used throughout Boost, including by the libraries Accumulators, Algorithm, Bimap, Function, Functional, GIL, Graph, ICL, MPI, Polygon, and Xpressive. You can see all the uses I found in the 1.61 beta boost/ directory at http://kundor.github.io/ubinary_function_list.html . All that these classes do are provide the typedefs result_type, and argument_type (for unary_function) or first_argument_type and second_argument_type (for binary_function). In particular, they do not include a virtual operator(), so that one cannot accept a function object polymorphically as a std::binary_function&, for example. So, although it is conceivable that C++98-era user code might check for inheritance from std::binary_function, it seems rather unlikely: practically all uses should just depend on the typedefs being present (which is what the standard library has always done). With modern C++ standards, the availability of std::result_of, decltype, and std::function make these typedefs redundant, and references to them are being phased out of the standard library (starting with deprecation.) It seems to me that there are four main possibilities for removing these classes from Boost. (I'll talk about binary_function in the following, but it all applies equally to unary_function.) 1) Add some sort of compatibility macro to Boost.Config, to enable classes to inherit from std::binary_function if it is available, or add the appropriate typedefs if it is not. I don't think this is necessary. 2) Remove the inheritance from std::binary_function, and add the typedefs. This seems to be the default approach: it is used by the C++11 standard itself, and has also already been done by some Boost libraries, e.g. in container/string.hpp and in intrusive/priority_compare.hpp. The drawback here is increased verbosity. Instead of writing template <class T> struct functor : std::binary_function<T, T, bool> {...}; We must write template <class T> struct functor { typedef T first_argument_type; typedef T second_argument_type; typedef bool result_type; ... }; 3) A modification of approach 2: instead of manually adding the typedefs everywhere, make a base class to provide the typedefs somewhere in Boost. Then replace inheritance from std::binary_function<Arg1, Arg2, Result> with inheritance from boost::binary_function<Arg1, Arg2, Result>. 4) Just remove inheritance from std::binary_function (and don't provide typedefs.) This is the bold approach. The typedefs are redundant now: I think the only use in the standard library is by the deprecated std::not1/std:not2 and the deprecated binders std::bind1st/std::bind2nd (which are to be removed in C++17). This is the direction that the standard library is starting to head, with all uses of the typedefs deprecated and probably eventually removed, and even the provision of the typedefs optional in C++17 standard library function objects. This has already been done at least by Boost Interprocess in detail/mpl.hpp. Probably the best options are either (2) or (4). Should there be a default policy on what authors should do? Nick Matteo

5 6

Regression testing Clang/LLVM with VC14.
by degski 07 May '16

07 May '16

I have started a new thread as the other one "Testing of clang emualting the VC++ preprocessor on Windows" has become rather long and interlaced with less relevant musings. Here I would like to concentrate on the subject in the title. Sergey suggested I'd run regression tests, in the "other thread". I was hesitant at first, mostly due to the luke warm reception. Thanks to Google's simple coding of their spam filter, I actually missed the post by Niall Douglas of 4th of April. When it was referenced later and after I dug it from the archives, I became encouraged by the fact that maybe I wasn't all wrong and somebody within the community was actually thinking along similar lines as me. Following this I'd decided to take on regression testing. I chose to first simply test boost-develop against VC14, just to see how it goes. Some good, some bad. Was easy to set up (git already included with VC14, all what I needed to do was install python, which I normally have, but I'm having a new laptop). The bad, space required 44GB (advertised as 5GB). Possibly .pdb files (debugger symbols) are filling up disk-space uselessly. Next bad, the process finished with the following lines: # Done writing "C:\boost_develop\results\degski.xml". # Compressing "C:\boost_develop\results\degski.xml"... # Done writing "C:\boost_develop\results\degski.zip". # Uploading log archive "C:\boost_develop\results\degski.zip" to develop # <lambda> failed with message "[Errno 10013] An attempt was made to access a socket in a way forbidden by its access permissions" # Retrying (5 more attempts). # Uploading log archive "C:\boost_develop\results\degski.zip" to develop # <lambda> failed with message "[Errno 10013] An attempt was made to access a socket in a way forbidden by its access permissions" # Retrying (4 more attempts). # Uploading log archive "C:\boost_develop\results\degski.zip" to develop # <lambda> failed with message "[Errno 10013] An attempt was made to access a socket in a way forbidden by its access permissions" # Retrying (3 more attempts). # Uploading log archive "C:\boost_develop\results\degski.zip" to develop # <lambda> failed with message "[Errno 10013] An attempt was made to access a socket in a way forbidden by its access permissions" # Retrying (2 more attempts). # Uploading log archive "C:\boost_develop\results\degski.zip" to develop # <lambda> failed with message "[Errno 10013] An attempt was made to access a socket in a way forbidden by its access permissions" # Retrying (1 more attempts). # Uploading log archive "C:\boost_develop\results\degski.zip" to develop # <lambda> failed with message "[Errno 10013] An attempt was made to access a socket in a way forbidden by its access permissions" # Giving up. Traceback (most recent call last): File "run.py", line 71, in <module> runner(root) File "C:\boost_develop\boost_regression_src\regression.py", line 287, in __init__ self.main() File "C:\boost_develop\boost_regression_src\regression.py", line 624, in main getattr(self,action_m)() File "C:\boost_develop\boost_regression_src\regression.py", line 591, in command_regression self.command_upload_logs() File "C:\boost_develop\boost_regression_src\regression.py", line 538, in command_upload_logs lambda: File "C:\boost_develop\boost_regression_src\regression.py", line 663, in retry return f() File "C:\boost_develop\boost_regression_src\regression.py", line 546, in <lambda> self.dart_server ) File "C:\boost_develop\boost_regression_src\collect_and_upload_logs.py", line 430, in upload_logs upload_to_ftp( tag, logs_archive, ftp_proxy, debug_level, ftp_url ) File "C:\boost_develop\boost_regression_src\collect_and_upload_logs.py", line 256, in upload_to_ftp ftp = ftplib.FTP( ftp_site ) File "C:\Python27\lib\ftplib.py", line 120, in __init__ self.connect(host) File "C:\Python27\lib\ftplib.py", line 135, in connect self.sock = socket.create_connection((self.host, self.port), self.timeout) File "C:\Python27\lib\socket.py", line 575, in create_connection raise err socket.error: [Errno 10013] An attempt was made to access a socket in a way forbidden by its access permissions I've re-checked this page <http://www.boost.org/development/running_regression_tests.html>again, there's no mention of "registering" or something similar. Some tests must have failed, got prompted for starting the debugger twice (is the latter normal). This was a test-run (testing the testing), with VC14U2. Assuming the above can get sorted, I would in reality like to test Clang/LLVM (with VC14U2). I would like to ask (Niall Douglas in particular, I guess) what the suggested parameters to run.py should be for this combo. Should I target clang.exe or clang-cl.exe, develop or master. What about Clang/C2? How to reduce disk-space usage? degski

5 7

proposed new library "histogram"
by Hans Dembinski 06 May '16

06 May '16

Hi everybody, I recently added a new library called "histogram" to the Boost Incubator. I would like to advertise it a little here in the hope to find a person interested in reviewing it. I hope that shameless self-advertisement is not going against some rule of this list, but I am sure you will let me know. My background is in analysis of big data in the fields of particle physics and astroparticle physics. Boost is very popular among my peers, since it is a free, high-quality, rich, and very well maintained collection of libraries. There is a growing number of tools to do statistical analysis in Boost and I think this project would fit in nicely, and fill a gap. We work with histograms a lot, so that's why my interest came from. I am a senior programmer in C++ and Python with 10 years of experience. Guiding development through code reviews and tickets, as well as taking on responsibility for continuous maintenance, are natural for me. Naturally, I am willing to commit free time to maintain the project should it be accepted, and do my share of the work in this community. I put a lot of thought and effort into this project, the rationale and my design choices are explained in the documentation, which I wrote according to the advice given at the Boost Incubator website. The project is feature complete from my side. What it needs now is the input from the Boost community to round off possible edges and to make the interface rich enough for everybody. I am good at considering the user perspective, but I cannot anticipate everyone's needs. In case you got interested, here are the links: Incubator link: http://rrsd.com/blincubator.com/bi_library/histogram-2/?gform_post_id=1582 github link: https://github.com/HDembinski/histogram Best regards, Hans

6 15

1.61 release notes
by John Maddock 06 May '16

06 May '16

Is it too late to add release notes? Forgetfully yours, John.

2 1

Boost.Proto: specializing context::eval classes
by Brook Milligan 06 May '16

06 May '16

I am trying to use Boost.Proto with some user-defined function terminals. Following the documentation, this requires specialization of context::eval classes to handle new terminals. (Using the callable_context<> mechanism is too simplistic because that seems to require a uniform result_type.) However, doing as suggested (see the "Defining an Evaluation Context" section) does not compile when function terminals are involved. My solution is a new traits class that deduces the type of a terminal. This does allow successful specialization of context::eval on the type of terminal, even with functions. To illustrate this, I have attached a set of three files, one implementing an example proto function, one implementing the relevant metafunction, and one demonstrating both use cases: the one corresponding to the Boost.Proto documentation and the one corresponding to my alternative. I would appreciate comments on the following: - Is this a valid problem and a valid solution or have I missed a standard method using Boost.Proto that works to solve this pattern? - Is this the standard way of creating function terminals in Boost.Proto or have I done something there to trigger the problem? - If the answer to these questions indicates a missing feature within Boost.Proto, what is the process for fixing that? Thanks for any help you can offer. Cheers, Brook

1 0

[random] Using random_device needs to link to built library
by Edward Diener 06 May '16

06 May '16

Evidently if I use boost::random::random_device class in code I need to link to the built random library. Otherwise the random library is header only. Shouldn't this be mentioned somewhere in the Boost random documentation ?

1 0

[generic programming] header file for general "default" operations for C++ classes
by Walt Karas 05 May '16

05 May '16

In C++, a default assignment operator is generated for a class if all of its components (data members and base classes) have an assignment operator. There are plans in C++17 to do something similar for comparison operators. This header, in https://github.com/wkaras/C-plus-plus-library-default-operators , facilitates that, more generally, if there is an operation on all the components of a class, a single macro invocation can provide this operation on the class as well. A big drawback is that it's very intrusive into the class definition. Each class component must be defined using a macro, COMPOSITE_OP_MBR_T(int) i; for examle. The class will in truth be a template, with the template parameter being defaulted for normal usage. I don't know which, if any, existing Boot library this header would belong in.

3 4