October 2019 - Boost - lists.preview.boost.org

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

Multi-Dimensional Dynamic Array Boost Library Proposal
by Richard Hogaboom 24 Oct '19

24 Oct '19

I've written a library at GitHub/rahogaboom/daa that does dynamic array allocation in ptr to ptr ... style that is very simple to use(only two routines), header file only, can allocate an unlimited number of dimensions with subscripts for each dimension starting at an arbitrary number e.g. 0, 1, -5 etc, can allocate anything you can take sizeof() and allocates all in one contiguous block(stack, heap) for easy freeing. I'm aware of the Boost.MultiArray library, however, I think daa has some advantages. Specifically, a. each dimension has it's own starting subscript b. it's relative simplicity(2 routines) c. it's longevity - 30 years and two articles d. also can be used in a C only environment. Following is the points noted in the GitHub README.md: |Library: daa.hpp Dynamic Array Allocator - C++ header file only library - ptr to ptr to ... style arbitrary N dimensional array allocator of anything you can take sizeof() - arbitrary starting subscript(0, 1, -10, ...) for each separate dimension - Note: for each array dimension the starting subscript and dimension size determine the valid subscripts for that dimension - any index outside that range is invalid and will give unpredictable results - allocates anything of any type(double, int, long, struct, ...) - one contiguous block allocation of memory for all ptr's and data(locality of reference and easy free()) - array or slices of array can be passed to subroutines to any depth, modified there, and be seen at all levels - simple library, two routines(das()(calculate space needed) and daa()(allocate ptr to ptr ... array)) - no library dependencies(except standard header files) - initialization pointer argument set to instance of initialized type or NULL for no initialization - implemented by a recursive routine(ptr_init()) which calls two other different recursive routines(off() and doff()) - see article in Embedded Systems Programming, Dec. 2000, "Flexible Dynamic Array Allocation"(included) - see article in The C Users Journal, Nov. 1990. "A Flexible Dynamic Array Allocator"(included) - 18 verification tests that show code usage examples, see daa_test.cpp - see cut/paste Examples section and API(das(), daa()) section below - a daa-compile.tar file is provided with a non-header compiled(clang, clang++, gcc, g++) version - for an excellent reference on this type of array(ptr to ptr to ...) access see Numerical Recipes in C, Press, Flannery, Teukolsky, and Vettering, Cambridge University Press, 1992, pg. 20-23. Ch. 1 Preliminaries -> 1.2 Some C Conventions for Scientific Computing -> Matrices and Two-Dimensional Arrays. From the above reference read: 'Here is our bottom line: We avoid the fixed-size two-dimensional arrays of C as being unsuitable data structures for representing matrices in scientific computing. We adopt instead the convention “pointer to array of pointers,” with the array elements pointing to the first element in the rows of each matrix.' - this file is the entire documentation needed to use the library - Author: Richard Hogaboom, richard.hogaboom(a)gmail.com| | Usage: - das() - find size necessary malloc()(or whatever memory allocation routine) - allocate memory daa() - populate allocated memory - allocate auto stack or static area storage e.g. unsigned char mem[SIZE] das() - determine if array will fit in mem[] daa() - populate allocated memory | |Example:| | int err_code = 0; int asize = 0; char *mem_ptr; unsigned int d[4] = {3, 5, 4, 2}; /* dimensions */ int st[4] = {-1, -5, 10, 0}; /* starting subscripts */ double ****array = NULL; /* array pointer */ asize = das(sizeof(double), 4, d, &err_code); mem_ptr = (char *)malloc(asize); array = (double ****) daa(sizeof(double), 4, d, st, &err_code, mem_ptr, NULL);| | double d = array[-1][-5][10][0];| -- Richard A Hogaboom 16 Alprilla Farm Road Hopkinton, MA 01748-1922 richard.hogaboom(a)gmail.com www.linkedin.com/in/richardhogaboom/ www.github.com/rahogaboom M508-330-3775

2 1