- Boost - lists.boost.org

Showstopper for Boost 1.56?
by Niall Douglas 10 Aug '14

10 Aug '14

Is anyone else seeing this warnings spew on Boost 1.56 beta when compiled with clang 3.4? https://ci.nedprod.com/view/Boost.AFIO/job/Boost.AFIO%20Build%20POSIX_ Linux64_clang%203.4/11/consoleFull GCC 4.8 produces no such spew. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

10 39

Boost 1.56.0 has been released
by Marshall Clow 09 Aug '14

09 Aug '14

Release 1.56.0 of the Boost C++ Libraries is now available. These open-source libraries work well with the C++ Standard Library, and are usable across a broad spectrum of applications. The Boost license encourages both commercial and non-commercial use. This release contains one new library and numerous enhancements and bug fixes for existing libraries. === Modularization === Boost version control has migrated to a system using git submodules. This shouldn't make too much of a difference to users, although the directory structure is now a bit different. Parts of some libraries have been moved into different modules, and several new modules have been extracted from existing code. All header paths should remain the same. The new modules are: • Assert: Customizable assert macros. Maintained by Peter Dimov. • Core: Core utilities used by other libraries, with minimal dependencies. Maintained by Peter Dimov, Glen Fernandes and Andrey Semashev. • Lexical_Cast: General literal text conversions, such as an int represented a string, or vice-versa, from Kevlin Henney. • Throw_Exception: A common infrastructure for throwing exceptions from Boost libraries, from Emil Dotchevski. • Winapi: Windows API declarations without <windows.h>, for internal Boost use. === New Libraries === • Align: Memory alignment functions, allocators, and adaptors, from Glen Fernandes. • Type_Index: Runtime/Compile time copyable type info, from Antony Polukhin. For details, including download links, see http://www.boost.org/users/news/version_1.56.0 You can also download directly from SourceForge: http://sourceforge.net/projects/boost/files/boost/1.56.0/ To install this release on your system, see http://www.boost.org/doc/libs/release/more/getting_started/index.html Thanks, --The Boost release team Vladimir Prus Rene Rivera Marshall Clow Eric Niebler Daniel James Beman Dawes

8 7

[config] Macro for initializer-list literals?
by Peter Dimov 09 Aug '14

09 Aug '14

We have BOOST_NO_CXX11_HDR_INITIALIZER_LIST, which tells us whether we can #include <initializer_list> and use std::initializer_list; we also have BOOST_NO_CXX11_UNIFIED_INITIALIZATION_SYNTAX, which tells us whether we can use X{ 1, 2 }, or X x{ 1, 2}. But we don't have a macro that tells us whether this: struct X { int a, b; }; void f( X x ) { } int main() { f( { 1, 2 } ); } is supported. This is a problem for http://www.boost.org/development/tests/develop/developer/output/Sandia-inte… because the test is guarded by BOOST_NO_CXX11_UNIFIED_INITIALIZATION_SYNTAX: https://github.com/boostorg/smart_ptr/blob/develop/test/allocate_shared_arr… and this macro is not set for Intel 13.1 in C++0x mode. Presumably the compiler allows braced initialization, but not braced literals.

1 0

[1.56.0] Release candidates available
by Marshall Clow 08 Aug '14

08 Aug '14

Release candidate files for 1.65.0 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. The files (and associated md5s) are: MD5 (boost_1_56_0_rc1.7z) = 0ac22b92b24209286d48e4c41925cd9f MD5 (boost_1_56_0_rc1.tar.bz2) = 5b5bfa99244b1ac5737323decceb19c2 MD5 (boost_1_56_0_rc1.tar.gz) = 2047cdd4e09cda34e7f10fec0f821175 MD5 (boost_1_56_0_rc1.zip) = 0c544f6acc85550b15cdc9221f2ac0c9 Thanks! -- The release managers

13 23

A quieter clang build
by Marshall Clow 08 Aug '14

08 Aug '14

I added the following lines to my user-config.jam: using clang-darwin : noC99W : "/usr/bin/clang++" : <cxxflags>"-Wno-c99-extensions -Wno-variadic-macros" ; and then built the 1.56.0 release with "toolset=clang-darwin-NoC99W", and lo! there were a *sane* amount of warnings. Just a quick tip for people drowning under the warnings. — Marshall P.S. I’m leaving for vacation this afternoon, but would like to pick this back up when I return.

1 0

Regression testing unobservable behavior?
by Beman Dawes 08 Aug '14

08 Aug '14

Certain library function errors are difficult to regression test because it is not obvious how to observe their behavior in a test framework. Examples include: 1) Selection of correct overload or template specialization when the only difference in effect is a performance enhancement. 2) Verification that BOOST_ASSERT fires when a precondition is violated. 3) Verification that I/O and other operating system API errors are handled correctly. 4) More generally, something occurs in a function under test that is hard to observe but needs to be verified. How do other boost developers address these regression testing needs? It seems to me all of the examples can be solved by creating some form of back channel (or channels) to pass information between caller and callee functions. All require getting additional information from a function after it is called. (3) also requires passing additional information to a function when it is called. An ideal solution requires: * Works in the existing Boost regression test framework. So much the better if it works in other test frameworks. * Does not violate the ODR or depend on undefined behavior. * Does not alter the interface of the function under test. * Does not generate any code except when the function is actually being tested. * Does not require that each test case be run as a separate program. * Works even if the function under test is noexcept. * Is lightweight, utterly reliable, and has few if any dependencies beyond those already present. --Beman

3 5

Error Handling issue in NonCopyable Interface
by John Pallino 08 Aug '14

08 Aug '14

Hello, I am having error handling issues that is in regards to the NonCopyable Interface library. Here is the source code: #include <boost/noncopyable.hpp> #include <iostream> class A : public boost::noncopyable { public: A() { std::cout << "In A \n" << std::endl; } class AnError {}; void Func() { if () //error condition throw AnError(); } }; int main() { try { A object1; A object2(object1); object1 = object2; } catch (A::AnError) { //tell user about error. } return 0; } } So far, I have tried on the forums in CPlusPlus.com and MSDN, but no responses. Since that Boost.org has created and authored the NonCopyable.hpp library, I would like to get some assistance. Can anybody give me some solutions on how to suppress any compilation errors? Thanks in advance. Email me back at the Cc: if you have any answers or comments with detailed information and examples. John P.

2 1

The release branch is now available for merging
by Marshall Clow 07 Aug '14

07 Aug '14

Now that 1.56.0 is out the door …. — Marshall

2 2

[1.56.0] Release Candidate 3 available
by Marshall Clow 07 Aug '14

07 Aug '14

We've created a third release candidate to fix a one more issue with Boost.Range. The files for 1.56.0 RC3 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. The files (and associated md5s) are: MD5 (./boost_1_56_0_rc3.7z) = b7a72a6a6f487fa445333b4e115c6171 MD5 (./boost_1_56_0_rc3.tar.bz2) = a744cf167b05d72335f27c88115f211d MD5 (./boost_1_56_0_rc3.tar.gz) = 8c54705c424513fa2be0042696a3a162 MD5 (./boost_1_56_0_rc3.zip) = fc16da21d641e03715a4144cb093964e Thanks! -- The release managers

7 10

Clang, -pedantic, and variadic macro warnings
by Edward Diener 06 Aug '14

06 Aug '14

My test show that if you compile with clang, pass the '-pedantic' option, and also pass 'std=c++0x' or 'std=c++11', that the many warnings about variadic macro use do not show in the output. I know there was a discussion and an assertion that the warnings do show in the output oonce '-pedantic' is passed as a compiler option even though a 'std=xxx' is passed that covers variadic macros, but I am not seeing that in my tests. If anybody else can tell me of a Boost library build where clang is the compiler, 'pedantic' is passed, and the appropriate 'std=xxx' to cover variadic macro use is passed, and the clang compiler warnings about using variadic macros show up, it would be appreciated.

1 0