- Boost - lists.boost.org

a safe integer library
by Robert Ramey 14 Jan '16

14 Jan '16

Arithmetic operations in C++ are NOT guaranteed to yield a correct mathematical result. This feature is inherited from the early days of C. The behavior of int, unsigned int and others were designed to map closely to the underlying hardware. Computer hardware implements these types as a fixed number of bits. When the result of arithmetic operations exceeds this number of bits, the result will not be arithmetically correct. I have crafted a library to address this issue once and for all. You can find out more about this by checking out the page for Safe Numerics at the boost library incubator. www.blincubator.com I hereby request that this library be added to the boost review queue. I've also made a proposal for the C++ Standards committee to include a simplified version of this library as part of he C++ standard. You can see the proposal at http://www.rrsd.com/software_development/safe_numerics/proposal.pdf Robert Ramey

14 42

ATTENTION: Library requirements..
by Rene Rivera 13 Jan '16

13 Jan '16

Last Summer I brought up the subject of library organization requirements to make it easier to write the development and release tools needed to keep the Boost machine going. See this thread < http://lists.boost.org/Archives/boost/2015/06/223027.php> for a refresher. This morning I committed the first part of the above.. A new set of library requirements that take into account existing practices. Adds some additional integration requirements. And puts in limits to reduce some integration burdens. Please read the new requirements carefully < http://www.boost.org/development/requirements.html#Requirements>. It would be wonderful if authors start making changes as needed immediately. But at some point I, and possible others, will start making changes to all libraries to follow the requirements. So that the release, build, and testing teams can move forward with better support. And of course, more cleanups and such will follow. Hopefully before the next release is out the door. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

16 80

[BPM] Supporting an alternative to meta/libraries.json
by Louis Dionne 13 Jan '16

13 Jan '16

Dear list, Currently, all Boost libraries are required to have a meta/libraries.json file at their root, which contains some meta-data describing the library. As I understand it, this meta-data is then used to generate the list of all libraries with their description when a release is done. I find having such a directory at the root of every library annoying, since it clutters it. Furthermore, for metaprogramming libraries, the name can be slightly confusing since meta/ might be expected to contain something different. I propose that we allow libraries to specify their metadata in a `.boost` file located at their root. Using a dotfile is the most common way of providing information for an external service (for example .travis.yml), and dotfiles are usually more discrete when viewing the project in an editor. Furthermore, making `boost` part of the filename is more descriptive. I have submitted a pull request to BPM [1] adding the ability to fetch the meta data in a .boost file. The meta-data can still be provided in meta/libraries.json, so this should not affect existing libraries. Related questions that we might want to consider: - Should it be .boost.json instead of .boost? - Perhaps we could store the meta-data for all the libraries in the same place, and get rid of the individual meta-data files? - If this suggestion is accepted, is there more to modify than BPM? Regards, Louis [1]: https://github.com/boostorg/bpm/pull/1

5 19

[test] BOOST_TEST macro and std::max
by Benedek Thaler 13 Jan '16

13 Jan '16

Hi, I'd expect the following cheks to pass: BOOST_TEST(3u == (std::max)(0u, 3u)); BOOST_TEST(3u == ((std::max)(0u, 3u))); But both fails with: check 3u == ((std::max)(0u, 3u)) has failed [3 != 7095312] Did I miss something regarding BOOST_TEST usage? Platform: Linux, GCC 5.3, Boost 1.60 Thanks, Benedek

4 15

Re: [boost] asio config.hpp macro redefinition - mistake?
by Curdeius Curdeius 13 Jan '16

13 Jan '16

> > ---------- Wiadomość przekazana dalej ---------- > From: "John M. Dlugosz" <mpbecey7gu(a)snkmail.com> > To: boost(a)lists.boost.org > Cc: > Date: Tue, 12 Jan 2016 17:32:48 -0600 > Subject: [boost] asio config.hpp macro redefinition - mistake? > In file boost_1_59_0\boost\asio\detail\config.hpp line 227 gives a macro > redefinition warning. > (...) > It seems that this is missing a guard or has the if/else things mixed up. > This was fixed some time ago. See https://github.com/boostorg/asio/commit/b9cb61416e1972d7490d91da91df549703f… . Regards, Marek Kurdej

1 0

[fusion]enabler.hpp junk character at start of file
by Aparna Kumta 13 Jan '16

13 Jan '16

All accumulator tests fail when compiled with Oracle Solaris Studio in 'dev' branch as follows: "../boost/fusion/support/detail/enabler.hpp", line 1: Error: A declaration was expected instead of "???". 1 Error(s) and 1 Warning(s) detected. See http://www.boost.org/development/tests/develop/developer/output/oracle-spar… It appears that in file boost/fusion/support/detail/enabler.hpp, there is some junk character at the start of file. This cannot be observed via vi editor, but with ' head -1 enabler.hpp', this can be seen. % head -1 enabler.hpp ��/*===================================== Perhaps these characters should be removed? When I view the file on github, I do not see the issue, however when I try to edit the file, I see it. Will submit a PR. Thanks, Aparna

2 2

[regression] Regression tests for 'develop' has error
by Edward Diener 13 Jan '16

13 Jan '16

Trying to open the regression test results for 'develop' page gives: "Error extracting file: Error code 3 - A severe error in the zipfile format was detected." This has happened numerous times before. Can this be fixed, not only now but permanently ? Surely there must be some way of determining why the zipfile format has a severe error and preventing this in the future.

5 16

asio config.hpp macro redefinition - mistake?
by John M. Dlugosz 13 Jan '16

13 Jan '16

In file boost_1_59_0\boost\asio\detail\config.hpp line 227 gives a macro redefinition warning. // Compliant C++11 compilers put noexcept specifiers on error_category members. #if !defined(BOOST_ASIO_ERROR_CATEGORY_NOEXCEPT) # if (BOOST_VERSION >= 105300) # define BOOST_ASIO_ERROR_CATEGORY_NOEXCEPT BOOST_NOEXCEPT # elif defined(__clang__) # if __has_feature(__cxx_noexcept__) # define BOOST_ASIO_ERROR_CATEGORY_NOEXCEPT noexcept(true) # endif // __has_feature(__cxx_noexcept__) # elif defined(__GNUC__) # if ((__GNUC__ == 4) && (__GNUC_MINOR__ >= 7)) || (__GNUC__ > 4) # if defined(__GXX_EXPERIMENTAL_CXX0X__) # define BOOST_ASIO_ERROR_CATEGORY_NOEXCEPT noexcept(true) # endif // defined(__GXX_EXPERIMENTAL_CXX0X__) # endif // ((__GNUC__ == 4) && (__GNUC_MINOR__ >= 7)) || (__GNUC__ > 4) # endif // defined(__GNUC__) # if defined(BOOST_ASIO_MSVC) # if (_MSC_VER >= 1900) # define BOOST_ASIO_ERROR_CATEGORY_NOEXCEPT noexcept(true) // ****** here ****** # endif // (_MSC_VER >= 1900) # endif // defined(BOOST_ASIO_MSVC) # if !defined(BOOST_ASIO_ERROR_CATEGORY_NOEXCEPT) # define BOOST_ASIO_ERROR_CATEGORY_NOEXCEPT # endif // !defined(BOOST_ASIO_ERROR_CATEGORY_NOEXCEPT) #endif // !defined(BOOST_ASIO_ERROR_CATEGORY_NOEXCEPT) To paraphrase, the block reads # if (BOOST_VERSION >= 105300) // it is: 105900 >= 105300 *# define BOOST_ASIO_ERROR_CATEGORY_NOEXCEPT BOOST_NOEXCEPT* ⋮ # if defined(BOOST_ASIO_MSVC) # if (_MSC_VER >= 1900) *# define BOOST_ASIO_ERROR_CATEGORY_NOEXCEPT noexcept(true)* # endif // (_MSC_VER >= 1900) # endif // defined(BOOST_ASIO_MSVC) It seems that this is missing a guard or has the if/else things mixed up.

2 1

[property_tree] Still being maintained?
by Gavin McNiff 12 Jan '16

12 Jan '16

Hi, I was wondering if the Property_Tree library is still being actively maintained. There are 9 GitHub pull requests stacked up since the summer? Best regards Gavin McNiff

2 2

[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