October 2019 - Boost - lists.boost.org

CMake Announcement from Boost Steering Committee
by Jon Kalb 13 Aug '24

13 Aug '24

The libraries produced by the Boost community have had a greater impact on the way that the C++ community writes code than any other library implementation. The focus of the Boost community will always be on the libraries, but it is undeniable that we are dependent on and often limited by the infrastructure of our trade. Years ago, the move to Git was contentious; yet, it was required to improve development. In a similar vein our build system has become an impediment for many developers and users, existing and prospective. Therefore, we, the Steering Committee, announce to the Boost community our desire and intent to move Boost’s build system to CMake for users and developers alike. We are soliciting comments and proposals from the community to guide the process and the goals. Our desire is that the community can come to consensus by the end of the calendar year with a vision of supporting users and developers. We understand that the actual process of achieving the end goal will be long, time consuming, and not without its share of conflict. We also recognize that the Boost community is comprised of bright and passionate individuals that are eager to get involved and help get work done. The members of the Steering Committee have been encouraged by the discussions and activity surrounding CMake on the mailing lists over the years and know that many people have voiced visions. We hope that each of you rejoins the discussion to support this initiative and contributes to the common goal of improving Boost’s integration into the broader C++ ecosystem. For the Boost Steering Committee, Jon Kalb, Chair jonkalb(a)boost.org

49 200

istream_iterator_limited
by Frederick Gotham 21 Nov '19

21 Nov '19

[MODERATOR: I tried to post this a week ago, but for some reason the word SPAM was prefixed to the subject line and so it didn't show up on the GMane server. I don't think many people actually saw it.] - - - - WHY I NEEDED THIS: I wanted to open a file using "ifstream", and then I wanted to read 32 bytes from the file and feed them directly into boost::algorithm::hex. Unfortunately I couldn't do this because 'hex' takes two iterators [begin,end), and there's no alternative function "hex_n". So I had to read the file into a string first, and then pass the string to 'hex'. - - - - THE IDEA I CAME UP WITH: Open the file using "ifstream", and then use a special iterator that will stop reading from the file after 32 bytes, with syntax like this: ifstream logfile("log.txt"); hex( istream_iterator_limited<char>(logfile,32), istream_iterator_limited<char>(), g_some_global_container.begin() ); - - - - SAMPLE CODE: #include <cstddef> /* size_t */ #include <iterator> /* istream_iterator */ template <typename T> class istream_iterator_limited : public std::istream_iterator<T> { protected: std::size_t const m_limit; std::size_t m_current_count; public: /* Shorter names */ typedef std::istream_iterator<T> Base; typedef istream_iterator_limited<T> This; istream_iterator_limited(typename Base::istream_type &obj_stream, size_t const arg_limit) : Base(obj_stream), m_limit(arg_limit), m_current_count (1) { /* The initialiser list above does all the construction work */ } istream_iterator_limited(void) /* This gives the End-Of-Stream iterator */ : Base() , m_limit(0), m_current_count(1) { /* The initialiser list above does all the construction work */ } This &operator++(void) { if ( m_limit <= m_current_count ) { Base::operator=( Base() ); /* Becomes End-Of- Stream iterator */ } else { ++m_current_count; Base::operator++(); } return *this; } }; #include <algorithm> /* copy */ #include <string> /* string */ #include <sstream> /* istringstream */ #include <iostream> /* cout, endl */ #include <iterator> /* back_inserter */ auto main(void) -> int { std::istringstream iss("123456789"); std::string str; /* Let's use copy to read 5 char's into our string */ std::copy( istream_iterator_limited<char>(iss,5), istream_iterator_limited<char>(), std::back_inserter(str) ); std::cout << str << std::endl; str.clear(); /* Get another 3 */ std::copy( istream_iterator_limited<char>(iss,3), istream_iterator_limited<char>(), std::back_inserter(str) ); std::cout << str << std::endl; }

1 1

[container] static_string ?
by Vinnie Falco 09 Nov '19

09 Nov '19

Beast has static_string which someone has asked to be move, is there any interest in moving this to Boost.Container? See: <https://github.com/boostorg/beast/issues/1691> <https://github.com/boostorg/beast/blob/b7230f12f16fe7a9f7a1ece5be1f607c8552…> -- Regards, Vinnie Follow me on GitHub: https://github.com/vinniefalco

19 50

Interest in a Unicode library for Boost?
by Zach Laine 02 Nov '19

02 Nov '19

About 14 months ago I posted the same thing. There was significant work that needed to be done to Boost.Text (the proposed library), and I was a bit burned out. Now I've managed to make the necessary changes, and I feel the library is ready for review, if there is interest. This library, in part, is something I want to standardize. It started as a better string library for namespace "std2", with minimal Unicode support. Though "std2" will almost certainly never happen now, those string types are still in there, and the library has grown to also include all the Unicode features most users will ever need. Github: https://github.com/tzlaine/text Online docs: https://tzlaine.github.io/text If you care about portable Unicode support, or even addressing the embarrassment of being the only major production language with next to no Unicode support, please have a look and provide feedback. I gave a talk about this at C++Now in May 2018, and now it's a bit out of date, as the library was not then finished. It's three hours, so, y'know, maybe skip it. For completeness' sake: https://www.youtube.com/watch?v=944GjKxwMBo&index=7&list=PL_AKIMJc4roVSbTTf… https://www.youtube.com/watch?v=GJ2xMAqCZL8&list=PL_AKIMJc4roVSbTTfHReQTl1d… Zach

8 10

Change TCP_USER_TIMEOUT
by JH 01 Nov '19

01 Nov '19

Hi, I am using boost asio TCP socket in my device application for network connection in Linux platform. I am troubled currently by long TCP tmeout issues in a device to switch application between WiFi and 4G LTE. If my application TCP was connected via 4G LTE initially, when WiFi is available, the network is switched to WiFi, but the application TCP connection would have 30 minutes timeout before it terminated the 4G LTE and reconnects to WiFi. That 30 minutes is too long. I checked TCP document for TCP_USER_TIMEOUT: TCP_USER_TIMEOUT Decreasing user timeouts allows applications to "fail fast", if so desired. Otherwise, failure may take up to 20 minutes with the current system defaults in a normal WAN environment. My question is, in boost asio socket, is there an API to change TCP_USER_TIMEOUT? Appreciate if showing an example or point me to a document how to do it. Thank you. Kind regards, - jh

2 3

Re: [boost] [Boost-users] Interest in a Unicode library for Boost?
by Zach Laine 30 Oct '19

30 Oct '19

On Wed, Oct 30, 2019 at 4:51 AM Leon Mlakar <leon(a)digiverse.si> wrote: > On 29.10.2019 17:11, Zach Laine wrote: > > > > >> - for the sake of completeness the normalization type used at the text >> level ought to be a policy parameter; although I do understand your >> arguments against it I think it should be there even at the cost of >> different text types being inoperable without conversions >> > > I disagree. Policy parameters are bad for reasoning. If I see a > text::text, as things currently stand, I know that it is stored as a > contiguous array of UTF-8, and that it is normalized FCC. If I add a > template parameter to control the normalization, I change the invariants of > the type. Types with different invariants should have different names. To > do otherwise is a violation of the single responsibility principle. > > Okay, the policy or not the policy was not my point ... it was to allow > for different underlying normalizations. Granted, it may only be important > to (a few) corner cases where input and/or output normalizations are given, > and your assessment that it may not be worth the effort is reasonable ... > unless you are aiming towards adding to the standard. Then the completeness > imho becomes more important. > > Frankly, I'm not proficient enough in the meta-programming to make a > strong case either for policy parameter or for explicit types/templates. I > just happen to prefer the policy based approach. > Understood. FWIW, the algorithms provided by Boost.Text make it possible to use any normalization representation, though at times conversions may be necessary. Some of those conversions are mandated by the Unicode standard itself -- you cannot feed NFC, NFKC, or NFKC to the collation algorithm, for instance (though implementations are possible for NFD and FCC). > > > - at the text level I'm not sure I'm willing to cope with different >> fundamental text types; I just want to use boost::text::text, pretty >> much the same as I use std::string as an alias to much more complex >> class template; heck, even at the string layer I'd probably prefer >> rope/contiguous concept to be a policy parameter to the same type >> template. >> > > That would be like adding a template parameter to std::vector that makes > it act like a std::deque for certain values of that parameter. Changing > the space and time complexity of a type by changing a template parameter is > the wrong answer. > > No, that is not making the std::vector to act as std::deque - the text > would still remain the text and act as a text, with the same interface. > It's more like FIFO implementation using either std::vector or std::dequeu > for its store - since in both cases the FIFO has the same interface and > functionally behaves the same, I really don't want two distinct types. The > type template with the parameter that makes the choice between the > underlying storage seems much more natural to me. > You example highlights my point. For N inputs to your FIFO queue, a deque underlying implementation is worst-case O(N). A vector implementation is worst-case O(N*N). The invariants of the type matter, and they matter a lot. Saying a foo may be like a bar or like a baz only work when bar and baz are so similar that you cannot observe a difference in the behavior of foo. Zach

1 0

[SPAM] istream_iterator_limited
by Frederick Gotham 28 Oct '19

28 Oct '19

- - - - WHY I NEEDED THIS: I wanted to open a file using "ifstream", and then I wanted to read 32 bytes from the file and feed them directly into boost::algorithm::hex. Unfortunately I couldn't do this because 'hex' takes two iterators [begin,end), and there's no alternative function "hex_n". So I had to read the file into a string first, and then pass the string to 'hex'. - - - - THE IDEA I CAME UP WITH: Open the file using "ifstream", and then use a special iterator that will stop reading from the file after 32 bytes, with syntax like this: ifstream logfile("log.txt"); hex( istream_iterator_limited<char>(logfile,32), istream_iterator_limited<char>(), g_some_global_container.begin() ); - - - - SAMPLE CODE: #include <cstddef> /* size_t */ #include <iterator> /* istream_iterator */ template <typename T> class istream_iterator_limited : public std::istream_iterator<T> { protected: std::size_t const m_limit; std::size_t m_current_count; public: /* Shorter names */ typedef std::istream_iterator<T> Base; typedef istream_iterator_limited<T> This; istream_iterator_limited(typename Base::istream_type &obj_stream, size_t const arg_limit) : Base(obj_stream), m_limit(arg_limit), m_current_count (1) { /* The initialiser list above does all the construction work */ } istream_iterator_limited(void) /* This gives the End-Of-Stream iterator */ : Base() , m_limit(0), m_current_count(1) { /* The initialiser list above does all the construction work */ } This &operator++(void) { if ( m_limit <= m_current_count ) { Base::operator=( Base() ); /* Becomes End-Of- Stream iterator */ } else { ++m_current_count; Base::operator++(); } return *this; } }; #include <algorithm> /* copy */ #include <string> /* string */ #include <sstream> /* istringstream */ #include <iostream> /* cout, endl */ #include <iterator> /* back_inserter */ auto main(void) -> int { std::istringstream iss("123456789"); std::string str; /* Let's use copy to read 5 char's into our string */ std::copy( istream_iterator_limited<char>(iss,5), istream_iterator_limited<char>(), std::back_inserter(str) ); std::cout << str << std::endl; str.clear(); /* Get another 3 */ std::copy( istream_iterator_limited<char>(iss,3), istream_iterator_limited<char>(), std::back_inserter(str) ); std::cout << str << std::endl; }

1 0

Re: [boost] disjoint_sets?
by Glen Fernandes 27 Oct '19

27 Oct '19

Peter wrote: > At some point we removed the disjoint_sets module from the develop branch, > but it's still on master. When are we going to remove it from master as > well? The relevant changes need to be merged from Graph develop to master, before we can retire the disjoint_sets repository entirely. John, any concerns about doing this now, before the 1.72 release progresses? Glen

1 0

disjoint_sets?
by Peter Dimov 25 Oct '19

25 Oct '19

At some point we removed the disjoint_sets module from the develop branch, but it's still on master. When are we going to remove it from master as well?

1 0

question re BOOST_NO_EXCEPTION
by Robert Ramey 25 Oct '19

25 Oct '19

I want to detect whether or not the -no_exception compile time flag has been used on gcc/clang. Will BOOST_NO_EXCEPTIONS do this? If not is there something I can use? Robert Ramey

5 10