- Boost - lists.boost.org

Introduction
by Samrat Patel 25 Feb '21

25 Feb '21

Hello Boost C++ Community, I am Samrat from Delhi Technology University and currently, I am pursuing my bachelor's in Computer Engineering(CoE). I have 3 years of experience in C++. I am extremely eager and excited about contributing to various projects of Boost C++. I am willing to participate in GSOC'21 with Boost C++. I would feel indebted if you could guide me in this regard. Regards Samrat Patel

4 3

property_tree in need of a maintainer
by Richard Hodges 25 Feb '21

25 Feb '21

Dear all, I am offering to become the/a maintainer of property_tree as part of my work for the C++ Alliance. Sincerely, -- Richard Hodges hodges.r(a)gmail.com office: +442032898513 home: +376841522 mobile: +376380212

3 3

Reminder: Describe needs a review manager
by Peter Dimov 25 Feb '21

25 Feb '21

This is a reminder that my library Describe https://github.com/pdimov/describe https://pdimov.github.io/describe/doc/html/describe.html needs a review manager. Describe is a library that allows programmers to annotate their classes (and enumerations) in order to enable simple reflection. It provides a very important fundament on which other libraries can build upon to provide automatic support for user-defined types. For example, given an annotated type, Boost.JSON can automatically provide conversions from/to json::value. Boost.ContainerHash can automatically provide a hash function hash_value for the type. Boost.Serialization can automatically provide serialization support. See the examples: https://pdimov.github.io/describe/doc/html/describe.html#example_to_json https://pdimov.github.io/describe/doc/html/describe.html#example_from_json https://pdimov.github.io/describe/doc/html/describe.html#example_serializat… Other JSON (and serialization) libraries already offer a similar mechanism, e.g. https://github.com/nlohmann/json#arbitrary-types-conversions. But since each library has its own private way to annotate types, a programmer needs to repeat the type annotations for every library he wants his type to be known to. This is unnecessary and undesirable, and a standard mechanism to describe types avoids it. Describe is intended to be this standard mechanism, and I believe that we need it in Boost sooner rather than later. Thanks in advance to whoever volunteers.

7 11

Re: [boost] Reminder: Describe needs a review manager
by Bjorn Reese 25 Feb '21

25 Feb '21

On 2021-02-23 19:56, Peter Dimov via Boost wrote: > Describe is a library that allows programmers to annotate their classes > (and enumerations) in order to enable simple reflection. It provides a > very important fundament on which other libraries can build upon to > provide automatic support for user-defined types. How does it differ from Boost.Fusion?

2 1

[boost-ext] Looking for Review Manager/s
by Krzysztof Jusiak 24 Feb '21

24 Feb '21

Hi, I just wanted to share, potentially useful for the Boost and C++ community, libraries and ask if anyone would be willing to become a Review Manager for any of them? [boost-ext] (https://github.com/boost-ext) is a collection of C++ libraries with aspirations to be included in Boost. Libraries can be characterized by: * Modern C++ (>= C++14) * Header/Single Module only * No dependencies ATM, [boost::ext] consists of four core libraries: * DI - Dependency Injection Library overview: standard: C++14 single header with no dependencies (neither STL nor Boost is required) release: 1.2.0 (first release - 2014) key features: - supports macro-free constructor injection - supports templates injection - quick compilation-times - highly optimized code generation try it online: https://godbolt.org/z/5qTKhf source code: https://github.com/boost-ext/di documentation: https://boost-ext.github.io/di/ * SML - State Machine Library overview: standard: C++14 single header with no dependencies (neither STL nor Boost is required) release: 1.1.4 (first release - 2016) key features: - much faster compilation-times than Boost.MSM (up to 60x faster) - highly optimized and customizable code generation - suitable for embedded systems try it online: https://godbolt.org/z/y99L50 source code: https://github.com/boost-ext/sml documentation: https://boost-ext.github.io/sml/ * UT - Unit Testing Framework overview: standard: C++20 single header with no dependencies (STL required) release: 1.1.8 (first release - 2019) key features: - macro-free - minimal boilerplate - fast compilation-times and execution try it online: https://godbolt.org/z/Jqb5Ye source code: https://github.com/boost-ext/ut documentation: https://boost-ext.github.io/ut * TE - Run-time polymorphism (type erasure) library overview: standard: C++17 single header with no dependencies (STL required) release: - key features: - simple interface - highly optimized code generation try it online: https://godbolt.org/z/xY9MEq source code: https://github.com/boost-ext/te documentation: https://github.com/boost-ext/te All libraries (except TE) were successfully deployed in the production systems. Some, such as DI and SML are used by well known/big IT companies as well. If anyone is interested in becoming a Review Manager for any of the libraries, I'd really appreciate it and I'll more than happy to address any issues/requests before the review as well as help with any process-related tasks. Thank you very much, -Kris

12 43

Getting stated with boost and CMake
by pbristow＠hetp.u-net.com 24 Feb '21

24 Feb '21

Having spent a decade watching the Cmake versus bjam/b2 battle, I had thought it wise to wait until the dust has settled. It would appear that the enthusiasm for CMake and Boost is much greater among consumers than producers ☹ But recently I have been working on a project that is possible Boost library and thought that I would dip my toe in the water. After some research, I am still puzzled how I should replace a simple b2/bjam program (say a classic “hello World”) that is run like this \example > b2 -a toolset=msvc,gcc,clang cxxstd=14 release > my_log.log The jamfile contains run hello_world.cpp ; # Simplest hello_world, no other includes apart from iostream. And the b2 run .log contains some outputs of "Hello world" and 3 nice **passed** lines and ...updated 3(?) targets..., one for each compiler (and version too, perhaps with some potentially using build info too), and return exit_success value. (I also would expect to get a simple setup to run a test using the /included version of unit_test_framework. Trying to walk before I fall over running, I have avoided any pre-compiler libraries, at least at first.) After some research (getting as far as generating a Visual Studio project, where I can intervene manually to build and run my hello_world program), I am still unclear how to replicate this b2 test to end with a .exe run and some log file with pass/fail indications. I am of course building on Windows 10 with three recent versions of MSVC, GCC and Clang compilers working, and in my bjam/b2 user-config.jam. Advice from less-than-novice CMakers most welcome. Thank you. Paul

1 0

GSoC 2021 new policies
by Pranam Lashkari 23 Feb '21

23 Feb '21

Hello, To all the potential mentors and students this year GSoC is different from all the previous seasons, so whenever you are planning/proposing/adding a project in GSoC this year, keep the following things in mind: *Smaller project size** - *all students participating in the 2021 program will be working on a 175 hour project (instead of a 350 hr project). *Shortened coding period* - the *coding period will be 10 weeks* with a lot more flexibility for the mentor and student to decide together how they want to spread the work out over the summer. *2 evaluations (instead of 3)* - There will be an evaluation after 5 weeks and the final evaluation will take place after the 10th week. -- Thank you, Pranam Lashkari, https://lpranam.github.io/

1 0

Releasing property_tree updates
by Jared McIntyre 20 Feb '21

20 Feb '21

I noticed there are several updates that have merged into the develop branch for property_tree, but it seems none of them have made it into master for release. Is there any chance that a new version with the fixes may be pushed out in a future release? Thanks, Jared

2 1

boost test: first test organization examples using deprecated init_unit_test_suite?
by Dennis Luehring 15 Feb '21

15 Feb '21

according to this example, i should use init_unit_test_suite https://www.boost.org/doc/libs/1_75_0/libs/test/doc/html/boost_test/tests_o… but it seems that init_unit_test_suite function is deprecated (starting with 1.59) https://www.boost.org/doc/libs/1_75_0/libs/test/doc/html/boost_test/adv_sce… so its unclear to me if i should (still) use this deprecated function or go witht BOOST_AUTO_TEST_SUITE/BOOST_AUTO_TEST_CASE

1 0

[build] "Unknown target type EXE"
by John Maddock 09 Feb '21

09 Feb '21

I've managed to get various architectures tested in qemu-emulation in this PR: https://github.com/boostorg/config/pull/366, with help from https://github.com/uraimo/run-on-arch-action However, for armv7 alone I see: /home/runner/work/config/boost-root/tools/build/src/build/type.jam:158: in type.validate from module type error: Unknown target type EXE (builtin):-1: in sequence.transform from module sequence /home/runner/work/config/boost-root/tools/build/src/build/generators.jam:239: in generator.__init__ from module object(installed-exe-generator)@4 /home/runner/work/config/boost-root/tools/build/src/tools/stage.jam:568: in class(a)installed-exe-generator.__init__ from module object(installed-exe-generator)@4 /home/runner/work/config/boost-root/tools/build/src/kernel/class.jam:90: in new from module class /home/runner/work/config/boost-root/tools/build/src/tools/stage.jam:596: in load from module stage /home/runner/work/config/boost-root/tools/build/src/kernel/modules.jam:295: in import from module modules /home/runner/work/config/boost-root/tools/build/src/tools/builtin.jam:27: in load from module builtin /home/runner/work/config/boost-root/tools/build/src/kernel/modules.jam:295: in import from module modules /home/runner/work/config/boost-root/tools/build/src/build-system.jam:12: in load from module build-system /home/runner/work/config/boost-root/tools/build/src/kernel/modules.jam:295: in import from module modules /home/runner/work/config/boost-root/tools/build/src/kernel/bootstrap.jam:139: in boost-build from module /home/runner/work/config/boost-root/boost-build.jam:17: in module scope from module This is while running ./b2 headers. The initialization/setup code is the same for each architecture as they're run in a GHA matrix so I don't think I've goofed in the CI script. Anyone any ideas what might cause this? Many thanks, John. -- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

2 1