- Boost - lists.boost.org

[err] RFC
by Domagoj Saric 11 Jan '16

11 Jan '16

https://github.com/psiha/err README.md copy-paste: --------------------------------------------- err - yet another take on C++ error handling. We have throw and std::error_code, what more could one possibly want? --------------------------------------------- std::error_code&co tried to solve or at least alleviate the problem of overhead of using exceptions (in terms of both source code verbosity and binary code size&speed) with functions which need to report failures that need not be 'exceptional' depending on the context of the call (thereby requiring try-catch blocks that convert exceptions to 'result codes'). Unfortunately, the way it was finally implemented, std::error_code did not quite accomplish what it set out to do: • in terms of runtime efficiency: 'manual'/explicit EH (try-catch blocks) is no longer needed but the compiler still has to insert hidden EH as it has to treat the functions in question as still possibly throwing (in fact the implementation/codegen of functions which use std::error_code for error reporting becomes even fatter because it has to contain both return-on-error paths and handle exceptions) • in terms of source code verbosity: again, try-catch blocks are gone but separate error_code objects have to be declared and passed to the desired function. Enter boost::err: 'result objects' (as opposed to just result or error codes) which can be examined and branched upon (like with traditional result codes) or left unexamined to self-throw if they contain a failure result (i.e. unlike traditional result codes, they cannot be accidentally ignored). Thanks to latest C++ language features (such as r-value member function overloads) incorrect usage (that could otherwise for example lead to a result object destructor throwing during a stack-unwind) can be disallowed/detected at compile time. Discussions where the concept (or a similar one) was first concieved of and/or so far discussed: • http://boost.2283326.n4.nabble.com/system-filesystem-v3-Question-about-erro… • http://cpptips.com/fallible • https://github.com/ptal/std-expected-proposal • https://github.com/ptal/expected • https://github.com/adityaramesh/ccbase/blob/master/include/ccbase/error/exp… • http://stackoverflow.com/questions/14923346/how-would-you-use-alexandrescus… • https://svn.boost.org/trac/boost/wiki/BestPracticeHandbook#a8.DESIGN:Strong… • http://2013.cppnow.org/session/non-allocating-stdfuturepromise **************************************************************** For starter's, to reduce the length of the first post, I'll assume that everyone as at least somewhat familiar with similar/related proposals from Andrei Alexandrescu (std::expected) and Niall Douglas (std::monad) to which I gave links above. What, primarily, makes (Boost.)Err different from other proposals is the ability to (using latest C++ features) detect/distinguish between temporaries and 'saved' return values by using two different class templates (result wrappers), fallible_result (for rvalues) and result_or_error (for lvalues) and thus minimise or often completely eliminate any extra verbosity: If we had a function foo() that produces bar_t objects but can fail with an err_t, up till now we had two options: * bar_t foo() throw( err_t ); * optional<bar_t> foo( err_t & ); Err enables the library writer to write a single API and a single implementation: err::fallible_result<bar_t, err_t> foo(); where fallible_result is the class template that wraps temporaries/rvalues returned from functions and its member functions are all declared with && (i.e. callable only on rvalues) so you get a compiler error if you save it to an auto value and try to do anything with it. The two exceptions are the implicit conversion operators to: - bar_t, which will either return bar_t or throw err_t and which is used for the 'EH code path' bar_t my_bar( foo() ); - err::result_or_error<bar_t, err_t> which is used for the 'oldsk00l nothrow error code path' err::result_or_error<bar_t, err_t> maybe_bar( foo ); if ( maybe_bar ) { print( *maybe_bar ); } else { log( maybe_bar.error() ); } Also, if the fallible_result rvalue is left uninspected and contains an error its destructor will throw (which AFAICT should be safe considering it is an rvalue and no other exception can possibly be active at the same time) - this makes code that uses Err enabled libraries/APIs but relies on EH almost indistinguishable from 'classic EH' APIs (almost because the one difference that remains is with the immediate use of the return value: because of the wrapper class one can no longer write foo().do_something() but has to implicitly use the -> operator and write foo()->do_something() where the -> operator will check-and-throw if foo() did not succeed). To wrap up, this approach gives the user the immediate and fine grained control over which error handling mechanism he/she wants to use while allowing the developer to write a single API and implementation - AFAICT it is a no brainer replacement for <system_error>, it is less verbose and much more efficient ;-) ps. the small library @ https://github.com/psiha/err is by no means a finished product, it contains no tests or documentation but 'it works' (i.e. it is used in the, also upcoming, https://github.com/psiha/mmap)...I'm bringing it to public view for scrutiny, discussion and guidance lest I steer in the wrong direction ;) -- "What Huxley teaches is that in the age of advanced technology, spiritual devastation is more likely to come from an enemy with a smiling face than from one whose countenance exudes suspicion and hate." Neil Postman

4 20

Add Boost.Convert to the Trac
by Vicente J. Botet Escriba 11 Jan '16

11 Jan '16

Hi, I have requested this (https://svn.boost.org/trac/boost/ticket/11814) 6 weeks ago without response. Is anyone maintaining the Trac component? I see Doug Gregor, but I believe he is not actively working on Boost. Best, Vicente

2 1

[trac] boost 1.61
by Raffi Enficiaud 11 Jan '16

11 Jan '16

Hi all, Would it be possible to add 1.61 to the roadmap? Thanks, Raffi

2 1

want to contribute in boost c++ organisation
by Aman Varshney 11 Jan '16

11 Jan '16

As I am a 2nd year computer Science student at IIIT-Hyderabad. Being a beginner I have some idea about C++ and want to start contributing to open source. I found the boost c++library. It would be great if I get some directions from you as to where to start from. Thank You

1 0

[regression] Summary for develop is unavailable
by Antony Polukhin 08 Jan '16

08 Jan '16

Hi, At http://www.boost.org/development/tests/develop/developer/summary.html you'll find "Error extracting file: Error code 3 - A severe error in the zipfile format was detected." Please, could someone fix that? -- Best regards, Antony Polukhin

1 1

Ynt: Building Boost (1.60) with Clang and NDK
by Fatih Kıralioğlu 07 Jan '16

07 Jan '16

Ok, I am sharing my build.bat user-config-android.jam file below, from the outputs, clang is using mingw headers, for clang build, is mingw headers really necessary? build.bat: set CXXFLAGS="-I%ANDROID_NDK%/platforms/android-9/arch-arm/usr/include -I%ANDROID_NDK%/sources/cxx-stl/gnu-libstdc++/4.9/include -I%ANDROID_NDK%/sources/cxx-stl/gnu-libstdc++/4.9/libs/armeabi/include" set TOOLSET=gcc-android b2 --toolset=%TOOLSET% --user-config=./user-config-android.jam cxxflags=%CXXFLAGS% threadapi=pthread --prefix=..\boost_android_arm --builddir=./ target-os=linux --with-date_time --with-filesystem --with-regex --with-log define=BOOST_FILESYSTEM_VERSION=3 --with-program_options --with-signals --with-system --with-thread link=static runtime-link=shared threading=multi install user-config-android.jam: androidNDKRoot = android-ndk-r10e ; # put the relevant path using clang : android : $(androidNDKRoot)/toolchains/llvm-3.6/prebuilt/windows-x86_64/bin/clang++ : <compileflags>--sysroot=$(androidNDKRoot)/platforms/android-21/arch-arm <compileflags>-Os <compileflags>-fno-strict-aliasing <compileflags>-O2 <compileflags>-DNDEBUG <compileflags>-g <compileflags>-I$(androidNDKRoot)/sources/cxx-stl/gnu-libstdc++/4.9/include <compileflags>-I$(androidNDKRoot)/sources/cxx-stl/gnu-libstdc++/4.9/libs/armeabi/include <compileflags>-D__GLIBC__ <compileflags>-D__ANDROID__ <compileflags>-D_GLIBCXX__PTHREADS <compileflags>-D__arm__ <compileflags>-D_REENTRANT And I'am getting this error: g++: error: unrecognized command line option '-stdlib=libc++' clang++.exe: error: linker (via gcc) command failed with exit code 1 (use -v to see invocation) "android-ndk-r10e/toolchains/llvm-3.6/prebuilt/windows-x86_64/bin/clang++" -o "bin.v2\libs\date_time\build\clang-linux-andr oid\release\target-os-android\threadapi-pthread\threading-multi\libboost_date_time-clang-mt-1_60.so.1.60.0" -Wl,-soname -Wl,libboost_date_time-clang-m t-1_60.so.1.60.0 -shared -Wl,--start-group "bin.v2\libs\date_time\build\clang-linux-android\release\target-os-android\threadapi-pthread\threading-mult i\gregorian\greg_month.o" "bin.v2\libs\date_time\build\clang-linux-android\release\target-os-android\threadapi-pthread\threading-multi\gregorian\greg_ weekday.o" "bin.v2\libs\date_time\build\clang-linux-android\release\target-os-android\threadapi-pthread\threading-multi\gregorian\date_generators.o" -Wl,-Bstatic -Wl,-Bdynamic -Wl,--end-group -stdlib=libc++ -lc++_shared -Landroid-ndk-r10e/sources/cxx-stl/llvm-libc++/libs/ar meabi ...failed clang-linux.link.dll bin.v2\libs\date_time\build\clang-linux-android\release\target-os-android\threadapi-pthread\threading-multi\libboost_da te_time-clang-mt-1_60.so.1.60.0... ...skipped <p..\boost_android_arm\lib>libboost_date_time-clang-mt-1_60.so.1.60.0 for lack of <pbin.v2\libs\date_time\build\clang-linux-android\release \target-os-android\threadapi-pthread\threading-multi>libboost_date_time-clang-mt-1_60.so.1.60.0... clang-linux.compile.c++.without-pth bin.v2\libs\system\build\clang-linux-android\release\target-os-android\threadapi-pthread\threading-multi\error_cod e.o In file included from libs\system\src\error_code.cpp:16: In file included from .\boost/system/error_code.hpp:19: In file included from android-ndk-r10e/sources/cxx-stl/gnu-libstdc++/4.9/include\ostream:38: In file included from android-ndk-r10e/sources/cxx-stl/gnu-libstdc++/4.9/include\ios:42: In file included from android-ndk-r10e/sources/cxx-stl/gnu-libstdc++/4.9/include\bits/ios_base.h:39: In file included from android-ndk-r10e/sources/cxx-stl/gnu-libstdc++/4.9/include\ext/atomicity.h:35: In file included from android-ndk-r10e/sources/cxx-stl/gnu-libstdc++/4.9/libs/armeabi/include\bits/gthr.h:148: In file included from android-ndk-r10e/sources/cxx-stl/gnu-libstdc++/4.9/libs/armeabi/include\bits/gthr-default.h:48: android-ndk-r10e/platforms/android-21/arch-arm/usr/include\pthread.h:164:58: error: unknown type name 'clockid_t'; did you mean ' clock_t'? int pthread_condattr_getclock(const pthread_condattr_t*, clockid_t*) __nonnull((1, 2)); ^ c:/mingw/include\time.h:71:14: note: 'clock_t' declared here typedef long clock_t; Fatih KIRALİOĞLU R&D Engineer fatih.kiralioglu(a)sestek.com www.sestek.com ________________________________________ Gönderen: Fatih Kıralioğlu Gönderildi: 6 Ocak 2016 Çarşamba 21:13 Kime: boost(a)lists.boost.org Konu: Ynt: [boost] Building Boost (1.60) with Clang and NDK Thanks for the responses, The last error I got is: "In file included from libs\date_time\src\gregorian\greg_weekday.cpp:16: In file included from libs\date_time\src\gregorian/greg_names.hpp:14: In file included from .\boost/date_time/gregorian/greg_month.hpp:14: In file included from .\boost/shared_ptr.hpp:17: In file included from .\boost/smart_ptr/shared_ptr.hpp:35: In file included from .\boost/smart_ptr/detail/spinlock_pool.hpp:25: In file included from .\boost/smart_ptr/detail/spinlock.hpp:47: In file included from .\boost/smart_ptr/detail/spinlock_gcc_arm.hpp:12: In file included from .\boost/smart_ptr/detail/yield_k.hpp:28: In file included from .\boost/predef.h:20: In file included from .\boost/predef/hardware.h:14: .\boost/predef/hardware/simd.h:77:5: error: "Multiple SIMD architectures detecte d, this cannot happen!" # error "Multiple SIMD architectures detected, this cannot happen!" " I have also installed and set it as an include dir for b2.exe to use clang and i got the error above fatih ________________________________________ Gönderen: Boost <boost-bounces(a)lists.boost.org> adına Ben Pope <benpope81(a)gmail.com> Gönderildi: 6 Ocak 2016 Çarşamba 19:06 Kime: boost(a)lists.boost.org Konu: Re: [boost] Building Boost (1.60) with Clang and NDK On Wednesday, January 06, 2016 04:06 AM, Fatih Kıralioğlu wrote: > Has anyone built the Boost with Clang and NDK other than CryStax? If so, can you post the related config.jam and build script? I have handled gcc build but clang is very very chalnllenging and no one including the guys in Stackoverflow could answer it. I haven't noticed any problems building boost for Android with the NDK, I honestly have no idea why I see so many people asking how to do it, or patch sets or whatever. I'm using gcc-4.9 and std=c++14 on linux x64 targeting armv7. I package the toolset I want (android 15, gcc-4.9) and pass that sysroot in the CXXFLAGS, I tend not to interfere with the build system of boost or android very much, preferring to drive everything from cmake (for my own projects). What problems have you seen? The NDK is moving entirely to clang, the next release will see gcc deprecated, so I'll have to have a play with moving over to clang, but in my experience, everything I do works equally well on clang for armv7, armv8 and x64. The only problem I remember having is thread locals on iOS targets, but my memory is short, and it only takes a few lines of code to emulate that for most purposes. If you explain what problems you've seen, which libraries, toolsets and command lines, perhaps you'll trigger a memory of a problem I've solved. I can give you more details of my configuration on the weekend, if required. As a sidenote, I'm hoping to bring up a boost/clang/linux/armv8 build bot if and when my Pine64 arrives and I get Ubuntu/Debian running on it (by April if all goes well). I have no idea how quickly it will cycle though, my current x64 tests take around 16 hours for gcc-4.9, gcc-5.2 and clang-3.7, I'll probably have to drop gcc-4.9. I had to give up on my regular sanitizer builds on x64 as they just take too long and there seemed to be very little interest. Unfortunately I don't have dedicated machines to run the tests. Ben _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

2 1

[review][qvm] QVM formal review report
by Adam Wulkiewicz 07 Jan '16

07 Jan '16

Dear Boost community, The review period for Emil Dotchevski's QVM library has concluded. I'd like to thank everyone who participated in the discussions, esspecially those who sent formal reviews. Only four votes were casted: - 1 vote for acceptance * Rajaditya Mukherjee - 2 votes for conditional acceptance * Rainer Deyke * Oswin Krause - 1 vote for rejection * Phil Endecott However more people commented on issues on the mailing list. Comments received during the course of the review were generally positive, with a number of technical issues identified that need to be addressed. The review identified no fundamental problems in the design or implementation of the library that would entail rejection. The final version of the library can be fully accepted once Emil has addressed the issues identified during the review. Therefore I'm happy to say: Emil Dotchevski's Boost.QVM library is CONDITIONALLY ACCEPTED. Below is a summary of technical concerns: - The identifiers should be made more verbose. This is true both for function names as well as identifers containing "q"/"v"/"m" parts. The former should be replaced with full words, e.g. "transp" -> "transpose". The latter should be replaced at least with "qua"/"quat"/"vec"/"mat" respectively, so e.g. "v_traits" -> "vector_traits"/"vec_traits", "col_m" -> "col_mat", etc. - Many participants found the swizzling syntax using comma operator confusing or not good enough. There were many suggestions about the possible replacements: * v%XY - the old operator% syntax * (v,XY) - the comma operator syntax currently used by QVM * (v,asXY) - in order to limit potential conflicts with macros * XY(v) - function syntax, MOST PREFERED * v.XY() - probably the best but currently not possible (n4165, n4174) * ref(v).XY() * ref(v)[xy] * swizzle(v, xy) * ref(v)->xy The function syntax, i.e. XY(v), was the most prefered solution. Some of the participants appreciated the comma operator as well because of the similarity with shader languages syntax. The library could provide a few alternatives that could be picked by the user, e.g. both a comma and function syntax. - There were concerns regarding deduce_xx set of traits, in particular that traits taking two arguments (deduce_q2, deduce_v2 and deduce_m2) can cause ODR issues in a case when e.g. third-party libraries depending on QVM specialized these traits differently and those libraries were used together. There were no consensus if this is indeed a library issue or how this issue could be handled in general. Taking into account that the specialization of these traits is optional it'd be sufficient to describe the issue in the documentation and discourage the users from specializing those traits for types defined outside of their own code. - There was also a suggestion to use the same names that are already being used in other well-known libraries to make the interface more intuitive, e.g. mag() could be replaced by norm() (used in Eigen and Armadillo libraries), mag2() could be replaced by norm_squared() or norm_sqr(), etc. This would also make the latter more verbose. I'd let the decission how to deal with it to Emil. - Another suggestion was to replace read/write semantics with get/set semantics or at least to make the r/w/ir/iw identifiers more verbose. Here, I'd let the decission how to deal with it to Emil as well. - Aside from the issues described above, there were also suggestions that the scope of QVM library could/should be broadened to include functionalities from domains other than computer graphics, e.g. linear algebra, geometry, physics, robotics, etc. Oswin Krause requested that an consensus on the scope of the library should be made before the acceptance of the library. Phil Endecott expressed that the library is too small to be a standalone library. However as a Boost.Geometry developer I may say that the scopes, design rationales, internal structures, etc. of both libraries are different. AFAIK it's also true for Boost.Polygon. Furthermore, if my understanding is correct after reading various discussions the community finds the library useful even in the current state, some of the participants already used the library in their projects. Furthermore I'm sure that future users of QVM will suggest additions to the QVM library if they think it's necessary, so the scope will be broadened in a natural way. Though of course I encourage Emil to start a discussion with the community regarding this issue. - Regarding the documentation, various people suggested the following improvements: * it should start with a "Quick Start" page showing how to use the QVM built-in types to do some high-school linear algebra, * make it more obvious which functions are classified as "operations" and which are "view proxies", * contain more examples of every function as well as some bigger real-life examples. Please let me know if you think something is wrong. Regards, Adam

2 1

Building Boost (1.60) with Clang and NDK
by Fatih Kıralioğlu 06 Jan '16

06 Jan '16

Has anyone built the Boost with Clang and NDK other than CryStax? If so, can you post the related config.jam and build script? I have handled gcc build but clang is very very chalnllenging and no one including the guys in Stackoverflow could answer it. Many Thanks. Fatih

4 3

[multiprecision] Creation from a range
by Fernando Pelliccioni 06 Jan '16

06 Jan '16

Hi John, hi all, Is there any way to create an Integer (or a number) from a range (bounded or counted)?; or from a string_view (string_ref)? Roughly speaking, something like: XintXXX_t make_from_bounded_range(I f, I l); XintXXX_t make_from_counted_range(I f, size_t n); If not exist, I can make a contribution, are you interested? Thank you very much and best regards, Fernando Pelliccioni.

3 3

[gsoc16] Re: Potential contribution scenarios?
by Miguel Coimbra 06 Jan '16

06 Jan '16

> It is not hard to find either myself or Antony. Both of us are here, > and both of us are at the top of Google search results for our names. Probably my bad, I only bumped into LinkedIn references. I'll wait for a reply from Antony as well, thanks. I will explore other ideas as well. > 1. A thing Boost really could do with is a decent (optionally > mmappable) dense hash map implementation, so the hash map could > contain billions of items and mostly reside on disk yet lookups would > still be very fast. I have some questions regarding this first idea. I believe a concept and implementation already exist and are actually in use at Google: http://goog-sparsehash.sourceforge.net/doc/dense_hash_map.html Quoting from that page: ** dense_hash_map is distinguished from other hash-map implementations by its speed and by the ability to save and restore contents to disk. On the other hand, this hash-map implementation can use significantly more space than other hash-map implementations, and it also has requirements -- for instance, for a distinguished "empty key" -- that may not be easy for all applications to satisfy. This class is appropriate for applications that need speedy access to relatively small "dictionaries" stored in memory, and for applications that need these dictionaries to be persistent." ** So what you want is something like this, but able to "contain billions of items and mostly reside on disk yet lookups would still be very fast"? I assume the "billions of items" is what is lacking from that dense_hash_map already in use by Google? Is this the difference between that and your idea? Assuming this is indeed what you were proposing, would the work encompass defining an API and also exploring mmap for lazy iteration for performance gains in the context of handling billions of items? Kind regards, Miguel E. Coimbra

2 1