- Boost - lists.boost.org

boost include directory question
by Robert Ramey 21 Jul '18

21 Jul '18

The current instructions for doing boost development are approximately: a) clone the boost super project from github. b) invoke b2 headers which does one of: 1) creates links in the boost root directory to individual projects 2) or copies boost directories from individual libraries into the boost root directory. depending on whether it is a windows system or other system. Since I test for both windows and other systems, this is somewhat of a pain. In considering my options, I'm wondering if specifying all the boost library include directories in the CPLUS_INCLUDE_PATH environmental variable (gcc compilers) or INCLUDE (msvc). a) Has this been considered before? b) Was it considered when the current system was setup? c) Is there an reason why it wouldn't be a good idea? Anyone with information on this is free to chime in. Actually anyone is free to chime in. Robert Ramey

3 4

[concept_check] stl_concept_covering - compiler, stdlib, boost, or test issue?
by James E. King III 20 Jul '18

20 Jul '18

Hi folks, The test stl_concept_covering is annotated with "gcc bug" on a number of tests, and yet gcc 7.3.0 (with libstdc++) and clang-6.0 (with libc++ or libstdc++) fail to compile this test, mostly on the sections marked as a bug. For example: "/usr/bin/clang++-6.0" -c -x c++ -stdlib=libc++ -fPIC -m64 -O0 -fno-inline -Wall -g -DBOOST_ALL_NO_LIB=1 -I"../.." -o "../../bin.v2/libs/concept_check/test/ stl_concept_covering.test/clang-linux-6.0/debug/stl_concept_covering.o" "test/stl_concept_covering.cpp" In file included from test/stl_concept_covering.cpp:9: /usr/local/include/c++/v1/algorithm:999:24: error: invalid operands to binary expression ('boost::input_iterator_archetype<boost::equality_comparable2_first_ar chetype<boost::null_archetype<int> >, 0>::reference' and 'const boost::equality_comparable2_second_archetype<boost::null_archetype<int> >') if (*__first == __value_) ~~~~~~~~~~ ^ ~~~~~~~~ test/stl_concept_covering.cpp:152:15: note: in instantiation of function template specialization 'std::__1::find<boost::input_iterator_archetype<boost::equalit y_comparable2_first_archetype<boost::null_archetype<int> >, 0>, boost::equality_comparable2_second_archetype<boost::null_archetype<int> > >' requested here in = std::find(in, in, value); Full log with gcc-7.3.0 here: https://travis-ci.org/boostorg/concept_check/jobs/404203085#L1517 What's interesting is that if I change the type of in to an input_iterator_archetype_no_proxy the test passes. When I look at the concept_archetypes I see that input_iterator_archetype is a template with a default parameter, but also defines "reference" as a structure with an operator(), instead of using a typedef which is what I usually see done. So this makes me wonder if it's really a compiler issue (both compilers and std C++ libs complain the same way though) or if the archetype is invalid. I'm not sure the best course of action. It does cause most CI build jobs to fail, except MSVC jobs interestingly enough. Any thoughts you could share on this would be appreciated. The PR with all the build jobs showing errors can be found here: https://github.com/boostorg/concept_check/pull/13 Thanks, Jim

3 4

[range] [concepts] Boost 1.68 beta build error in RandomAccessIteratorConcept using latest MSVC
by Viktor Sehr 20 Jul '18

20 Jul '18

The following error is emitted in latest MSVC building Boost 1.68 beta: 1>\boost\range\concepts.hpp(257): error C3646: 'n': unknown override specifier 1>\boost\range\concepts.hpp(264): note: see reference to class template instantiation 'boost::range_detail::RandomAccessIteratorConcept<Iterator>' being compiled 1>\range\concepts.hpp(257): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int Unfortunately I'm not competent enough to determine what is causing the error: Full struct: template<class Iterator> struct RandomAccessIteratorConcept : BidirectionalIteratorConcept<Iterator> { #if BOOST_RANGE_ENABLE_CONCEPT_ASSERT BOOST_RANGE_CONCEPT_ASSERT(( Convertible< BOOST_DEDUCED_TYPENAME RandomAccessIteratorConcept::traversal_category, random_access_traversal_tag >)); BOOST_CONCEPT_USAGE(RandomAccessIteratorConcept) { i += n; i = i + n; i = n + i; i -= n; i = i - n; n = i - j; } private: // MSVC 14.1 - avoid C4596: 'difference_type': illegal qualified name in member declaration #if defined(_MSC_VER) && _MSC_VER >= 1912 BOOST_DEDUCED_TYPENAME difference_type n; #else BOOST_DEDUCED_TYPENAME RandomAccessIteratorConcept::difference_type n; #endif Iterator i; Iterator j; #endif }; br/Viktor Sehr

3 3

[system] Clang CI builds broken because of constexpr
by Andrey Semashev 20 Jul '18

20 Jul '18

Hi, I'm seeing these errors in Travis CI builds with Clang 3.8, 3.9, 4.0 and 5.0: ./boost/system/error_code.hpp:232:41: error: constexpr constructor never produces a constant expression [-Winvalid-constexpr] BOOST_SYSTEM_CONSTEXPR explicit std_category( boost::system::error_category const * pc ): pc_( pc ) ^ ./boost/system/error_code.hpp:232:41: note: non-constexpr constructor 'error_category' cannot be used in a constant expression /usr/bin/../lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8/system_error:69:5: note: declared here error_category() noexcept; ^ I'm assuming this is because the compiler uses libstdc++ from gcc 4.8, in which error_category() is not marked constexpr. Can this be fixed somehow?

2 2

Looking for help on preparing for review
by Damian Vicino 20 Jul '18

20 Jul '18

Hi, I'm preparing my library safe_float to be proposed for review. The library was born in the GSOC2015, but it never reached a review ready state. My plan is to change that in the next few months. At this point, I'm looking for some volunteers to proof-read the documentation. Code is going through major rewrite, and I will send another mail looking for help with reviewing the code when that is done. The most current documentation can be read directly from the web here: https://sdavtaker.github.io/safefloat/ Any comment is appreciated. Best regards, Damian

5 9

[Compute] Conflict between boost::compute::zip_iterator and boost::iterators::zip_iterator
by fortenberry.rm＠protonmail.com 18 Jul '18

18 Jul '18

I'd like to use boost::compute and boost::range together, like below, but if I uncomment the '#include <boost/range/combine.hpp>' line I get an error saying that boost::compute::zip_iterator and boost::iterators::zip_iterator are ambiguous. Is there a way around this, so that I can use boost::compute and boost::range together in the same cpp file? I am using on Windows vs2015 64bit. Boost 1.67.0. Code: #include <vector> #include <iostream> #include <algorithm> //#include <boost/range/combine.hpp> #include <boost/compute/lambda.hpp> #include <boost/compute/functional/math.hpp> #include <boost/compute/container/vector.hpp> #include <boost/compute/algorithm/transform.hpp> namespace compute = boost::compute; using compute::float4_; using compute::lambda::_1; using compute::lambda::_2; using compute::lambda::distance; int main() { // get default device and setup context compute::device device = compute::system::default_device(); compute::context context(device); compute::command_queue queue(context, device); // generate random data on the host std::vector<float4_> a(10000); std::vector<float4_> b(10000); std::vector<float> r(10000); std::generate((float*)a.data(), (float*)(a.data() + a.size()), rand); std::generate((float*)b.data(), (float*)(b.data() + b.size()), rand); // create a vector on the device compute::vector<float4_> _a(a.size(), context); compute::vector<float4_> _b(b.size(), context); compute::vector<float> _r(r.size(), context); // transfer data from the host to the device compute::copy(a.begin(), a.end(), _a.begin(), queue); compute::copy(b.begin(), b.end(), _b.begin(), queue); boost::compute::transform( _a.begin(), _a.end(), _b.begin(), _r.begin(), distance(_1, _2), queue ); // copy values back to the host compute::copy(_r.begin(), _r.end(), r.begin(), queue); for (int i = 0; i < a.size(); ++i) { float4_ va = a[i]; float4_ vb = b[i]; float vr = r[i]; float e = std::sqrt(std::pow(va[0] - vb[0], 2) + std::pow(va[1] - vb[1], 2) + std::pow(va[2] - vb[2], 2) + std::pow(va[3] - vb[3], 2)); std::cout << std::setprecision(12); if (std::abs(e - vr) > 1e-2) std::cout << e << " != " << vr << "\n"; } return 0; } Error, truncated for brevity. I can post the full error log if it is helpful: 1>------ Build started: Project: demo, Configuration: Debug x64 ------ 1> demo.cpp 1> This header is implementation detail and provided for backwards compatibility. 1>C:\local\boost_1_67_0\boost/compute/algorithm/transform.hpp(67): error C2668: 'boost::compute::make_zip_iterator': ambiguous call to overloaded function 1> C:\local\boost_1_67_0\boost/compute/iterator/zip_iterator.hpp(276): note: could be 'boost::compute::zip_iterator,boost::compute::buffer_iterator,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type>> boost::compute::make_zip_iterator,boost::compute::buffer_iterator,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type,boost::tuples::null_type>>(IteratorTuple)' 1> with 1> [ Thanks, Madison

2 2

[boostbook] cleanup / modernization
by James E. King III 18 Jul '18

18 Jul '18

I would have opened an "issue" on the boostorg/boostbook project, however, that is not enabled. (Perhaps someone should enable it?) I have duplicated the boostbook setup scripts into the docker setup environment for Ubuntu Bionic and I have found that all of the packages that boostbook depends on are ancient. PackageVersionLast ModifiedHost docbook-xsl 1.75.2 2009 SourceForge <http://sourceforge.net/projects/docbook/files/docbook-xsl/1.75.2/docbook-xs…> docbook-xml 4.2 2002 oasis-open.org <http://www.oasis-open.org/docbook/xml/4.2/docbook-xml-4.2.zip> fop 0.94 2007 Apache <http://archive.apache.org/dist/xmlgraphics/fop/binaries/fop-0.94-bin-jdk1.4…> These tools are quite old and it is only a matter of time before the older versions could be removed. These external sites are under no particular requirement to keep these older versions of software available. At some point some of these tools may no longer work with current operating system tools, for example "fop" says that it is for "JDK 1.4". Each of these tools has a newer version. A project should be initiated now to modernize the documentation build to use more recent versions of these tools before it becomes a critical release blocker at a bad time. - Jim

3 2

[iostreams] libstdc++ vs MSVC exception handling behavior in seekg, seekp
by James E. King III 17 Jul '18

17 Jul '18

I found a disabled test in Boost.Iostreams called stream_state_test. It was disabled because it was thought it only tests the standard library implementation. Partially true, but it also tests some parts of iostreams so I have been working to re-enable it along with the generic CI upgrades. It looks like libstdc++ and the standard library that comes with MSVC (is it still Dinkumware? It used to be...) handle exceptions on stream seekg and seekp differently. I haven't consulted the standards documents yet, but I found this reference for exception handling: http://www.cplusplus.com/reference/istream/istream/seekg/ which states, " Any exception thrown by an internal operation is caught and handled by the function, setting badbit <http://www.cplusplus.com/ios_base::badbit>. " Sitting in the debugger where the test throws an exception in error_device::seek, there is no exception handling within iostreams or in msvcp140d code paths for a call to seekg, while the libstdc++ implementation is able to pass all of the tests. This leads to a couple questions: 1. Are the standards clear in this area? 2. Is someone violating them? A cursory review (such as this) leads me to believe that the MSVC C++ runtime implementation is not properly handling exceptions here. The sources for seekg in libstdc++ wrap the internals in a try catch in order to restore state. The sources for seekg in the MSVCPRT do not. - Jim

2 1

Safe Float design question
by Damian Vicino 17 Jul '18

17 Jul '18

Hi, I looking for some design advice. The context: - I'm revisiting SafeFloat after some time and, while doing so, I'm rethinking all the decisions from the past. Idea is to sent for review in the following months. - The goal of the library is being a drop-in replacement for float, that adds checks to floating point operations and reports when a check failed. Without SafeFloat, someone could write something like this: #include <iostream> #include <limits> #include <cfenv> using namespace std; int main(){ float a = 1.0f; float b = numeric_limits<float>::max(); feclearexcept(FE_ALL_EXCEPT); float c = a/b; if(fetestexcept(FE_UNDERFLOW)) { cout << "underflow result\n"; } } What I expect when using safe_float is to declare upfront "what checks" I care about, "what operations" to check, and "what to do when a check fails". Some intention examples: - I would like to check there was no "overflow_to_infinite" in "addition operations", otherwise I "throw exception".. - I would like to check there was no "division by zero" in "division", otherwise I will "log to cerr and ignore it". - I would like to check there was no "inexact" "addition", otherwise I return an boost::unexpected. I have at least 5 things to check (there is 5 flags in c++11::fenv). I have at least 4 places to check (+/-/*//) and I want to keep what to do about it customizable. In addition, sometimes I want to check multiple things "overflow and underflow", etc... So, the question is how the user can pass all that information to the type and it doesn't look as horrible nonsense. My original option was: int main(){ using CHECK = compose_policy<check_addition_overflow, check_division_by_zero, check_division_underflow>::type; using REPORT = report_throw_on_failure; using sf = safe_float<float, CHECK, REPORT>; try{ sf a = 1.0_sf; sf b = numeric_limits<sf>::max(); auto c = a/b; } catch (safe_float_exception e){ cout << e.message(); //this outputs there was a underflow } } Please comment in what you think about this way to use. Is there a better way to specify the policies to apply that I should try? Best regards, Damian I expect when using safe float to write some code like this: int main(){ safe_float<float> }

2 3

[system] Clang CI builds broken because of constexpr
by Andrey Semashev 17 Jul '18

17 Jul '18

Hi, I'm seeing these errors in Travis CI builds with Clang 3.8, 3.9, 4.0 and 5.0: ./boost/system/error_code.hpp:232:41: error: constexpr constructor never produces a constant expression [-Winvalid-constexpr] BOOST_SYSTEM_CONSTEXPR explicit std_category( boost::system::error_category const * pc ): pc_( pc ) ^ ./boost/system/error_code.hpp:232:41: note: non-constexpr constructor 'error_category' cannot be used in a constant expression /usr/bin/../lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8/system_error:69:5: note: declared here error_category() noexcept; ^ I'm assuming this is because the compiler uses libstdc++ from gcc 4.8, in which error_category() is not marked constexpr. Can this be fixed somehow?

1 0