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

[teeks99][test] Test failures on MSVC 8-11
by Andrey Semashev 23 Nov '15

23 Nov '15

Hi, I'm seeing massive Boost.Log test failures on teeks99 with MSVC versions 8 through 11. The links to the failure messages lead to Boost.Test but the console output is not helpful (shows a successful compilation of a source file [1]). I can see Boost.Test tests are also failing massively on these compilers. Could this be fixed? [1]: http://www.boost.org/development/tests/develop/developer/output/ teeks99-08d-win2012R2-64on64-boost-bin-v2-libs-log-test-attr_attribute_set- test-msvc-11-0-dbg-adrs-mdl-64-thrd-mlt.html

6 18

[Config] boost::uint32_t != std::uint32_t on some targets
by Louis Dionne 23 Nov '15

23 Nov '15

Dear Boost, I recently fell into a trap where a program wouldn't compile because of a difference between `boost::uint32_t` and `std::uint32_t`. Specifically, I was trying to cross-compile from OS X to ARM, and the following program wouldn't compile #include <boost/cstdint.hpp> #include <cstdint> #include <type_traits> static_assert(std::is_same<std::uint32_t, boost::uint32_t>::value, ""); int main() { } I was building with arm-none-eabi-g++ -I /path/to/boost -std=c++11 -c main.cpp I have asked a question on StackOverflow [1], and I now understand why the two types are not required to be the same. However, I think it is a QOI issue that those two types are not the same, since it makes interoperating between `std::uint32_t` and `boost::uin32_t` more difficult. Is there a reason for this difference, and if not would it be reasonable to ensure that `boost::uint32_t == std::uint32_t` whenever the latter is defined, i.e. in C++11 and above? Regards, Louis [1]: http://stackoverflow.com/q/33857554/627587

3 2

build and install boost subset does not install the header files
by George Georgiev 22 Nov '15

22 Nov '15

Hi, I am trying to use github boost to obtain a subset of the libraries. I found that using the following subset of modules allows me to build boost_system. git submodule update --init tools/build || exit 1 git submodule update --init tools/inspect || exit 1 git submodule update --init libs/assert || exit 1 git submodule update --init libs/config || exit 1 git submodule update --init libs/core || exit 1 git submodule update --init libs/predef || exit 1 git submodule update --init libs/system || exit 1 git submodule update --init libs/utility || exit 1 The problem is that ./b2 ... install does not copy the header files. Is this a bug that I am hitting? My commands are: ./bootstrap.sh --prefix=../../boost --includedir=../../boost/include || exit 1 PATH=$CLANGBIN:$PATH \ ./b2 \ toolset=clang \ cxxflags="-std=c++11 -stdlib=libc++ -isystem/Developer/SDKs/MacOSX10.7.sdk/usr/include" \ linkflags="-stdlib=libc++" \ install threading=multi link=static Thanks, -g

2 3

[type_traits] Is_nothrow_move_constructible fails on mngw
by Andrzej Krzemienski 21 Nov '15

21 Nov '15

Hi, It looks like is_nothrow_move_constructible (in branch develop, on testers igaztanaga-gcc-4.6c++11 and igaztanaga-gcc-4.7c++11) fails the compilation rather than returning a true-false answer. <http://www.boost.org/development/tests/develop/igaztanaga-gcc-4-7c++11.html>I filed a ticket for it: https://svn.boost.org/trac/boost/ticket/11811 Reards, &rzej

1 0

[thread] Boost threading on VMware ESXi
by Fu ji 20 Nov '15

20 Nov '15

Hello, Is there anyone who try to use boost threading on ESXi (posix like system from VMware) or try to port it? Best regards, Damian

1 0

Re: [boost] boost log memory leak? Maybe it is my wrong.
by Jefferyliangmh 16 Nov '15

16 Nov '15

Many thanks andrey.semashev's reply. I send my demo application codes in BoostDemo.rar file. "logger" is my wrapped module by win32 dll. "BoostDemo" is my MFC test application, call logger code written in CMainFrame::CMainFrame() fuction, like this : AppLogger::log("this is test message"). Memory leak display in output windows when compiled BoostDemo application. 2015-11-16 2015-11-16 Jefferyliangmh 发件人：boost-request(a)lists.boost.org 发送时间：2015-11-16 01:00 主题：Boost Digest, Vol 4908, Issue 1 收件人："boost"<boost(a)lists.boost.org> 抄送： Send Boost mailing list submissions to boost(a)lists.boost.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.boost.org/mailman/listinfo.cgi/boost or, via email, send a message with subject or body 'help' to boost-request(a)lists.boost.org You can reach the person managing the list at boost-owner(a)lists.boost.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Boost digest..." The boost archives may be found at: http://lists.boost.org/Archives/boost/ Today's Topics: 1. boost log memory leak? Maybe it is my wrong. (=?UTF-8?B?5qKB5piO6L6J?=) 2. Re: boost log memory leak? Maybe it is my wrong. (Andrey Semashev) 3. Re: checking __INTEL_COMPILER == 9999 (Blower, Melanie) 4. Re: checking __INTEL_COMPILER == 9999 (Edward Diener) ---------------------------------------------------------------------- Message: 1 Date: Sat, 14 Nov 2015 19:31:28 +0800 From: "=?UTF-8?B?5qKB5piO6L6J?="<liang_mh(a)163.com> To: "boost"<boost(a)lists.boost.org> Subject: [boost] boost log memory leak? Maybe it is my wrong. Message-ID: <220730f2.126658.15105c3ab0c.Coremail.liang_mh(a)163.com> Content-Type: text/plain; charset="UTF-8" Way I want to use win32 dynamic link library encapsulates the boost.log, the wrapper DLL in MFC MSVC 2015 calls, memory leak in output window prompt; The same library in a console program calls, no such problems. I am very depressed. Who can help me? 2015-11-14 ??? ------------------------------ Message: 2 Date: Sun, 15 Nov 2015 00:05:28 +0300 From: Andrey Semashev <andrey.semashev(a)gmail.com> To: "boost(a)lists.boost.org" <boost(a)lists.boost.org> Subject: Re: [boost] boost log memory leak? Maybe it is my wrong. Message-ID: <CAEhD+6BH=Lnw1ghLwOVarXbYGDBqoNygzcWnML+TtU7mVbB1zQ(a)mail.gmail.com> Content-Type: text/plain; charset=UTF-8 On Sat, Nov 14, 2015 at 2:31 PM, ??? <liang_mh(a)163.com> wrote: > Way I want to use win32 dynamic link library encapsulates the boost.log, the wrapper DLL in MFC MSVC 2015 calls, memory leak in output window prompt; The same library in a console program calls, no such problems. > I am very depressed. Who can help me? If you work with Boost.Log the same way in both cases then it's likely a problem in your code and not the library. Otherwise I can't help without a minimal working code sample. ------------------------------ Message: 3 Date: Sun, 15 Nov 2015 13:05:27 +0000 From: "Blower, Melanie" <melanie.blower(a)intel.com> To: "boost(a)lists.boost.org" <boost(a)lists.boost.org> Subject: Re: [boost] checking __INTEL_COMPILER == 9999 Message-ID: <B3584E72CFEBED439A3ECA9BCE67A4EF40258FCC(a)fmsmsx116.amr.corp.intel.com> Content-Type: text/plain; charset="us-ascii" Thanks for all your suggestions and replies, I will work it on the Intel side. To Edward, at the bottom of my first message there's info about one of the failure modes. --Melanie ------------------------------ Message: 4 Date: Sun, 15 Nov 2015 10:43:25 -0500 From: Edward Diener <eldiener(a)tropicsoft.com> To: boost(a)lists.boost.org Subject: Re: [boost] checking __INTEL_COMPILER == 9999 Message-ID: <n2a971$msb$1(a)ger.gmane.org> Content-Type: text/plain; charset=windows-1252; format=flowed On 11/15/2015 8:05 AM, Blower, Melanie wrote: > Thanks for all your suggestions and replies, I will work it on the Intel side. To Edward, at the bottom of my first message there's info about one of the failure modes. Thanks, I see that now. ------------------------------ Subject: Digest Footer _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost ------------------------------ End of Boost Digest, Vol 4908, Issue 1 **************************************

1 0

checking __INTEL_COMPILER == 9999
by Blower, Melanie 15 Nov '15

15 Nov '15

A few years ago, circa 2010, the Intel 12.x compiler was released without having a correct value for the macro __INTEL_COMPILER. It was released using the development-only version number 9999 instead of the correct value 12xx. Later on, an Intel 12.x compiler was updated to remove this problem and the version number made correct. Meanwhile, since boost needed to add some workarounds, there was code added in a couple of boost files to check for version 9999. The check for 9999 in boost causes trouble in our current development compiler in-house testing. Is it possible to have this version checking removed from the boost sources? There's no advantage to boost users, and possibly a disadvantage if someone is still using a not-updated 12.x compiler. But hopefully that is unlikely, we're currently shipping our 16.x compiler. Here's the diff, diff --git a/include/boost/config/compiler/intel.hpp b/include/boost/config/compiler/intel.hpp index 7789b94..bbbf876 100644 --- a/include/boost/config/compiler/intel.hpp +++ b/include/boost/config/compiler/intel.hpp @@ -47,11 +47,7 @@ #undef BOOST_COMPILER #if defined(__INTEL_COMPILER) -#if __INTEL_COMPILER == 9999 -# define BOOST_INTEL_CXX_VERSION 1200 // Intel bug in 12.1. -#else # define BOOST_INTEL_CXX_VERSION __INTEL_COMPILER -#endif #elif defined(__ICL) # define BOOST_INTEL_CXX_VERSION __ICL #elif defined(__ICC) @@ -93,11 +89,7 @@ #include "boost/config/compiler/common_edg.hpp" #if defined(__INTEL_COMPILER) -#if __INTEL_COMPILER == 9999 -# define BOOST_INTEL_CXX_VERSION 1200 // Intel bug in 12.1. -#else # define BOOST_INTEL_CXX_VERSION __INTEL_COMPILER -#endif #elif defined(__ICL) # define BOOST_INTEL_CXX_VERSION __ICL #elif defined(__ICC) @@ -289,7 +281,7 @@ template<> struct assert_intrinsic_wchar_t<unsigned short> {}; // (Niels Dekker, LKEB, May 2010) // Apparently Intel 12.1 (compiler version number 9999 !!) has the same issue (compiler regression). #if defined(__INTEL_COMPILER) -# if (__INTEL_COMPILER <= 1110) || (__INTEL_COMPILER == 9999) || (defined(_WIN32) && (__INTEL_COMPILER < 1600)) +# if (__INTEL_COMPILER <= 1110) || (__INTEL_COMPILER == 1210) || (defined(_WIN32) && (__INTEL_COMPILER < 1600)) # define BOOST_NO_COMPLETE_VALUE_INITIALIZATION # endif #endif Here's the other checking for 9999 that I found. Not known to cause a problem. diff --git a/include/boost/regex/v4/regex_format.hpp b/include/boost/regex/v4/regex_format.hpp index e9006a7..bf2e552 100644 --- a/include/boost/regex/v4/regex_format.hpp +++ b/include/boost/regex/v4/regex_format.hpp @@ -180,7 +180,7 @@ private: } inline int toi(ForwardIter& i, ForwardIter j, int base) { -#if defined(_MSC_VER) && defined(__INTEL_COMPILER) && ((__INTEL_COMPILER == 9999) || (__INTEL_COMPILER == 1210)) +#if defined(_MSC_VER) && defined(__INTEL_COMPILER) && (__INTEL_COMPILER == 1210) // Workaround for Intel support issue #656654. // See also https://svn.boost.org/trac/boost/ticket/6359 return toi(i, j, base, mpl::false_()); The intel.hpp check for 9999 causes this problem, among others, float128 tests from (boost_multiprecision suite) fail due to workaround in intel.hpp fo 12.1 compiler that was released with __INTEL_COMPILER == 9999 Fails like this: $ "icpc" -c -xc++ -O0 -w1 -inline-level=0 -fPIC -m64 -DBOOST_ALL_NO_LIB=1 -DSLOW_COMPILER -DTEST_FLOAT128 -I"../../.." -I"../include" -c -o "../../../bin.v2/libs/multiprecision/test/test_tanh_float128.test/intl-lnx/dbg/dbg-symbl-\ off/test_tanh.o" "test_tanh.cpp" In file included from test_tanh.cpp(53): ../../../boost/multiprecision/float128.hpp(48): error: identifier "_Quad" is undefined typedef _Quad float128_type; ^ Thanks and regards, Melanie Blower

5 6

boost log memory leak? Maybe it is my wrong.
by 梁明辉 14 Nov '15

14 Nov '15

Way I want to use win32 dynamic link library encapsulates the boost.log, the wrapper DLL in MFC MSVC 2015 calls, memory leak in output window prompt; The same library in a console program calls, no such problems. I am very depressed. Who can help me? 2015-11-14 梁明辉

2 1

Boost 1.60.0 beta 1 Release Candidate 3 available for testing
by Marshall Clow 14 Nov '15

14 Nov '15

Release candidate files for 1.60.0 beta 3 are available at http://boost.cowic.de/rc/ 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. This helps ensure the candidates build OK before we push them out to SourceForge. Changes since rc1: * Boost.Sprit has been updated and Boost.Log now builds. * Boost.Math has been updated and now builds. [ Note: The RC2 files that I posted yesterday were incorrectly produced. RC3 is identical to what RC2 should have been -- end note ] Known issues: * Errors when building libraries for visual studio: test and type_erasure. * Boost.Test fails when building on Darwin with gcc 4.9.2 The files (and associated md5s) are: MD5 (boost_1_60_0_b1_rc3.7z) = cfac18348700d0e6c1a0e4418a57e9aa MD5 (boost_1_60_0_b1_rc3.tar.bz2) = d3cb5a59e5b38555096814a6bfbcb441 MD5 (boost_1_60_0_b1_rc3.tar.gz) = db9b011547b8933454d0dfe31f7b8551 MD5 (boost_1_60_0_b1_rc3.zip) = 216c7cd0c15c096ece24d2649a272b51 Thanks! -- The release managers

3 4

Seeking advice regarding inline namespaces
by Louis Dionne 13 Nov '15

13 Nov '15

Dear community, I am seeking advice regarding the usage of inline namespaces for header-only metaprogramming libraries. I was at Eric Niebler's talk on C++11 library design back in 2014, and I understand the problem that inline namespaces solve. I also read all of this past thread [1] on the mailing list, but did not find what I was looking for. I also understand how they can be useful for a normal header-only library __that would provide guarantees about ABI compatibility__. Indeed, if the ABI of the library changes from v1 to v2, then any client C1 exposing types from v1 in its interface and trying to link with a client C2 built against v2 will get a clean link-time error instead of a runtime error. Now, my question has several aspects: (1) How can you guarantee ABI compatibility from one version of a library to the next? IIUC, ABI can be broken by merely changing the size or the layout of a type, so guaranteeing backwards ABI compatibility means freezing those things in time, right? (2) Assuming that it is unreasonable for a library L to guarantee ABI compatibility from one version to the next, would there still be a reason to use inline namespaces to version that library? (3) When using inline namespaces to version a library (at all, not necessarily for header only libraries), are there other guidelines to follow? For example, I see that Eric Niebler's range-v3 library is all stuffed in the range/v3 subdirectory. IIUC, this would allow an eventual range-v4 library to cohabit with the range-v3 library, because people explicitly state which version of the library they're including. Is this the reason behind the v3 subdirectory? Any answer or pointer to answers is appreciated. Regards, Louis [1]: http://boost.2283326.n4.nabble.com/type-traits-general-Best-practice-for-in… -- View this message in context: http://boost.2283326.n4.nabble.com/Seeking-advice-regarding-inline-namespac… Sent from the Boost - Dev mailing list archive at Nabble.com.

2 6