- Boost - lists.boost.org

[lockfree] _ENABLE_ATOMIC_ALIGNMENT_FIX for VS 2015 Update 2
by Stephan T. Lavavej 11 May '16

11 May '16

Hi, While running Boost.Lockfree's tests, one of our compiler devs encountered the following failure: freelist_test.cpp c:\wcfb01\binaries\x86chk\inc\atomic(659): error C2338: You've instantiated std::atomic<T> with sizeof(T) equal to 2/4/8 and alignof(T) < sizeof(T). Before VS 2015 Update 2, this would have misbehaved at runtime. VS 2015 Update 2 was fixed to handle this correctly, but the fix inherently changes layout and breaks binary compatibility. Please define _ENABLE_ATOMIC_ALIGNMENT_FIX to acknowledge that you understand this, and that everything you're linking has been compiled with VS 2015 Update 2 (or later). c:\wcfb01\binaries\x86chk\inc\atomic(669): note: see reference to class template instantiation 'std::_Atomic_base<_Ty,4>' being compiled with [ _Ty=boost::lockfree::detail::tagged_index ] e:\boost\boost\boost\lockfree\detail\freelist.hpp(608): note: see reference to class template instantiation 'std::atomic<boost::lockfree::detail::tagged_index>' being compiled e:\boost\boost\boost\lockfree\detail\freelist.hpp(609): note: see reference to class template instantiation 'boost::lockfree::detail::fixed_size_freelist<T,NodeStorage>' being compiled call "C:\WCFB01\binaries\x86chk\bin\i386\vcvarsall.bat" x86 >nul cl /Zm800 -nologo @"..\bin.v2\libs\lockfree\test\freelist_test.test\msvc-latest\debug\threading-multi\freelist_test.obj.rsp" ...failed compile-c-c++ ..\bin.v2\libs\lockfree\test\freelist_test.test\msvc-latest\debug\threading-multi\freelist_test.obj... with the following type: class tagged_index { public: typedef boost::uint16_t tag_t; typedef boost::uint16_t index_t; protected: index_t index; tag_t tag; }; This is by design - your tagged_index has align 2, size 4, triggering the need for my atomic alignment fix. As the static_assert advises, your code needs to define _ENABLE_ATOMIC_ALIGNMENT_FIX in order to pass. If this has already been fixed in 1.61.0, then that's great (I haven't checked). Thanks, STL

5 14

Getting started with boost in Codeblocks
by Karan Kapoor 11 May '16

11 May '16

Hi, This is Karan Kapoor,a 3rd year UG student at NSIT. Can somebody guide me how to get started with boost libraries while i am using codeblocks. Karan Kapoor

2 1

Boost.Random subtract_with_carry doesn't like m == numeric_limits<result_type>::digits
by Billy O'Neal (VC LIBS) 10 May '16

10 May '16

Hello, Boost folks. I found a bug in subtract_with_carry_engine while fixing a bug in MSVC++'s implementation of the same, where m == numeric_limits<result_type>::digits. Consider the following: #include <stdlib.h> #include <stdio.h> #ifdef USE_BOOST #include <boost/random/subtract_with_carry.hpp> using namespace boost::random; #else #include <random> using namespace std; #endif template <typename Engine> typename Engine::result_type run_10k(Engine engine) { for (int i = 0; i < 9999; ++i) { engine(); } return engine(); } int main() { subtract_with_carry_engine<unsigned long long, 64, 10, 24> ull_swc; ull_swc.seed(0x12341234'00000000); printf("0x%016llX\n", run_10k(ull_swc)); } MSVC++ said: 0xFCF0A4776BA0A6A8 Libstdc++ says: 0x01316AEA3646F686 Libc++ says: 0x01316AEA3646F686 Boost 1.60.0/libc++ + Clang says: 0x69E18848FE1BD36D Boost 1.60.0/libstdc++ + g++ says: 0x1DD6C263C41EEED0 MSVC++'s bug was that we did the underflow check incorrectly resulting in the carry bit always being set if m == numeric_limits<result_type>::digits. I fixed that and MSVC++ will agree with libstdc++ and libc++ in the next update; but boost's behavior here is still strange. Hope that helps, Billy Robert O'Neal III SDE II - Visual C++ Libraries bion(a)microsoft.com

2 1

[thread] API for getting/setting thread name in Boost?
by Bob Summerwill 10 May '16

10 May '16

I've also been working with an external developer which is getting Ethereum C++ working on Alpine Linux, as a statically linked executable using musl, rather than glibc. One rather confusing element was related to setting and getting thread names, which is the process of working through this issue, I find appears not to have made its way into either Boost or the C++11 standard library, though it must be a very common cross-platform use-case. https://github.com/ethereum/libweb3core/pull/73 https://github.com/ethereum/libweb3core/pull/73/files I've just added this comment-block, while fixing the issue: /// Set the current thread's log name. /// /// It appears that there is not currently any cross-platform way of setting /// thread names either in Boost or in the C++11 runtime libraries. What is /// more, the API for 'pthread_setname_np' is not even consistent across /// platforms which implement it. /// /// A proposal to add such functionality on the Boost mailing list, which /// I assume never happened, but which I should follow-up and ask about. /// http://boost.2283326.n4.nabble.com/Adding-an-option-to-set-the-name-of-a-bo… /// /// man page for 'pthread_setname_np', including this crucial snippet of /// information ... "These functions are nonstandard GNU extensions." /// http://man7.org/linux/man-pages/man3/pthread_setname_np.3.html /// /// Stack Overflow "Can I set the name of a thread in pthreads / linux?" /// which includes useful information on the minor API differences between /// Linux, BSD and OS X. /// http://stackoverflow.com/questions/2369738/can-i-set-the-name-of-a-thread-i… /// /// musl mailng list posting "pthread set name on MIPs" which includes the /// information that musl doesn't currently implement 'pthread_setname_np' /// https://marc.info/?l=musl&m=146171729013062&w=1 void setThreadName(std::string const& _n); Would I be right in assuming that this never happened? http://boost.2283326.n4.nabble.com/Adding-an-option-to-set-the-name-of-a-bo… If not, where can I log an issue to request that we revisit that? From what I can see, everybody is likely just cut-and-pasting much the same code for this functionality. http://stackoverflow.com/questions/10121560/stdthread-naming-your-thread Cheers, Bob Summerwill -- bob(a)summerwill.net

2 7

[config] Boost and the Intel (Linux) compiler
by Bob Summerwill 10 May '16

10 May '16

I am a developer on the Ethereum C++ client ( https://github.com/ethereum/webthree-umbrella) and have been working with an external developer on adding support to the codebase for building with the Intel Compiler on Ubuntu. Here is the full log of pain :-) https://github.com/ethereum/webthree-umbrella/issues/396 We've already merged various changes, and we appear to be getting down to the real hard ones, which are now mainly clustered around build issues with boost::multiprecision and seeming limitations with the Intel compiler and Like so: /home/libweb3core/libdevcore/Base64.h(48): error: no suitable conversion function from "boost::multiprecision::number<boost::multiprecision::backends::cpp_int_backend<160U, 160U, boost::multiprecision::unsigned_magnitude, boost::multiprecision::unchecked, void>, boost::multiprecision::et_off>" to "unsigned int" exists unsigned r = (unsigned)(a - a / 36 * 36); // boost's % is broken ^ detected during instantiation of "std::string dev::toBase36(const dev::FixedHash<N> &) [with N=20UL]" at line 114 of "/home/libethereum/libethcore/ICAP.cpp" This appears to be the key observation: https://github.com/ethereum/webthree-umbrella/issues/396#issuecomment-20659… "In summary, the intel platform supports this "convert_to" member function, but does not support implicit conversion of boost multiprecision types" Has anybody worked with Boost and the Intel compiler who might have some further insight into whether there is some way in which the Intel compiler "warts" can be handed within Boost? Or are we stuck with these nasty diffs/workarounds? https://github.com/ethereum/libethereum/pull/224/files https://github.com/ethereum/libweb3core/pull/68/files Cheers, Bob Summerwill Developer, Ethereum Foundation -- bob(a)summerwill.net

3 4

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