- Boost - lists.boost.org

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

Boost logo font?
by Hans Dembinski 23 Oct '19

23 Oct '19

Dear all, does someone remember which font was used for the Boost logo on boost.org? Is it possible to get this font to make another logo? I want to make a logo for Boost.Histogram. Best regards, Hans

4 11

New JSON library from the maker of Beast!
by Vinnie Falco 23 Oct '19

23 Oct '19

I've been working on a massively-multiplayer online blackjack casino server, called Beast Lounge [1]. The server and client communicate using JSON-RPC over WebSocket. I have developed a brand-new JSON library for this project, in accordance with the following design goals: * Robust support for custom allocators throughout. * Array and object interfaces closely track their corresponding C++20 container equivalents. * Use `std::basic_string` for strings. * Minimize use of templates for reduced compilation times. * Parsers and serializers work incrementally (['online algorithms]). * Elements in objects may also be iterated in insertion order. You can see the JSON library in development here: https://github.com/vinniefalco/json Is there any interest in proposing this for Boost? I'm happy to hear feedback or answer questions about this library. Feel free to open an issue on the repository, or reply here. Thanks [1] <https://github.com/vinniefalco/BeastLounge>

21 68

[lockfree][Interprocess] - SPSC queue in shared memory cause SEG fault
by Saravanan A 23 Oct '19

23 Oct '19

Hi Team, We Currently trying to develop a prototype with boost libraries, where we are facing an issue in it with boost library. It would be great if someone help out here . we are having two process where one process create “*managed xsi shared memory”* and other get attached to it. Here we trying to have a spsc queue in a shared memory structure which will be accessed by both process . Where SPSC queue data is a user defined class object. when we have a integer in ” *Mydata”* (Class name) mentioned below and try to do a Push /pop operation in the spsc queue on respective process it was working fine without any issues. But the same framework when we have an array of greater size(more than 28 byte around. Example: a[7] ) .We are facing a crash in consumer side . (It seems spsc queue write somewhere in process heap memory after first pop leading to memory corrupt ) please let us know if there any open issue in this ? or if we have used boost library incorrectly ? Thanks for reading. I would be thankful for any information you may have to offer. *Backtrace:* /data/users/kapparao/example_boost/anony-SHM-managed> $./processB Consumer-TX - Read data from Q - [1,b] notify_one@93 - I am here! notify_one@159 - I am here! Segmentation fault (core dumped) /data/users/kapparao/example_boost/anony-SHM-managed> $gdb ./processB GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-115.el7 Copyright (C) 2013 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html > This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-redhat-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from /data/users/kapparao/example_boost/anony-SHM-managed/processB...done. (gdb) r Starting program: /data/users/kapparao/example_boost/anony-SHM-managed/./processB [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". Consumer-TX - Read data from Q - [1,b] Program received signal SIGSEGV, Segmentation fault. 0x00007ffff7bcb09b in pthread_cond_signal@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 Missing separate debuginfos, use: debuginfo-install glibc-2.17-292.0.1.el7.x86_64 libgcc-4.8.5-39.0.1.el7.x86_64 libstdc++-4.8.5-39.0.1.el7.x86_64 (gdb) bt #0 0x00007ffff7bcb09b in pthread_cond_signal@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00000000004063de in boost::interprocess::ipcdetail::posix_condition::notify_one (this=0x28) at ../../boost/include/boost/interprocess/sync/posix/condition.hpp:160 #2 0x00000000004066e1 in boost::interprocess::interprocess_condition::notify_one (this=0x28) at ../../boost/include/boost/interprocess/sync/interprocess_condition.hpp:94 #3 0x0000000000402941 in main () at processB.cpp:42 Attached the complete code in tar for your reference. *Compilation and Execution* : *Process A : * Compilation syntax : c++ my_data.cc processA.cpp -I < boost_header_file_path> <boost_lib_path> -lpthread -g -o processA -std=c++11 Execution syntax : ./processA *Process B :* Compilation syntax : c++ my_data.cc processB.cpp -I < boost_header_file_path> <boost_lib_path> -lpthread -g -o processB -std=c++11 Execution syntax : ./processB *Thanks in advance !!!!!* Regards, saravanan =====================================================

2 1

Re: [boost] New JSON library from the maker of Beast!
by Daniel Frey 23 Oct '19

23 Oct '19

> On 23. Oct 2019, at 00:33, Vinnie Falco <vinnie.falco(a)gmail.com> wrote: > > On Tue, Oct 22, 2019 at 3:13 PM Daniel Frey via Boost > <boost(a)lists.boost.org> wrote: >> That sounds like you should stop using the STL altogether. What if std::string is suddenly 2x slower? So... no, I don't buy that argument. >> >> I just switched our JSON library <https://github.com/taocpp/json> from >> our own classic enum+union implementation (back from the C++11 days) >> over to std::variant (as we are now C++17 anyways). > > Any idea why taocpp compiled with optimizations is 5 to 10 times > slower than the other libraries at parsing the same inputs? Yeah... I'd actually *try* to blame MSVC here :) We haven't benchmarked our libraries on Window as we are not Windows users ourselves. The numbers on Linux/MacOS should look different. Have you tested there as well? So Emil's argument has some truth to it, but still I'd rather like to see the STL to improve rather than rolling back. But I haven't even verified it, so take that with a grain of salt. > It seems like there's this thing called PEGTL which has some large > number of functions showing up as taking up time in the profile? What > is PEGTL? The PEGTL is the Parsing Expression Grammar Template Library <https://github.com/taocpp/PEGTL>, our general-purpose parser library. the JSON library actually started out as a benchmark for the PEGTL. Obviously, the parser spends most time in some methods from the PEGTL. And older version that are in the nativejson-benchmark were doing quite well for a general-purpose parser framework <https://github.com/miloyip/nativejson-benchmark#parsing-time>. Not as fast as RapidJSON, but that also largely depends on the design choices for the value type to hold the result.

2 1