November 2024 - Boost - lists.preview.boost.org

[review] [sqlite]
by Richard Hodges 04 Feb '25

04 Feb '25

Dear All, Surprise! The Boost formal review of the Boost SQLITE library starts *TODAY*, taking place from November 13th, 2024 to November 22nd, 2024 (inclusive). I apologise profusely for springing this on you without prior warning. The error is entirely mine. I am extending the period by one day to compensate. The library is authored by Klemens Morgenstern (@klemens-morgenstern in the CppLang slack). Documentation: https://klemens.dev/sqlite/ <https://anarthal.github.io/mysql/index.html> Source: https://github.com/klemens-morgenstern/sqlite <https://github.com/anarthal/mysql/> >From the documentation: boost.sqlite is a simple to use C++ sqlite library. It provides a modern interface using facilities like error_code, views (e.g. for blobs) and the ability to use boost.describe or boost.pfr for parameterised queries. Supported features include: - typed queries - prepared statements - json support - custom functions (scalar, aggregate, windows) - event hooks - virtual tables SQLite provides an excellent C-API, so this library does not attempt to hide, but to augment it. Please provide in your review information you think is valuable to explain your choice to ACCEPT or REJECT including SQLITE as a Boost library. Please be explicit about your decision (ACCEPT or REJECT). Some other questions you might want to consider answering: - Will the library bring additional out-of-the-box utility to Boost? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - Will the choice of API abstraction model ease the development of software that must talk to a SQLITE database? - Are there any immediate improvements that could be made after acceptance, if acceptance should happen? - Did you try to use the library? With which compiler(s)? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? More information about the Boost Formal Review Process can be found at: http://www.boost.org/community/reviews.html The review is open to anyone who is prepared to put in the work of evaluating and reviewing the library. Prior experience in contributing to Boost reviews is not a requirement. Thank you for your efforts in the Boost community. They are very much appreciated. Richard Hodges - review manager of the proposed Boost.SQLITE library Klemens is often available on CppLang Slack and of course by email should you require any clarification not covered by the documentation, as am I.

17 61

Pretty printer module
by Дмитрий Архипов 20 Dec '24

20 Dec '24

Recently Niall Douglas posted about his idea to embed GDB pretty printers into binaries using a header. At the time I was thinking about a good way to deploy pretty printers for JSON that facilitates their autoloading. After Niall's post I experimented a little bit more, and I came to the conclusion that indeed nothing beats embedding via a C++ header in terms of convenience. At the same time I was also thinking about testing that pretty printers do in fact work. Given that pretty printers (usually) are implemented as a Python module, it initially looked like one could just run a Python program and import GDB Python modules. But actually you cannot. It turns out, though, you can run a Python script with GDB as the interpreter. After several iterations I arrived at this setup: https://github.com/boostorg/json/blob/develop/test/printers.cpp. A script converts this file into a Python script that uses GDB to break on certain lines and check if a particular expression produces a particular output when printed. While doing all this I thought that most of this work can be useful to other libraries. So, I moved the reusable parts into a separate directory (https://github.com/boostorg/json/tree/develop/pretty_printers) and added both a b2 module, and a CMake module. For B2. Importing: https://github.com/boostorg/json/blob/develop/build.jam#L8-L9 https://github.com/boostorg/json/blob/develop/build/Jamfile#L13 (Re)generating the header: https://github.com/boostorg/json/blob/develop/build/Jamfile#L88-L95 Testing: https://github.com/boostorg/json/blob/develop/test/Jamfile#L96-L101 For CMake: Importing: https://github.com/boostorg/json/blob/develop/CMakeLists.txt#L54-L55 (Re)generating the header: https://github.com/boostorg/json/blob/develop/CMakeLists.txt#L56-L63 Testing: https://github.com/boostorg/json/blob/develop/test/CMakeLists.txt#L80-L88 My questions to the community: do you find this useful? Would you use it in your Boost or non-Boost library? If you do, the module should be moved to tools rather than stay in libs/json.

12 24

Any interest in a faster "any" type alternative?
by Marcus Tomlinson 06 Dec '24

06 Dec '24

I’m aware that the current implementation of any intentionally avoids copy assignments and uses only copy construction for all value updates. I believe this is due to the fact that copy assignment isn’t always available for all types - understandable. My proposal is what if we had a separate “fast-any” type that does utilise copy assignment when types match. In my own usage of this new type, I’ve found massive (roughly 2x) performance improvement on consecutive assignments of the same type. I’d like to gauge whether there would be any interest in adding such a type to the Boost library. Source code: https://github.com/cross-platform/fast_any Regards, Marcus Tomlinson

2 2

[release] Master branch is now open for bug fixes
by Ion Gaztañaga 04 Dec '24

04 Dec '24

Hi, The master branch is now open for bug fixes, test and documentation changes, but please follow the policy described in: https://github.com/boostorg/wiki/wiki/Releases%3A-Beta-Merge-Policy The next deadline: On December 4th, master closes for all changes. As always, the calendar is at https://www.boost.org/development/ — The release managers

9 22

Boost 1.87-beta1 still has sha1 failure in boost.compute
by Benjamin Redelings 02 Dec '24

02 Dec '24

Hi, It looks like boost 1.87-beta1 still has the compile failures from version 1.86 in boost::compute::detail::sha1. I see that there are patches from Aug 21, 2024 to address this in the `develop` branch of `boost.compute`. Are these likely to make it into boost 1.87? -BenRI

3 3

[release] Boost 1.87.0 beta 1 released
by Marshall Clow 19 Nov '24

19 Nov '24

Boost release 1.86.0 beta 1 is now available at: https://archives.boost.io/beta/1.87.0.beta1/source/ The SHA256 checksums are: 2e7cdf358526e8937b36b93fc96c501b8d6a0c8436e95e65440de31c48ec3086 boost_1_87_0_b1.tar.bz2 98a86940c13509dfd0288a3075280f46a76c9a3faeb8a9bf49ca7f9e6a271995 boost_1_87_0_b1.tar.gz 2ca4c019d0c96fd160dec5292a7a6bfcf7b4e592cd238a2207e17084f8021d08 boost_1_87_0_b1.zip 5ea32facd963dbb79ceb5bda7ef7546017ea5da854158f8933bbad74d6bbe622 boost_1_87_0_b1.7z This is slightly different than the RC3. Someone committed a documentation fix to master after we had started the release process, and rather than re-do the whole thing (and re-tag everything), we decided to go with the release that we prepared. The person who did this has been informed of the problems that he caused, and I don’t think he’ll do it again. Release notes (still need updates): https://www.boost.org/users/history/version_1_87_x.html Please try the beta and report any problems you encounter. Thanks to everyone who contributed to the release. -- Boost Release Team

4 6

Re: [boost] [review] [sqlite]
by Дмитрий Архипов 19 Nov '24

19 Nov '24

пт, 15 нояб. 2024 г. в 15:58, Klemens Morgenstern <klemensdavidmorgenstern(a)gmail.com>: > Would you also suggest automatic conversions or just stick to sqlite::value ? To be honest, I'm not sure. Automatic conversions would also have to rely on deduction, which would again inhibit the use of templates and overloaded functions. > I think you're right. I didn't really like the context idea in your > previous code example, but I think this can be rectified: instead of a > context object, you can pass in a tuple that gets forwarded to the > constructor of the function. > ... > create_aggregate_function<collect_libs, 1>("my-prefix", 42); First, I realised that there's no need to put any additional shared data into SQLite-managed memory, as you can always just add a reference member to the callable and store that shared data on your side. Second, I assume the point of this approach is to avoid copying the callable object, and also support non-default constructible callables. My approach uses the original callable as a kind of prototype, from which it copies new objects for every operation. To be honest, I don't think there should be any difference in performance between my approach with copying and yours with constructing. Ergonomically, I think mine is better. Yours may be looking more straightforward to users. One idea came to my mind. It's sometimes hard to determine which parts of the SQLite C API are supported by your library, and what specific components do it. So, I think you need a dedicated list of all SQLite C functions with comments like "supported via sqlite::backup", "supported via sqlite::mutex", "not supported because an analogous function X is supported ", "not supported because deprecated by SQLite", etc.

2 1

[graph] Temporary maintenance delays until the new year
by Jeremy Murphy 18 Nov '24

18 Nov '24

Dear Boost.Graph users, I'm in the process of moving to another country and changing jobs at the moment, so apologies that there has been and will continue to be a period of slow responses to (some) pull requests, etc until I get settled into a new routine. Regards, Jeremy

1 0

Re: [boost] [review] [sqlite]
by Ruben Perez 16 Nov '24

16 Nov '24

(CC-ing the list) On Sat, 16 Nov 2024 at 12:11, Klemens Morgenstern <klemensdavidmorgenstern(a)gmail.com> wrote: > > On Sat, Nov 16, 2024 at 7:07 PM Ruben Perez <rubenperez038(a)gmail.com> wrote: > > > > > > 3. What's the rationale behind BOOST_SQLITE_NO_VIRTUAL? Wouldn't > > > > setting it cause trouble, being a compiled library? > > > > > > It would. The idea is that you can use that for constrained (i.e. > > > embedded environments) to avoid the unnecessary vtable and to enforce > > > devirtualization if your compiler misses this. > > > > If I have read the code correctly, these functions seem to only be > > used in headers. Why do they need to be virtual? It looks like it > > could have been made a compile-time interface (i.e. a concept), > > completely avoiding the need for the macro. What's the rationale > > behind this? > > That's correct, that's also what it was originally. But the error > messages were horrendous. > By creating a base class you get good error messages (purely virtual > because method X is missing) and the compiler is still compelled to > devirtualize by the way it's used. > And because it's effectively unused, you can disable it. Couldn't you achieve a similar effect (scoped to C++20 and later) by conditionally using concepts? In a way similar to what Asio does to diagnose completion tokens (i.e. BOOST_ASIO_COMPLETION_TOKEN_FOR).

2 1

Re: [boost] [review] [sqlite]
by Ruben Perez 16 Nov '24

16 Nov '24

(CC-ing the list) On Sat, 16 Nov 2024 at 11:55, Klemens Morgenstern <klemensdavidmorgenstern(a)gmail.com> wrote: > > On Sat, Nov 16, 2024 at 6:47 PM Ruben Perez <rubenperez038(a)gmail.com> wrote: > > > > What's the current recommended way to consume the library? Installing > > it with CMake seems to only install the binaries (and not the > > headers/cmake find_package scripts), and I haven't found a Jamfile to > > build the library as part of the Boost superproject. > > FetchContent + add_subdirectory is what I do. > > There also is a Jamfile in /build, but it's going to just to sqlite3, > because there's no `using sqlite ;` available at the moment. That's > probably only going to work on linux as of now. > Thanks, I completely missed out the Jamfile because of an unfortunate IDE setting.

1 0