- Boost - lists.preview.boost.org

boost::trim_copy(boost::string_view()); // error
by Olaf van der Spek 31 Oct '21

31 Oct '21

Hi, Why does the overload for boost::string_view not work? The std one works. Could it be made to work? #include <boost/algorithm/string.hpp> #include <boost/utility/string_ref.hpp> #include <boost/utility/string_view.hpp> #include <iostream> #include <string_view> int main() { boost::trim_copy(boost::string_view()); // error boost::trim_copy(std::string_view()); } $ g++ t0.cpp In file included from /usr/include/boost/algorithm/string.hpp:19, from t0.cpp:1: /usr/include/boost/algorithm/string/trim.hpp: In instantiation of ‘SequenceT boost::algorithm::trim_copy_if(const SequenceT&, PredicateT) [with SequenceT = boost::basic_string_view<char, std::char_traits<char> >; PredicateT = boost::algorithm::detail::is_classifiedF]’: /usr/include/boost/algorithm/string/trim.hpp:343:49: required from ‘SequenceT boost::algorithm::trim_copy(const SequenceT&, const std::locale&) [with SequenceT = boost::basic_string_view<char, std::char_traits<char> >]’ t0.cpp:10:19: required from here /usr/include/boost/algorithm/string/trim.hpp:319:20: error: no matching function for call to ‘boost::basic_string_view<char, std::char_traits<char> >::basic_string_view(const char*, const char*&)’ 319 | return SequenceT( | ^~~~~~~~~~ 320 | detail::trim_begin( | ~~~~~~~~~~~~~~~~~~~ 321 | ::boost::begin(Input), | ~~~~~~~~~~~~~~~~~~~~~~ 322 | TrimEnd, | ~~~~~~~~ 323 | IsSpace), | ~~~~~~~~~ 324 | TrimEnd | ~~~~~~~ 325 | ); | ~ In file included from t0.cpp:3: /usr/include/boost/utility/string_view.hpp:97:9: note: candidate: ‘template<class Allocator> boost::basic_string_view<charT, traits>::basic_string_view(const std::__cxx11::basic_string<charT, traits, Allocator>&) [with Allocator = Allocator; charT = char; traits = std::char_traits<char>]’ 97 | basic_string_view(const std::basic_string<charT, traits, Allocator>& str) BOOST_NOEXCEPT | ^~~~~~~~~~~~~~~~~ /usr/include/boost/utility/string_view.hpp:97:9: note: template argument deduction/substitution failed: In file included from /usr/include/boost/algorithm/string.hpp:19, from t0.cpp:1: /usr/include/boost/algorithm/string/trim.hpp:319:20: note: mismatched types ‘const std::__cxx11::basic_string<char, std::char_traits<char>, Allocator>’ and ‘const char*’ 319 | return SequenceT( | ^~~~~~~~~~ 320 | detail::trim_begin( | ~~~~~~~~~~~~~~~~~~~ 321 | ::boost::begin(Input), | ~~~~~~~~~~~~~~~~~~~~~~ 322 | TrimEnd, | ~~~~~~~~ 323 | IsSpace), | ~~~~~~~~~ 324 | TrimEnd | ~~~~~~~ 325 | ); | ~ In file included from t0.cpp:3: /usr/include/boost/utility/string_view.hpp:110:23: note: candidate: ‘constexpr boost::basic_string_view<charT, traits>::basic_string_view(const charT*, boost::basic_string_view<charT, traits>::size_type) [with charT = char; traits = std::char_traits<char>; boost::basic_string_view<charT, traits>::size_type = long unsigned int]’ (near match) 110 | BOOST_CONSTEXPR basic_string_view(const charT* str, size_type len) | ^~~~~~~~~~~~~~~~~ /usr/include/boost/utility/string_view.hpp:110:23: note: conversion of argument 2 would be ill-formed: In file included from /usr/include/boost/algorithm/string.hpp:19, from t0.cpp:1: /usr/include/boost/algorithm/string/trim.hpp:324:17: error: invalid conversion from ‘boost::range_detail::extract_const_iterator<boost::basic_string_view<char, std::char_traits<char> >, true>::typ’ {aka ‘const char*’} to ‘boost::basic_string_view<char, std::char_traits<char> >::size_type’ {aka ‘long unsigned int’} [-fpermissive] 324 | TrimEnd | ^~~~~~~ | | | boost::range_detail::extract_const_iterator<boost::basic_string_view<char, std::char_traits<char> >, true>::type {aka const char*} In file included from t0.cpp:3: /usr/include/boost/utility/string_view.hpp:107:23: note: candidate: ‘constexpr boost::basic_string_view<charT, traits>::basic_string_view(const charT*) [with charT = char; traits = std::char_traits<char>]’ 107 | BOOST_CONSTEXPR basic_string_view(const charT* str) | ^~~~~~~~~~~~~~~~~ /usr/include/boost/utility/string_view.hpp:107:23: note: candidate expects 1 argument, 2 provided /usr/include/boost/utility/string_view.hpp:78:23: note: candidate: ‘constexpr boost::basic_string_view<charT, traits>::basic_string_view(const boost::basic_string_view<charT, traits>&) [with charT = char; traits = std::char_traits<char>]’ 78 | BOOST_CONSTEXPR basic_string_view(const basic_string_view &rhs) BOOST_NOEXCEPT | ^~~~~~~~~~~~~~~~~ /usr/include/boost/utility/string_view.hpp:78:23: note: candidate expects 1 argument, 2 provided /usr/include/boost/utility/string_view.hpp:73:23: note: candidate: ‘constexpr boost::basic_string_view<charT, traits>::basic_string_view() [with charT = char; traits = std::char_traits<char>]’ 73 | BOOST_CONSTEXPR basic_string_view() BOOST_NOEXCEPT | ^~~~~~~~~~~~~~~~~ /usr/include/boost/utility/string_view.hpp:73:23: note: candidate expects 0 arguments, 2 provided In file included from /usr/include/boost/algorithm/string.hpp:19, from t0.cpp:1: /usr/include/boost/algorithm/string/trim.hpp: In instantiation of ‘SequenceT boost::algorithm::trim_copy_if(const SequenceT&, PredicateT) [with SequenceT = std::basic_string_view<char>; PredicateT = boost::algorithm::detail::is_classifiedF]’: /usr/include/boost/algorithm/string/trim.hpp:343:49: required from ‘SequenceT boost::algorithm::trim_copy(const SequenceT&, const std::locale&) [with SequenceT = std::basic_string_view<char>]’ t0.cpp:11:19: required from here /usr/include/boost/algorithm/string/trim.hpp:324:17: error: invalid conversion from ‘boost::range_detail::extract_const_iterator<std::basic_string_view<char>, true>::type’ {aka ‘const char*’} to ‘std::basic_string_view<char>::size_type’ {aka ‘long unsigned int’} [-fpermissive] 324 | TrimEnd | ^~~~~~~ | | | boost::range_detail::extract_const_iterator<std::basic_string_view<char>, true>::type {aka const char*} In file included from /usr/include/c++/11/bits/basic_string.h:48, from /usr/include/c++/11/string:55, from /usr/include/boost/algorithm/string/std/string_traits.hpp:15, from /usr/include/boost/algorithm/string/std_containers_traits.hpp:19, from /usr/include/boost/algorithm/string.hpp:18, from t0.cpp:1: /usr/include/c++/11/string_view:137:56: note: initializing argument 2 of ‘constexpr std::basic_string_view<_CharT, _Traits>::basic_string_view(const _CharT*, std::basic_string_view<_CharT, _Traits>::size_type) [with _CharT = char; _Traits = std::char_traits<char>; std::basic_string_view<_CharT, _Traits>::size_type = long unsigned int]’ 137 | basic_string_view(const _CharT* __str, size_type __len) noexcept | ~~~~~~~~~~^~~~~ -- Olaf

2 1

VS2022 release date is Nov 8
by Peter Dimov 30 Oct '21

30 Oct '21

The Visual Studio 2022 (msvc-14.3) release date is Nov 8, which is right in the middle of our beta master freeze (Nov 3 - Nov 10). Since VS2022 is now RC2, which means that it won't change much if at all, we probably need to start testing our libraries with it now, so that the issues are ironed out before 1.78 beta.

9 12

The deadline for new libraries and breaking changes in Boost 1.78.0 is Friday, October 29
by Marshall Clow 27 Oct '21

27 Oct '21

Sorry for the late notice; the deadline was supposed to be today, but I'm extending it to Friday. See https://www.boost.org/development/index.html <https://www.boost.org/development/index.html> for the full calendar Next deadline: Boost 1.78.0 closed for beta Wednesday, Nov 3, 2021 — The Release Managers

1 0

Header-only Boost.System
by Ashish Singh 25 Oct '21

25 Oct '21

Hi All, In my application, I'm trying to use Boost ASIO via boost 1.66 and defining the following two macros in the Makefile. Basically trying to use the header-only approach. CFLAGS += \ -DBOOST_ERROR_CODE_HEADER_ONLY \ -DBOOST_SYSTEM_NO_DEPRECATED But then I came across this thread: https://lists.boost.org/Archives/boost/2017/10/239106.php "In header only mode, multiple instances may appear and thus no longer be proper singletons. Stuff breaks in this situation, badly." Is the above applicable to 1.66 too?How can I safely use the header-only approach in boost 1.66? Thanks,Ashish

2 8

Boost.URL: Something Wicked This Way Comes! (Was: Needs Review)
by Vinnie Falco 21 Oct '21

21 Oct '21

Folx: Well, I was on a pause but I picked Boost.URL back up and whipped it into shape. The good news, this Belle is ready for the Ball ! I invite you to kick the tires and light the fires on the next major component in my line of network and protocol libraries: Repository <https://github.com/CPPAlliance/url/> Documentation <https://master.url.cpp.al/> Docs are still being worked on, of course (docs are never "done"). `url_view`, `url`, `static_url`, and `authority_view` should be completely solid and ready to get beat up. And I'm ready for all that lovely negative feedback !!! If a kind soul would like to volunteer to be the review manager, that would be swell. I'm very happy to answer any questions about the library, and happy to get feedback regarding the design and implementation. -- Regards, Vinnie Follow me on GitHub: https://github.com/vinniefalco

12 79

Opinions on introduction of string_view in Core
by Andrey Semashev 21 Oct '21

21 Oct '21

Hi, Recently, a new implementation of string_view was introduced in Boost.Core: https://github.com/boostorg/core/blob/d5bd40e5280487fb29a108eb42e6c4f0bef69… Most of you probably know there is also a string_view implementation in Boost.Utility: https://github.com/boostorg/utility/blob/05e0d1688dcfcd3fdd65bdb6884b7edd1a… The main motivation for introducing the new implementation is adding conversions to/from std::string_view, which were proposed to Boost.Utility and rejected a while ago: https://github.com/boostorg/utility/pull/51 Another notable deviation of boost::core::string_view from std::string_view and boost::string_view is that it only accepts the character type in template parameters and not char_traits. This choice was made to simplify implementation. I have concerns that introducing yet another string_view type (3rd in Boost, after boost::string_ref and boost::string_view, not counting std::string_view) is not good for the ecosystem and interoperability, as this will require adding explicit support in some code bases. One example that I readilly have is Boost.Log: https://github.com/boostorg/log/blob/4c54e4ca4c31f18ce2e451e8d0abf88054242d… std::string_view was supposed to make user's code simpler by removing the need to provide a multitude of function overloads accepting string arguments. boost::string_view (and boost::string_ref before it) was a prototype implementation before introduction of std::string_view and served a similar purpose. In the age with std::string_view, boost::string_view is still useful as a drop-in replacement for std::string_view to lower C++ requirements in libraries and projects, like this: #if !defined(BOOST_NO_CXX17_HDR_STRING_VIEW) using std::basic_string_view; using std::string_view; using std::string_view; #else using boost::basic_string_view; using boost::string_view; using boost::string_view; #endif Introducing boost::core::string_view, which is not a drop-in replacement, does not make users' code simpler as it requires adding yet another set of overloads and specializations to users' APIs. I should stress that I'm not opposing because I don't want to make changes to Boost.Log, I'm opposing because I don't think those changes will be for the better, and because I view this as potentially destructive to the wide adoption of one common string_view type (be it std::string_view or boost::string_view, depending on the conventions taken in the project) to accept string arguments. Please, express your opinions on this matter, in particular: - Do you think it is good/ok/bad to have yet another string_view in Boost? - Is it ok that boost::core::string_view is not a drop-in replacement for std::string_view? Should it be changed to be one? - Should we, perhaps, do something with boost::string_view from Boost.Utility? Deprecate? - Should we reopen the discussion to add conversion to/from std::string_view to boost::string_view, which led to this fork? Perhaps, hold a vote to make this change as widely requested? - Any other course of action or thoughts? Thanks. PS: This post was made after an initial discussion in this commit: https://github.com/boostorg/core/commit/95924b1329da49e70c9c8485b87e066895d…

12 57

hash_value( complex<T> )
by Peter Dimov 19 Oct '21

19 Oct '21

At the moment, boost::hash_value for complex<T> is specified as When T is a built in type and val.imag() == 0, the result is equal to hash_value(val.real()). Otherwise an unspecified value, except that equal arguments shall yield the same result. This is a bit odd; the natural implementation for a two-argument point/tuple type is std::size_t seed = 0; boost::hash_combine( seed, v.real() ); boost::hash_combine( seed, v.imag() ); return seed; Can anyone offer an opinion on whether or why the original behavior is preferable?

3 6

regarding boost::exception
by rajesh daggumati 18 Oct '21

18 Oct '21

Hi Team, I need to create an object for catched exception . class exception: virtual public std::exception ,virtual public boost::exception {} inside my application code, try{ boost::rethrow_exception(exceptr)} catch(std::exception &e) { std::exception *e = stacktoHeapObject(e); } static std::exception* stacktoHeapObj(std::exception* e) { if (dynamic_cast<std::bad_alloc*>(e)) { return new std::bad_alloc(*(dynamic_cast<std::bad_alloc*>(e))); } else if (dynamic_cast<std::bad_cast*>(e)) { return new std::bad_cast(*(dynamic_cast<std::bad_cast*>(e))); } else if (dynamic_cast<std::bad_typeid*>(e)) { return new std::bad_typeid(*(dynamic_cast<std::bad_typeid*>(e))); } else if (dynamic_cast<std::bad_exception*>(e)) { return new std::bad_exception(*(dynamic_cast<std::bad_exception*>(e))); } else if (dynamic_cast<std::domain_error*>(e)) { return new std::domain_error(*(dynamic_cast<std::domain_error*>(e))); } else if (dynamic_cast<std::invalid_argument*>(e)) { return new std::invalid_argument(*(dynamic_cast<std::invalid_argument*>(e))); } else if (dynamic_cast<std::length_error*>(e)) { return new std::length_error(*(dynamic_cast<std::length_error*>(e))); } else if (dynamic_cast<std::out_of_range*>(e)) { return new std::out_of_range(*(dynamic_cast<std::out_of_range*>(e))); } else if (dynamic_cast<std::overflow_error*>(e)) { return new std::overflow_error(*(dynamic_cast<std::overflow_error*>(e))); } else if (dynamic_cast<std::range_error*>(e)) { return new std::range_error(*(dynamic_cast<std::range_error*>(e))); } else if (dynamic_cast<std::underflow_error*>(e)) { return new std::underflow_error(*(dynamic_cast<std::underflow_error*>(e))); } else if (dynamic_cast<std::runtime_error*>(e)) { return new std::runtime_error(*(dynamic_cast<std::runtime_error*>(e))); } else if (dynamic_cast<std::exception*>(e)) { return new std::exception(*(dynamic_cast<std::exception*>(e))); } } I have coded by taking order reference of below pic. please help me to get classes names in boost:exception which are not in std::exception . if they are in boost::exception only then how to catch that and send to stackToHeapObj and what order i need to follow to add those if checks. try { boost::rethrow_exception(exptr) } here in catch block , we don't know which exception type we have in exptr(ie. std:: or boost:;) then How to catch them. if i use std::exception in catch block then if exptr throws boost::exception type then ... and viceversa..? Please help me to clarify above queries [image: image.png]

3 6

Opinions on merging Assert, StaticAssert, ThrowException into Core
by Nikita Kniazev 17 Oct '21

17 Oct '21

Recently Core grew with additional dependencies on StaticAssert (in 1.76) and ThrowException (in the next release), previously it was only depending on Assert and Config. That made a lot of libraries checkout the same four repositories, three of them containing only a few headers. Merging into a single dependency will affect mostly positive about 100 libraries and negative 1: StlInterfaces (depends on Assert, and will on Core). Please leave a comment at https://github.com/boostorg/core/issues/97 if you think it is a good idea, or have concerns against doing that.

7 14

No more cycles going forward
by Glen Fernandes 16 Oct '21

16 Oct '21

Boost 1.77.0 released with no dependency cycles between libraries. This wasn't easy to achieve and we want to preserve it, going forward. We should not regress and allow libraries to introduce dependency cycles in any future Boost release. i.e. Doing so should be considered a release blocker. Currently, such a regression exists (introduced last month in Context): Asio -> Coroutine -> Context -> Asio It should be fixed before we lock the branches for the 1.78 release, or we should not take this change in the release. Glen

3 3