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

[program_options] Proposal: self-contained, header-only port of Boost Program Options library
by Vicram Rajagopalan 17 Sep '19

17 Sep '19

I am interested in creating a header-only implementation of the Boost Program Options library that only depends on the C++ standard library. Program Options uses several other Boost libraries, so I would have to re-implement some of it using standard library constructs. I have 2 questions for the community: 1. Would you use something like this if it were available? 2. Do you know of any implementation details of Program Options which might make some part of this difficult or impossible? To be clear, I do not intend for this to be merged into Boost in any form. Rationale: There is no portable command-line argument-parsing capability in the C++ standard library. There's getopt, but that's in unistd.h which is only available on Unix-based systems. The only widely-used C++ command-line parsing library I am aware of is Program Options, but that requires adding a dependency on Boost to your project, which seems like overkill to me. I would like to be able to simply add a project as a submodule in my Git repo and #include it without even having to add anything to my build files. The goal is to ensure that the library is as portable and easy to include as possible, because it shouldn't be difficult to parse command-line options. I appreciate any thoughts, comments, or criticisms! -Vicram Rajagopalan

9 14

[Boost.numeric.ublas] Compiler warnings when building with O2 optimizations and NDEBUG defined
by Albert Perlman 17 Sep '19

17 Sep '19

I am using boost v1.69, compiling with g++-7 for an x86 target. If I build with -O2 optimization flags when NDEBUG is defined, I get the following compiler warning: ./../boost/numeric/ublas/matrix_expression.hpp:59:20: error: ‘*((void*)&<anonymous> +8)’ is used uninitialized in this function [-Werror=uninitialized] return e_.size2 (); If I add -fno-partial-inling to the compiler flags, this makes the warning go away. This warning does not appear if NDEBUG is not defined, regardless of optimization flags. This behavior is the same with boost v1.71. I would like to build with the -fpartial-inling optimization when NDEBUG is defined. Is there a workaround to fix this warning? -- Albert -- IMPORTANT: The information contained in this transmission may be privileged, proprietary and confidential and protected from disclosure. It is intended only for the intended recipient. If you are not the intended recipient or a person responsible for delivering this transmission to the intended recipient, you may not disclose, copy or distribute this transmission or take any action in reliance on it. If you received this transmission in error, please notify us immediately by replying to this message and please dispose of and delete this transmission. Thank you. Yaskawa America, Inc.

1 0

Write data to NAND flash file system
by JH 13 Sep '19

13 Sep '19

Hi, I am using boost::filesystem to write / remove files to NAND flash file system where it writes by pages, the system can cache and pack data upon write back to avoid segmentation if fsync(), fdatasync(), O_SYNC or a sync mounted filesystem are not used to force write. Will the boost::filesystem::ofstream and operator<< involve any of sync call? Which IO library is not using sync call? Thank you. Kind regards, - jupiter

1 0

math
by Gero Peterhoff 12 Sep '19

12 Sep '19

Hello Developers, Hello John, thanks for making the float128_t features I missed available in boost 1.71. But: - I miss in boost::math::constants log2_e (M_LOG2E); You have written in the documentation that all constants are now available; are there any other constants missing? - in boost/multiprecision/float128.hpp, the value in numeric_limits<float128_t>::is_bounded must be true Thanks and Greetings Gero

2 1

Secure-by-default networking
by Alex Christensen 11 Sep '19

11 Sep '19

At https://github.com/boostorg/asio/pull/283 <https://github.com/boostorg/asio/pull/283> I’ve attached a proof-of-concept which explores making ASIO secure by default. The C++ committee is discussing what secure-by-default networking would look like in the soon to be published papers P1860 and P1861. Since the C++ Networking TS is based on ASIO, this seems like a good place to try things out. The implementation uses BoringSSL for its crypto and Security.framework to evaluate certificates against the root certificates trusted by the system. I've implemented enough to see what the API shape would need to be, and it works with basic client and server programs. I’d love to get your feedback on this initial work, including any implementation concerns you have and suggestions on portability. I don’t think the patch is ready to commit as-is.

3 2

Re: [boost] Secure-by-default networking
by Bjorn Reese 11 Sep '19

11 Sep '19

On 9/11/19 1:35 AM, Alex Christensen via Boost wrote: > At https://github.com/boostorg/asio/pull/283 <https://github.com/boostorg/asio/pull/283> I’ve attached a proof-of-concept which explores making ASIO secure by default. The C++ committee is discussing what secure-by-default networking would look like in the soon to be published papers P1860 and P1861. Since the C++ Networking TS is based on ASIO, this seems like a good place to try things out. Please don't. There are plenty of networking applications that do not use SSL. Use ssl::stream if you want secure-by-default.

1 0

Re: [boost] Requesting opinions on CECS (C/C++ Error Control) library for possible boost implementation.
by Bjorn Reese 11 Sep '19

11 Sep '19

On 9/8/19 3:17 PM, Terablade via Boost wrote: > I have also released the library on github:https://github.com/terablade2001/CECS This library is described as handling "textual informative error control" using severity levels, so the first question that comes to mind is how this differs from Boost.Log? PS: The standard as reserved all symbol names starting with an underscore followed by a capital letter.

2 1

[Random] Proposal: Faster RANLUX engines
by Christoph Conrads 10 Sep '19

10 Sep '19

Boost.Random and the C++11 standard library ship with a 24- and a 48-bit RANLUX pseudo-random number generator (PRNG). I propose to add 32- and 64-bit RANLUX PRNGs because they are at least 40% faster. Additionally, the 32-bit RANLUX PRNG can be implemented as follows: #include <boost/cstdint.hpp> #include <boost/random.hpp> namespace br = boost::random; typedef br::subtract_with_carry_engine<boost::uint32_t,32,3,17> ranlux32_base; typedef br::discard_block_engine<ranlux32_base, 389, 16> ranlux32; There is C++98 benchmark code at the end of this e-mail requiring only Boost and a C++ compiler. Below I will briefly discuss the theory behind RANLUX PRNGs, where the new generators are coming from, and why the 64-bit RANLUX PRNG requires (a few lines of) new code. Drawing from RANLUX PRNGs is a two-step process. In the first step a value is drawn from a "subtract-with-borrow" (SWB) generator implementing b-bit modular arithmetic [1]. Then, values are generously discarded yielding uniformly distributed values (uniform in a dynamical systems model) [2]. The RANLUX PRNGs using 24- and 48-bit arithmetic always gave me an itch so I looked into the motivation behind this. It turns out [3] that this restriction arose likely from a) computational limitations in the 1990s and b) Lüscher's interest in the generation of floating-point numbers (single-precision floating-point numbers have 24-bit significand). SWB PRNGs come in two flavors (Type I, Type II) and they make use of three parameters called base b, short lag s, and long lag r. Using modern prime factorization methods, one can quickly come up with the 32-bit PRNG above, a Type I SWB generator with b=2^32, r=17, and s=3. This one can be implemented as shown above. To generate 64-bit values, one should use a Type II SWB with b=2^64, r=62, and s=5 (all other 64-bit generators with b=2^64 and r < 100 will be awfully slow). What distinguishes the different types of SWBs is the recurrence for the computation of variates. For Type I it is x_n := (x_{n-s} - x_{n-r} + c_n) mod b, where c_n is a carry bit. For Type II it is x_n := (x_{n-r} - x_{n-s} + c_n) mod b. (Observe the order of long lang and short lag in these formulas.) Type II SWBs are not difficult to implement but it requires either a modification of `subtract_with_carry_engine` or a new class. Let me know what you think about this proposal. Christoph Conrads [1] G. Marsaglia, A. Zaman: "A New Class of Random Number Generators". 1991. URL: https://www.jstor.org/stable/2959748 [2] Martin Lüscher: "A Portable High-Quality Random Number Generator for Lattice Field Theory Simulations". 1994. URL: https://arxiv.org/abs/hep-lat/9309020 [3] Christoph Conrads: "Faster RANLUX Pseudo-Random Number Generators". 2019. URL: https://christoph-conrads.name/faster-ranlux-pseudo-random-number-generators // Build with: // c++ -Wextra -Wall -std=c++98 -pedantic benchmark.cpp -O3 \ // -march=native -DNDEBUG -lboost_chrono -lboost_system #include <boost/chrono.hpp> #include <boost/cstdint.hpp> #include <boost/random.hpp> #include <cassert> #include <cstdio> #include <limits> #include <string> namespace chrono = boost::chrono; typedef chrono::milliseconds milliseconds; typedef chrono::process_cpu_clock my_clock; namespace br = boost::random; typedef br::subtract_with_carry_engine<boost::uint32_t,32,3,17> ranlux32_base; typedef br::discard_block_engine<ranlux32_base, 389, 16> ranlux32; struct dummy_engine { typedef boost::uint32_t result_type; static result_type max() { return std::numeric_limits<result_type>::max(); } static result_type min() { return std::numeric_limits<result_type>::min(); } result_type operator() (); result_type state_; }; dummy_engine::result_type dummy_engine::operator() () { return state_++; } std::string get_name(const dummy_engine&) { return "dummy-prng"; } std::string get_name(const br::ranlux24&) { return "ranlux24"; } std::string get_name(const br::ranlux48&) { return "ranlux48"; } std::string get_name(const ranlux32&) { return "ranlux32";} template<typename Generator> typename Generator::result_type draw(Generator& gen) __attribute__((noinline)); template<typename Generator> typename Generator::result_type draw(Generator& gen) { return gen(); } template<typename Generator> void run(boost::uintmax_t num_draws) { assert(Generator::min() == 0); unsigned w = Generator::max() == std::numeric_limits<boost::uint64_t>::max()?8u: Generator::max() == (UINTMAX_C(1)<<48) - 1u ?6u: Generator::max() == std::numeric_limits<boost::uint32_t>::max()?4u: Generator::max() == (UINTMAX_C(1)<<24) - 1u ?3u: Generator::max() == std::numeric_limits<boost::uint16_t>::max()?2u: Generator::max() == std::numeric_limits<boost::uint8_t>::max() ?1u: 0u ; Generator gen; my_clock::time_point t_0 = my_clock::now(); for(uintmax_t i = 0; i < num_draws; ++i) draw(gen); my_clock::time_point t_1 = my_clock::now(); milliseconds t_ms = chrono::duration_cast<milliseconds>(t_1 - t_0); double bytes_per_sec = w * num_draws * 1000u/double(t_ms.count()); std::string name = get_name(gen); boost::uint16_t dummy = boost::uint16_t(gen()); std::printf( "%-26s | %10lu | %20.2e | %hu\n", name.c_str(), t_ms.count(), bytes_per_sec, dummy ); } int main() { boost::uintmax_t num_draws = UINTMAX_C(100000000); run<dummy_engine>(num_draws); run<br::ranlux24>(num_draws); run<ranlux32>(num_draws); run<br::ranlux48>(num_draws); }

1 0

Interest in circular span?
by Bjorn Reese 10 Sep '19

10 Sep '19

I am working on a circular queue library that contains a non-owning circular span, a fixed-sized circular array, and a dynamically resizable circular vector. Would you be interested in adding such a library to Boost? The design is inspired by Boost.CircularBuffer, std::span, and P0059R4 std::experimental::ring_span. The code can be found at: https://github.com/breese/trial.circular The documentation can be found at: https://github.com/breese/trial.circular/tree/develop/doc circular::span can be used to implement the P0059R4 ring_span, as shown in one of the example: https://github.com/breese/trial.circular/blob/develop/example/p0059/ring_sp… circular::span can also be used to implement most parts of boost::circular_buffer; all except insertions and erasure at arbitrary positions.

7 10

[Intrusive] Movable intrusive container elements?
by Phil Endecott 09 Sep '19

09 Sep '19

Dear Experts, Is it possible to make intrusive container elements movable? Here's the scenario. Say I have struct Thing { int id, string name }; and I want a container of those indexed by both the id and the name. Using Boost.Intrusive I can add two hooks to the struct and have two intrusive::sets, one using id as the key and the other using name. All good. But say my ids are a contiguous range of integers starting at zero. It would be much better to store the Things in a vector (or similar), indexed by the id, and use Intrusive only for the name index. Or if my ids are not contiguous, I might still prefer to keep the things in a vector sorted by id and do id lookup by binary search (i.e. a flat_set). In both cases, the issue is that when the vector expands or is sorted the elements are moved, and this will invalidate the pointers used for the name index. Is is possible to fix this using move constructors and move assignment for the hooks? I.e. those operations could adjust the pointers pointing to the element's old location to point to its new location. (This has some similarities to how auto-unlink hooks already fix pointers to remove the being-deleted item.) Maybe there is some complication that makes this impossible. Or maybe this is already possible?? Any thoughts anyone? Regards, Phil.

2 2