- Boost - lists.boost.org

[build][wave][thread][date-time] 1.65.0 clang on Windows build failures
by Konstantin Ivlev 02 Sep '17

02 Sep '17

Hi, I am trying to compile boost 1.65.0 on Windows via clang 4.0.1 with the following user-config.jam: using clang : 4.0 : "C:/Program Files/LLVM/bin/clang.exe" : <compileflags>-fmsc-version=1910 <ranlib>"C:/Program Files/LLVM/bin/llvm-ranlib.exe" <archiver>"C:/Program Files/LLVM/bin/llvm-ar.exe" <linkflags>-fuse-ld=lld ; and there are few issues. 1. clang.jam ignores ranlib/archiver settings. currently there is the PR https://github.com/boostorg/build/pull/232 against clang-darwin.jam, and I suppose the same should be applied to the clang-linux.jam. 2. there are numerous errors in boost wave: .\boost/wave/grammars/cpp_expression_grammar.hpp:829:18: error: case value evaluates to -804257404, which cannot be narrowed to type 'unsigned int' [-Wc++11-narrowing] case T_CPPCOMMENT: // contains newline (about 100 errors of such kind for various enumerations) 3. WinAPI-related errors in boost::date_time & boost::thread, e.g. In file included from libs\coroutine\src\windows\stack_traits.cpp:23: In file included from .\boost/thread.hpp:13: In file included from .\boost/thread/thread.hpp:12: In file included from .\boost/thread/thread_only.hpp:15: In file included from .\boost/thread/win32/thread_data.hpp:10: In file included from .\boost/thread/thread_time.hpp:10: In file included from .\boost/date_time/microsec_time_clock.hpp:23: .\boost/date_time/filetime_functions.hpp:57:46: error: conflicting types for 'GetSystemTimeAsFileTime' __declspec(dllimport) void __stdcall GetSystemTimeAsFileTime(FILETIME* lpFileTime); ^ C:\Program Files (x86)\Windows Kits\10\include\10.0.15063.0\um\sysinfoapi.h:159:1: note: previous declaration is here GetSystemTimeAsFileTime( ^ seems like stack_traits.cpp unconditionally includes windows.h, while BOOST_USE_WINDOWS_H is not defined in case of clang build, so filetime_functions.hpp defines its own WinAPI prototypes. probably shall be somehow fixed in boost config? any advice on how to proceed with these issues?

3 4

[release] Boost 1.65.1 Release Candidate 1
by Daniel James 01 Sep '17

01 Sep '17

The release candidates for the 1.65.1 release are now available at: <https://dl.bintray.com/boostorg/release/1.65.1/> The SHA256 checksums are as follows: 9b440d8167043c8d70326d8a5d4df98a59abb40be7d68f51e75ea95ea24d84f3 boost_1_65_1_rc1.7z fbd5663c748a88479adb4106c8a12009b149e602dec4b40a4a778381a33cf3ce boost_1_65_1_rc1.tar.bz2 b1b18d658cc0ff8a5030b29f4ed41de1826281fcb52fc1073b106c5802a570bd boost_1_65_1_rc1.tar.gz 542624352b2c3fd6a76c98624f90d2c0e62dd810ec6cc9fdae831677c7aa1fbf boost_1_65_1_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.

4 7

[regression] [date_time] Tests table damaged
by Andrey Semashev 01 Sep '17

01 Sep '17

Hi, It looks like Boost.DateTime table got damaged: http://www.boost.org/development/tests/develop/developer/date_time.html One of the table cells contains this text: lin/home/www/live.boost.org/common/code/boost_archive.php:149: Cannot modify header information - headers already sent by (output started at /home/www/live.boost.org/common/code/boost_archive.php:91) and there are no test results visible past this cell.

2 2

[iterator] generator_iterator vs. function_input_iterator
by Andrey Semashev 01 Sep '17

01 Sep '17

Hi, There seems to be two nearly equivalent components in Boost.Iterator: generator_iterator (moved from Boost.Utility) and function_input_iterator. Both are input iterators wrapping a function object, which result is used as the dereferenced value. The difference is: - generator_iterator always creates an instance of the element type while function_input_iterator does that lazily; - function_input_iterator uses result_of while generator_iterator relies on C++03 T::result_type - equality comparison is different: generator_iterators compares equal if both refer to the same generator and cached element instances are equal while function_input_iterator uses an additional state (which can be viewed as an index) for comparison instead of the cached element. So basically, they are the same thing. generator_iterator looks a bit more dated and IMHO its comparison implementation is not as robust as that of function_input_iterator, so maybe we should deprecate it?

4 6

[release] Starting 1.65.1
by Daniel James 30 Aug '17

30 Aug '17

Hello all, As no one objected, I'm starting work on a point release. This release should only include fixes and documentation changes, and please keep your changes to a minimum - I'm not looking for any minor changes, such as compiler warning fixes. If I can cleanly incorporate changes from your master branch, let me know the commit hash. Otherwise, please create a branch from the boost-1.65.0 tag called 'fixes/1.65' and cherry pick the required changes onto that branch. All changes should already be included in both your develop and master branches. If a commit doesn't cleanly apply, then we'll have to work something out, but please try to avoid that. If you want any help with this, let me know. The quickbook file for the release notes is at: https://github.com/boostorg/website/blob/master/feed/history/boost_1_65_1.q… I'll set a schedule in the next few days, but I want to get the changes finalised as soon as possible, so don't wait around, I think it will have to be pretty tight. thanks for you help, Daniel

10 27

GitHub issues for superproject
by Olaf van der Spek 30 Aug '17

30 Aug '17

Hi, James wrote: > I would have opened up a github issue on the superproject to track this and resolve it, however the "issues" section is not activated for the superproject. Why's this? IMO it'd be nice to track issues there. As a Boost user I vastly prefer GitHub over Trac. -- Olaf

1 0

Superproject 1.55.0 tags incorrect for libs/uuid?
by James E. King, III 29 Aug '17

29 Aug '17

Hello, Someone reported a discrepancy in boost trac that needs to be investigated by folks on the superproject team. What is claimed is that the superproject tag for boost-1.55 contains commit id 8c395a888c2d77bdc91e956ef24a07c0c87cdd24 for uuid, however this commit id does not exist. The tag id in the boost/uuid repository points to commit 98cf8322aef86e6398dbac7f9cd6bf766621d645. I would have opened up a github issue on the superproject to track this and resolve it, however the "issues" section is not activated for the superproject. https://svn.boost.org/trac10/ticket/13071 Instructions given to reproduce the issue are as follows: git clone https://github.com/boostorg/boost.git cd boost git submodule init libs/uuid git checkout boost-1.55.0 git submodule update libs/uuid and the last step will fail with: fatal: reference is not a tree: 8c395a888c2d77bdc91e956ef24a07c0c87cdd24 Unable to checkout '8c395a888c2d77bdc91e956ef24a07c0c87cdd24' in submodule path 'libs/uuid' Thanks, Jim

2 1

Interest in thermodynamic properties of water and steam
by Belcourt, Kenneth 29 Aug '17

29 Aug '17

Hi, Would there be any interest in an implementation of the IAPWS-95 in Boost? Here’s the reference: The IAPWS Formulation 1995 for the Thermodynamic Properties of Ordinary Water Substance for General and Scientific Use. Authors: W. Wagner and A. Pruss J. Phys. Chem. Ref. Data, Vol. 31, No. 2, 2002, pages 387-535 For those with access to the paper, the code reproduces Table 6.6 (results agree to all published digits), as well as well significant parts of both Table 13.1 (vapor-liquid phase boundary properties as function of temperature) and Table 13.2 (properties of water in single-phase as function of temperature and density for pressures in range of 0.05 MPa to 1000 MPa). Also implemented are the full set of algorithms in Table 6.3, including pressure, enthalpy, entropy, sound speed, heat capacities. There’s also an algorithm for computing the thermal saturation properties (pressure, liquid and vapor densities), given the saturation temperature. At present the code has a required dependency on Boost.Units and is about 2k loc. If you're interested in this, feel free to reply or contact me directly. — Noel Belcourt [1] http://www.iapws.org

7 10

Question/Remark to your include/boost/numeric/ublas/lu.hpp
by Ziehe, Dieter 29 Aug '17

29 Aug '17

Dear development community, first of all, thanks for your work, I use boost sometimes to ease from it in my development of math algorithm. Normally I try and check your code and documentation till it works (for example Edmonds karp, remez ...) But now I came to one point, which I don't understand and only workarounded it (although I'm a mathematician and the topic LU-Decomposition is easy). My Problem is lu.hpp:: lu_factorize and this part : (*) #if BOOST_UBLAS_TYPE_CHECK swap_rows (pm, cm); BOOST_UBLAS_CHECK (singular != 0 || detail::expression_type_check (prod (triangular_adaptor<matrix_type, unit_lower> (m), triangular_adaptor<matrix_type, upper> (m)), cm), internal_logic ()); #endif Despite the fact, that I can BOOST_UBLAS_TYPE_CHECK switch off (with BOOST_UBLAS_NDEBUG) I don't understand the sense of these lines. As far as I know, LU is in every case possible, either a matrix is singular or not. For example the ZERO-Matrix is also LU- decomposable (Solution ZERO-Matrix and Identity Matrix). And so, IMHO the lines are too strong for this situation. These lines lead in remez to an Exception : remez failed with exception: internal logic , but the remez algorithm is right (without BOOST_UBLAS_TYPE_CHECK) I got the correct results. Is it possible to weaken the lines (*) to a hint only (the return-value singular is also available for other user, who need regularity). Maybe I'm wrong. But if so, I'd like to know the argument, which lead to such strong reaction in the normal case of singular Matrix inside the LU-Algorithm ? I'm looking forward to hear from you. Many thanks. Dieter from Berlin

1 0

[Intrusive]
by degski 28 Aug '17

28 Aug '17

I having trouble understanding the documentation of Boost.Intrusive. I'm referring to this section in particular: http://www.boost.org/doc/libs/1_65_0/doc/html/intrusive/intrusive_vs_nontru… "The main difference between intrusive containers and non-intrusive containers is that in C++ non-intrusive containers store *copies* of values passed by the user." This is confusing, as that might not be true in case of C++11 and up. Does (or rather, can) move-construction invalidate the use case for Intrusive containers? "On the other hand, an intrusive container does not store copies of passed objects, but it stores the objects themselves. The additional data needed to insert the object in the container must be provided by the object itself." But then in the example for slist, it seems from the example code that (a) pointer(s) to the original object are stored (and makes it look like the object), but that's not what I read from the quoted text. class MyClass{ MyClass *next; MyClass *previous; //Other members...}; int main(){ acme_intrusive_list<MyClass> list; MyClass myclass; list.push_back(myclass); //"myclass" object is stored in the list assert(&myclass == &list.front()); return 0;} I would like to ask for somebody to confirm I'm right, or explain to me in language (palatable to a thick user) what is actually stored (in terms of implementation). Thanks in advance, degski -- "*Ihre sogenannte Religion wirkt bloß wie ein Opiat reizend, betäubend, Schmerzen aus Schwäche stillend.*" - Novalis 1798

5 19