September 2025 - Boost - lists.boost.org

Master regression tests failing
by Tom Kent 12 Oct '25

12 Oct '25

There seems to be a problem on master with all tests failing. It results in this in the log: error: Unable to find file or target named error: '/var/boost/run/boost_root/libs/system/build//boost_system' error: referred to from project at error: '../libs/graph_parallel/test' error: could not resolve project reference '/var/boost/run/boost_root/libs/system/build' Tom

4 4

[container] New deque implementation and future plans
by Ion Gaztañaga 10 Oct '25

10 Oct '25

Hi, I've been working lately on a new deque implementation for Boost.Container. The original uses the classic SGI STL-based data structure, that is quite bulky. The new implementation is already on develop and ready to be merged to master for Boost 1.90 The new implementation will try to be faster than std implementations (I probably need to work more on that with benchmarks), but more importantly, can allow some additional features. Some changes: - sizeof(deque) was 10 words, now is 4 words. Probably the lightest implementation around. - sizeof(deque::iterator) was 4 words, now is is 2 words (similar to libc++ and MSVC).) - Several internal algorithms were reimplemented to take advantage of the segmented nature of deque. - Defaults were slightly changed, 64 bit platforms now use 1024 byte blocks by default instead of the SGI classic 512 byte blocks (still far from libc++'s 4K blocks). - The new implementation eases further deque-like variations and optimizations in the future. Some planned features - Add a "stored_size_type" option so that the sizeof deque can be further decreased (probably down to 3 words) for those in 64 bit platforms that don't need more than 4G elements in deque. - Add a single-ended variation ("seque" might be confusing name because the data structure would not longer be a queue, but a segment-based sequence with random-access). Some people use deque to have a random-access container that avoids vector-like reallocations and guarantees stable pointers and references when inserting on the back. A double-ended container is sometimes sub-optimal for those use cases. - Add options (or maybe different containers or aliases reusing parts of the implementation) that can offer "reserve/capacity"-like features, so that a programmer can pre-allocate all the blocks that's going to use avoiding allocation performance penalties on hot code. I'll update the "Draft Development Plan for Boost.Container" (https://docs.google.com/document/d/1VdMTheFUczC946dP3VKPseOoUq3sVKjU73oMvK8…) with these proposals. Of course, I'm open to new proposals/features. If any booster is eager to test the new deque implementation or wants to suggest a benchmark/use-case that could be useful for Boost.Container users, please let me know! If anyone detects a bug in the new implementation please notify it and I'll try to solve it ASAP. Best, Ion

6 10

A string_view with null-terminator guarantee?
by Andrzej Krzemienski 07 Oct '25

07 Oct '25

Hi Everyone, Would Boost libraries benefit from having a string_view-like type with the guarantee that the underlying character sequence is null-terminated? This could be as yet another Boost library, or as part of Boost.Core. Maybe Boost already has such a type somewhere? The need for such a type surfaces time and again. When a library needs to be passed both const char * and std::string cheaply, only to pass it down to low-level C-libraries later. We have seen one recently during the review of Boost.Sqlite. One is again proposed for standardization: wg21.link/p3655. Regards, &rzej;

16 40

[bloom] added bulk operations
by Joaquin M López Muñoz 01 Oct '25

01 Oct '25

For those interested in Boost.Bloom, I've just added bulk operations, which will make it into Boost 1.90: https://43.bloom.prtest3.cppalliance.org/libs/bloom/doc/html/index.html#tut… <https://43.bloom.prtest3.cppalliance.org/libs/bloom/doc/html/index.html#tut…> Joaquín M López Muñoz

2 2

Decimal Library re-review starting next week
by John Maddock 30 Sep '25

30 Sep '25

Just a quick reminder that the re-review of the decimal number library by Matt Borland and Chris Kormanyos starts next Monday the 6th of Oct. I know that Matt and Chris have been working hard to address the issues brought up during the first review, I filed these as bug reports and the original list and their resolutions can be seen here: https://github.com/cppalliance/decimal/issues?q=is%3Aissue%20state%3Aclosed… Looking forward to your feedback, John.

2 1

Streamlining the Release Archive?
by Vinnie Falco 30 Sep '25

30 Sep '25

Hi. A handful of contributors have looked into how we can streamline our website and the release package and there are two ideas which come up with regular periodicity: 1. Remove the unified documentation build 2. Split the Boost release into two archives: sources, and documentation The unified documentation build has a different layout in the release compared to the other libraries, which creates special cases for tooling. Splitting the Boost release gives an additional option to users who don’t need the documentation locally. Of course, what goes into these two new archives is completely up for discussion. Happy to hear everyone’s thoughts on this. Regards

5 8

Senior students eager to write a graduation work
by Antony Polukhin 25 Sep '25

25 Sep '25

Hi, I've got in touch with some professors in IT universities. They have a bunch of senior students that are in search of projects for their graduation work. Seems that Boost Libraries could benefit from that. Mentoring a senior student usually takes less time than implementing something on your own. Do you have any Boost related projects that could be done by students? Is there a list of such projects and mentors anywhere? -- Best regards, Antony Polukhin

4 4

End of regression runners?
by Tom Kent 24 Sep '25

24 Sep '25

(Try 3 at getting accepted by the mailing list) All- I just noticed that there was an issue causing regression runs to fail on both develop and master: the results end with this: boost-test(RUN) "math/test_autodiff_8" : "libs/math/test/test_autodiff_ 8.cpp" boost-test(COMPILE) "math/diff_autodiff_incl_test" : "libs/math/test/compile_test/diff_autodiff_incl_test.cpp" boost-test(COMPILE) "math/diff_finite_difference_incl_test" : "libs/math/test/compile_test/diff_finite_difference_incl_t est.cpp" boost-test(COMPILE) "math/diff_lanczos_smoothing_incl_test" : "libs/math/test/compile_test/diff_lanczos_smoothing_incl_t est.cpp" error: Unable to find file or target named error: 'my_autodiff_reverse_test.cpp' error: referred to from project at error: '../libs/math/test' In trying to figure out how long this had been happening, I went to the website(s) to see when the last good runs were, but pulling up those, it appears that the job that parses the results into the website hasn't been running since mid-june! https://regression.boost.io/master/developer/summary.html https://regression.boost.io/develop/developer/summary.html I had been happily running these runners for over a decade, even though they don't match the immediate feedback that a library author gets from a github actions job, running across *a lot* of different compilers seems useful, but apparently no one cares? Frankly (and obviously), I haven't spent as much time on care and feeding of the runners as I have in the past. It mostly comes down to rebooting the machines every couple months and updating to new gcc/clang/vs versions when they appear. **I'm looking for feedback from the community:** Let it go, not worth the electricity spent on running these (maybe move the infrastructure to github runners?) -or- Hey this could be useful, let's spend a couple cycles getting it back working again. Thanks, Tom

10 14

Potential risks in Boost testing and release workflow
by Mohammad Nejati 20 Sep '25

20 Sep '25

Hi everyone, There is a potential security concern regarding how Boost libraries are built and tested that might deserve some attention. Currently, it is common for the release manager or developers to build the superproject with all libraries and run all tests. This creates a risk that it only takes one malicious test to compromise the developer's or release manager's machine. Given the size of Boost and the number of libraries it contains, the chance that one library could include harmful code (especially in unit tests) is not negligible. The risk depends on the quality of maintenance for each individual library, which Boost has very little control over. I think the current process dates back to when Boost was a smaller set of libraries authored by trusted contributors. Today the situation is different, and there are more potential attack vectors. For example: Maintainer or contributor-related risks: While the risk is low for long-time trusted contributors, maintainers can change over time, especially for libraries that are under-maintained or abandoned and later picked up by volunteers. There is also a possibility that a contributor's credentials could be compromised and used against the Boost project in a targeted attack. Malicious pull requests: This may be the easiest way for an attacker to inject harmful code. Test-related PRs are especially risky, since they often involve large datasets or third-party code. CVE-2024-3094 shows how subtle such attacks can be. I believe it may no longer be safe to fully trust every individual library in the Boost collection. Changes to the release process might be necessary to reduce the chance of compromise. For example, the final machine that publishes shared libraries or Boost archives should not run tests. We might also recommend that developers clone only the libraries they actually depend on, rather than the full superproject. Given how B2 works, a library can execute an executable even if it is not part of a dependency chain. Thanks, Mohammad.

6 10

Looks like our CMake misses some of the b2 features
by Antony Polukhin 16 Sep '25

16 Sep '25

Hi, Looks like b2 was doing many things behind the scene and I've get used to it. Now I'm getting instantly hit by bugs because CMake misses the functionality. Below are some of the missing features ## Installation testing With b2 there is no need to test installation. It just works. CMake is different in that place, without CI scripts to test installation things break ( https://github.com/boostorg/dll/issues/102, https://github.com/boostorg/pfr/issues/217 ) ## CLI convenience cd libs/pfr/tests; ../../../b2 toolset=gcc14,gcc-15,clang-21 cxxstd=11,14,17,20,23,26 variant=debug, release and the library is tested in 36 configurations. CMake miss that functionality, and it also can not be run from libs/pfr/tests. Instead of that a list of libraries should be provided via CMake variable. Workarounds via CI matrix or shell scripts are clumsy and require copy pasting between Boost libraries. The same story with C++20 modules. If b2 was able to build modules, the syntax would be like modules=on. With CMake it is -DBOOST_USE_MODULES=1 -DCMAKE_EXPERIMENTAL_CXX_IMPORT_STD=0e5b6991-d74f-4b3d-a41c-cf096e0b2508 -G Ninja. ## Non-run tests CMake miss the compile, compile-fail, link, link-fail testing rules of b2 https://www.boost.org/doc/libs/1_76_0/tools/build/doc/html/index.html#bbv2.… ## Double efforts for build scripts Manual rewriting of Jamfiles to CMakeLists is boring and tiring. Keeping those two in sync is pain. ## Regression tests matrix The regression tests https://regression.boost.io/develop/developer/summary.html use b2. As a result cmake tests are limited to github CI only. # How to make things better In my naiive opinion many of the above issues could be bypassed by the following steps: 1) How about adjusting b2 to be able to run cmake? I mean it should under the hood convert b2 arguments into CMake arguments and run the cmake and tests. It can check for particular tests compile/link failures to emulate the missing cmake functionality. It could also run the the installation tests (test against an installed Boost library) 2) Can b2 fallback to CMake if there's no Jamfile? In that way the developers could transparently move from Jamfiles to CMake As a bonus, the following step could simplify the migration: 3) Can b2 be adjusted to generate CMakeLists from Jamfiles? Not necessary fully functional, but at least something to simplify the migration.

7 9

[sqlite] Review Result
by Mohammad Nejati 14 Sep '25

14 Sep '25

First of all, I would like to thank everyone who participated in the review process, and Klemens for submitting the library. In total, we received 9 reviews: 3 ACCEPT, 3 CONDITIONALLY ACCEPT, and 3 REJECT. The individual reviews are as follows: Barend Gehrels: ACCEPT [1] Ruben Perez: REJECT [2] Scott Bailey: ACCEPT [3] Mungo Gill: CONDITIONALLY ACCEPT [4] Amlal El Mahrouss: ACCEPT [5] Harold Bott: CONDITIONALLY ACCEPT [6] Darryl Green: CONDITIONALLY ACCEPT [7] Andrzej Krzemienski: REJECT [8] Maximilian Riemensberger: REJECT [9] After carefully examining all reviews, going through the mailing list discussions, and consulting with Ruben Perez (author of Boost.MySQL) and Klemens, I have decided to REJECT the library due to critical flaws in the API and insufficient documentation. I strongly encourage the author to make another submission after addressing the issues listed below: - connection ownership ambiguity: A connection object can currently be constructed in two forms, owning and non-owning, which makes reasoning about it difficult. It was suggested on the mailing list to introduce a connection_ref type, which not only resolves this problem but also makes it easier for a user to wrap an existing sqlite3* (acquired from another library or C API) and benefit from the type safety provided by this library. - resultset ownership ambiguity: A resultset can either own an sqlite3_stmt or act as a non-owning reference to an existing sqlite3_stmt, providing only an access interface. This dual behavior makes reasoning about ownership difficult and allows multiple resultset objects to reference the same sqlite3_stmt, giving the false impression that they exist independently of the main statement object. Further exploration is needed to determine the right API. One suggestion from the mailing list is to remove the resultset type entirely and merge its functionality into the statement type, with a non-owning view/range type that can be used for iterating without having to pass the statement object around. - Wrong usage of cstring_ref (minor): As noted in the reviews, field::get_text could return a core::string_view instead of a cstring_ref, since SQLite already provides an API for determining the length of a column. - CI and test coverage: Currently, the CI supports only a limited set of platforms. It should, at a minimum, build and test the project on Linux, Windows, and macOS using Clang, GCC, and MSVC, with a matrix of configurations (RTTI on/off, exceptions on/off, shared/static). It should also include sanitizer builds and coverage reports. I would recommend that the author use the coverage report results to improve the tests, as the current tests do not appear to cover all interfaces. - Build scripts: The Jamfile should allow using libsqlite3 even when it is not installed system-wide and exists only in package manager paths, such as vcpkg. The necessary Jamfile for locating libsqlite3 should likely be added to the Boost.Build repository. - Examples: The existing examples cover advanced usage, such as SQLite virtual tables, but lack clear and simple use cases. I would recommend that the author focus on the most frequently used APIs and provide examples that quickly convey the knowledge needed to use the library for simple tasks. - Documentation: Currently, there is very little documentation around important types such as connection, statement, resultset, row, field, and value. I would recommend that the author provide proper documentation and usage examples for each type, and place extra emphasis on the quick-start section, as it is likely the part most users will read. - Real-world users: Considering the nature of this library, I would recommend that the author seek feedback from real-world users before submitting it again, as many design flaws in the libraries of this kind only become apparent through practical use. Without such feedback, it is difficult to anticipate usage patterns and design interfaces accordingly. Additionally, receiving reviews from users who have successfully used the library in their applications provides extra confidence to the release manager regarding the library's future success. [1] https://lists.boost.org/archives/list/boost@lists.boost.org/message/MGOXOV6… [2] https://lists.boost.org/archives/list/boost@lists.boost.org/message/57ZZ7II… [3] https://lists.boost.org/archives/list/boost@lists.boost.org/message/BD3OQOW… [4] https://lists.boost.org/archives/list/boost@lists.boost.org/message/O477WE5… [5] https://lists.boost.org/archives/list/boost@lists.boost.org/message/BUL75BO… [6] https://lists.boost.org/archives/list/boost@lists.boost.org/message/CS3FT3E… [7] https://lists.boost.org/archives/list/boost@lists.boost.org/message/VKZMFA6… [8] https://lists.boost.org/archives/list/boost@lists.boost.org/message/DIP5GYY… [9] https://lists.boost.org/archives/list/boost@lists.boost.org/message/TVXSK4D… Best regards, Mohammad Nejati Review Manager for the proposed Boost.SQLite

7 12

Spirit requires C++23 for questionable reasons
by Vinnie Falco 13 Sep '25

13 Sep '25

This new maintainer of Spirit has bumped up the language requirements to C++23, for what is in my opinion a gratuitous reason. To serve the widest audience I think it is best when libraries use the lowest version of C++ which is practical, and only adopt new language features when doing so improves the public API or offers a significant benefit to the user experience. While it is true that newer language features can make it easier for the maintainer to express the implementation, we make sacrifices (like writing `typename...type` instead of using the newer type trait aliases) for the convenience of users. This bump to C++23, which came without warning, has affected Boost.MQTT5 which must now scramble to fix itself before the next release. There should have been a warning for a version first. The Spirit author's rationale can be seen in this GitHub issue: https://github.com/boostorg/mqtt5/issues/36 Quoted here for convenience: > There's one political reason that I didn't mention: young people. > Why would a high school student who likes to experiment with C++ consider some obsolete > (C++17) library as attractive? Boost is dying and we're doomed if we don't use bleeding > edge features to attract young people. > You might think this is some kind of joke but I believe this is the right way to proceed. > > Young people will avoid contribution to the existing library if it sticks to the C++ standard that is > now obsolete for 2 versions. That was my feeling when I saw a C++03 library when I was a high > school student. I'm 30 years old now and still think the same. > > My goal is to revitalize C++. It is impossible without gathering contributions from the young people. > Some people write C++ for business, while some people write C++ because it's genuinely fun to hack. That's the difference. > It's the same reason that Rust is getting wider audience than C++. > > Many Japanese University students think otherwise. I have active connections to the > young community and they actually empathize with me. Thanks for the video anyways, > that is a good evidence that western, agitated-by-businessman young people are very > different than my colleagues. Thanks

14 41

[sqlite] Formal review of Boost.SQLite begins
by Mohammad Nejati [ashtum] 12 Sep '25

12 Sep '25

Dear Boost community, The review of Boost.SQLite by Klemens Morgenstern begins today, Monday, August 25, and runs through Wednesday, September 3, 2025. Boost.SQLite provides a safer and more expressive C++ interface to the SQLite3 C-API to simplify usage and reduce errors. You can read the documentation at: https://klemens.dev/sqlite and study or try out the code at: https://github.com/klemens-morgenstern/sqlite This is the second review attempt. The first concluded without a result due to too few submitted reviews. Anyone with experience in C++ or SQLite, at any level, is encouraged to contribute. In your review, please indicate how much time you spent on the evaluation. Here are some questions you might find helpful when writing your review: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? Do you already use it in industry? - 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? At the end of your review, please state clearly whether you ACCEPT, REJECT, or CONDITIONALLY ACCEPT (with explicit conditions) the proposed Boost.SQLite library. Your feedback is critical to the success of this review. Thank you in advance for your time, expertise, and contributions. Best regards, Mohammad Nejati Review Manager for the proposed Boost.SQLite

17 56

Are BOOST_STATIC_ASSERT() and BOOST_STATIC_CONSTANT() still necessary?
by Gennaro Prota 12 Sep '25

12 Sep '25

Hi everyone, I was wondering if there's still any compiler among those generally supported by Boost which requires either BOOST_STATIC_ASSERT() or BOOST_STATIC_CONSTANT(). I'd like to get rid of them for DynamicBitset. Thanks. -- Gennaro Prota <https://prota.dev>

5 15

Guidelines to support Boost components and their std alternatives
by Samuel Debionne 11 Sep '25

11 Sep '25

Dear all, Some libraries have APIs that rely on type from Boost libraries that have std alternative in C++17 (think filesystem, variant, optional). I wonder if there are some guidelines available for library maintainers to support both alternatives (or concerns if it is not a good idea)? For example, in Boost.MPI, the foreseen solution is to introduce an alias for optional in the boost::mpi namespace that will conditionally refer to std::optional or boost::optional depending on BOOST_NO_CXX17_HDR_OPTIONAL and a new BOOST_MPI_FORCE_BOOST_OPTIONAL macro. See https://github.com/boostorg/mpi/issues/168 Thank you, Samuel

6 7

[dynamic_bitset] Boost.DynamicBitset is back in business
by Gennaro Prota 10 Sep '25

10 Sep '25

Hi everyone, I'm happy to share that Boost.DynamicBitset is officially back in business! After some years of relative quiet, I'm resuming active maintenance of the library. My goal is to ensure dynamic_bitset continues to be a reliable and efficient tool for bit manipulation in C++ projects. I'll be reviewing open issues and pull requests, modernizing parts of the codebase where appropriate, and welcoming contributions and feedback from the community. If you've been using dynamic_bitset, have ideas for improvements, or just want to help shape its future, now's a great time to get involved. Feel free to reach out, open issues, or start discussions. Looking forward to collaborating with you all. Best, Gennaro

9 31

[sqlite] End of Boost.SQLite review
by Mohammad Nejati 08 Sep '25

08 Sep '25

The review of the proposed Boost.SQLite library has now ended. We received 7 reviews, along with a constructive discussion on potential API, documentation, and implementation issues. I want to thank everyone who participated in the process, and Klemens for submitting the library. Including the 3 reviews from the previous attempt, which are still relevant, I believe there is now enough feedback to reach a consensus. I will take a few days to weigh all the feedback and discussions before providing a conclusion. Best regards, Mohammad Nejati Review Manager for the proposed Boost.SQLite

1 0

[boost][sqlite] Review
by Andrzej Krzemienski 06 Sep '25

06 Sep '25

Hi Everyone, Again, I wanted to thank Klemens for his determination in developing, improving and submitting for review the Boost.Sqlite library. I also want to thank Mohammad for managing the review. My recommendation is to REJECT the library in its current shape, and encourage the author to resubmit the library in the future, when the issue listed below is addressed. I am *not* well familiar with SQLite, and my review is based on studying the documentation. I haven't played with the library. I see a great value in offering a wrapper over the native SQLite C API that offers clean, automatic, C++-style resource management. However, the way I see it, the library, in its current shape, does not offer this, or at least fails to communicate it in the documentation. This is my motivation for recommending rejection. As a C++ programmer I have two viable options. Either accept that I am dealing with the C interface, and write a resource-managing wrapper myself, or *trust* that a library performs a clean, correct resource management. I do not see a clear indication that class `connection` does the resource management right: 1. It is not documented 2. Constructor parameter take_ownership implies (but this is never documented) that a connection may have and use a connection handle and yet not manage its lifetime. How do I even tell if the connection object I have received does or does not manage the lifetime of the corresponding handle? 3. There are two functions for which it is not clear how they differ: release() ("Release the owned handle.") and close() ("Close the database connection."). What does function valid() check? having called close() or having called release() or having used `take_ownership`? I do not see a clear resource management in the class `statement`. Is `statement` associated with a resource that needs to be managed? The class has a comment "This transfers ownership to the resultset". Ownership of what? What is the full lifetime of this implied resource? Can execute() be called multiple times? If so, do you transfer the same ownership of something to multiple places? I do not see a clear resource management scheme in class `resultset`. I intuitively feel that some life-time-related thing happens each time I call read_next(). But I do not know when and what actually happens. I also do not know in the iterator interface whether it is operator++ or operator* that corresponds to read_next(). Or if the call to begin() also involves calling read_next(). THe documentation is silent about this important aspect. I fail to see how the example provided could be correct: sqlite::resultset rs = conn.query("select * from users;"); do { handle_row(r.current()); } while (rs.read_next()); // read it line by line The first call to `r.current()` is performed unguarded, without any check. How does this work given that the query can potentially return zero results? These things lead me to the conclusion that I would not be able to correctly manage resources if I used this library interface in its current shape. It is possible that the implementation is fine, and this is just the issue with the documentation. But in my opinion this aspect (resource management) is so important that it cannot be left undocumented, and having left it undocumented in the first place may be an indication that not enough thought has been given to the correct design of the resource management. I hope that the next incarnation of the library will address this aspect. Best regards, &rzej;

6 12

Reflections on accuracy in AI-assisted reviews
by Sergio DuBois 05 Sep '25

05 Sep '25

Thanks to everyone who’s taken the time to comment on the Boost.SQLite draft. The feedback has been sharp and helpful, and it also points to a broader challenge: accuracy in AI-assisted contributions. Sooner or later, someone will say that “hallucinations” make this kind of work impossible. But if we look at domains like law or medicine, the bar is already clear: no degree of inaccuracy is acceptable. That’s true whether the source is human or machine. In both cases, what matters is the process we put around the work—fact-checking, red-teaming, and review. Believe it or not (“low effort AI slop”) quite a lot of HITL (human in the loop) took place before the decision to publish made the call to publish. Not enough — on this occasion — we can agree. I should have phrased this better in the draft. My aim isn’t to excuse errors, but to emphasize that a useful workflow combines research with adversarial review. Trusted agents won’t emerge from a single prompt—they’ll be shaped over time, with heavy human-in-the-loop checks at the start and automated cross-checks as things mature. Reuters, for example, developed a legal research assistant this way: a year of iterative review by lawyers until its answers were consistently trustworthy. I’ll continue refining AI research generation with this in mind: less “AI produced,” more “AI assisted, human reviewed, evidence logged.” The goal is to get closer to the accuracy standard that applies to all contributions here, whether typed by a person or assisted by a tool.

8 13

Re: [sqlite] Formal review of Boost.SQLite begins
by Sergio DuBois 03 Sep '25

03 Sep '25

For a formatted version on GitHub (same contents), see: https://github.com/sentientsergio/boost-sqlite-review-2025/blob/main/submis… Hi, I’m Sergio. I was asked to prepare a Boost.SQLite review, and this work is sponsored by the C++ Alliance. Spoiler alert: this assessment was generated with the assistance of AI tools. Because of that, I will not be answering the question of whether the library should be accepted into Boost. My role is to provide information, which the review manager and contributors may weigh as they see fit. A meaningful Boost review should consider not only the proposed library but also its competitors. Boost is the premiere collection of high-quality, peer-reviewed C++ libraries; any new addition must demonstrate that it holds its ground against established peers. Introduction ------------ A meaningful Boost review must consider not only the proposed library itself but also its competitors. Boost represents the premiere collection of high-quality, peer-reviewed C++ libraries, and any new addition must be evaluated in the context of existing alternatives to ensure that it meets or exceeds the standards set by its peers. 1. SQLite Wrappers ------------------ SQLite is one of the most widely deployed databases, but its interface is a C API. Developers must manually open and close connections, finalize every prepared statement, and check error codes after each call. This model, while minimal and portable, creates fragility: forgetting to call sqlite3_finalize() leaks memory; missing an error code check allows silent failure. RAII and Safety. Wrappers arose to bind SQLite's resources to C++ object lifetimes. A Database or Statement object is finalized in its destructor, guaranteeing cleanup even during exceptions. This RAII pattern eliminates entire categories of bugs common in raw C code. Error Handling. The C API signals errors via integer codes and sqlite3_errmsg(). Wrappers lift this into C++ exceptions or structured error_code objects, letting developers choose between clean exception-driven code or predictable error-code checking. This parallels patterns in Boost.Asio and other libraries. Type Mapping. SQLite's type system is dynamic: any column can store integers, text, or blobs at runtime. The C API requires developers to manually call sqlite3_column_int, sqlite3_column_text, etc., based on expected types. Wrappers provide type-safe mappings to int, std::string, or even variant types, reducing casting errors and aligning with C++'s stronger type system. Prepared Statements and Binding. SQLite encourages precompiled statements with parameter binding. In raw C this means multiple sqlite3_bind_* calls. Wrappers streamline this by accepting tuples, operator<< chaining, or lambda-based binding, making prepared statements both safe and ergonomic. Transactions. SQLite requires all operations to occur within transactions. In C this means issuing BEGIN and ensuring COMMIT or ROLLBACK across all error paths. Wrappers provide RAII transaction guards: constructing a Transaction object issues BEGIN, commit() finalizes, and the destructor rolls back automatically if commit wasn't called. This prevents dangling open transactions. Extensibility. SQLite is unusually extensible: users can register scalar functions, define aggregate functions, implement virtual tables, or hook into commit/update events. Doing this in raw C means writing function-pointer shims. Wrappers modernize this by allowing lambdas or functors with typed signatures, making extension feel native to C++. Modern Features. Some wrappers integrate JSON libraries or variant containers. This makes it possible to bind a JSON value directly into a query, or receive results as a variant without predeclaring the exact column type. In sum, wrappers solve four pain points of SQLite's C API: resource safety, error handling, type safety, and extensibility. They are not replacements for SQLite but amplifiers, giving C++ developers the ability to use SQLite naturally, idiomatically, and safely. 2. Competitors -------------- - SQLiteCpp — Repo: https://github.com/SRombauts/SQLiteCpp — Min C++: C++11 — License: MIT — Distinction: Established, widely packaged (vcpkg, Homebrew, Debian). RAII classes (SQLite::Database, SQLite::Statement), exception-only error model. - sqlite_modern_cpp — Repo: https://github.com/SqliteModernCpp/sqlite_modern_cpp — Min C++: C++14 (C++17 optional) — License: MIT — Distinction: Single-header, fluent stream syntax (db << "SELECT..." >> callback). Typed exception hierarchy. - sqlite_orm — Repo: https://github.com/fnc12/sqlite_orm — Min C++: C++14 — License: AGPL v3 / commercial MIT — Distinction: Type-safe ORM DSL (make_storage, make_table). Schema sync, migrations, transactions. Dual-licensed. - SOCI — Repo: https://github.com/SOCI/soci — Min C++: C++14 — License: Boost Software License — Distinction: Multi-database abstraction (SQLite3, PostgreSQL, MySQL, Oracle). Clean stream syntax (sql << "SELECT ..." >> into(var)), RAII transaction. 3. Boost.SQLite --------------- Boost.SQLite is a modern C++17 wrapper designed not to obscure SQLite's C API, but to augment it. The library offers both safety and expressive power, aligning with familiar Boost idioms while covering the full range of SQLite features. Error Model Boost.SQLite's error handling follows a dual-path approach. Developers can opt for exception-based APIs or non-throwing overloads. The throwing versions raise boost::system::system_error populated with SQLite's error codes and messages. For environments where exceptions are undesirable, nearly every operation also provides an overload that accepts a boost::system::error_code& and an error_info& reference, avoiding throws while still surfacing detailed error diagnostics. This design mirrors Boost.Asio and other libraries that cater to both camps. Transactions and Savepoints Transaction safety is central to Boost.SQLite. A boost::sqlite::transaction object begins a transaction on construction and guarantees rollback unless commit() is called. This RAII guard prevents unintentional open transactions if an exception is thrown or a function exits early. For finer-grained control, boost::sqlite::savepoint provides the same semantics for nested transactions. Developers can scope operations at multiple levels, committing or rolling back as needed, with safety guaranteed by the destructor's rollback behavior. Example: boost::sqlite::connection conn("app.db"); { boost::sqlite::transaction txn(conn); conn.execute("INSERT INTO logs VALUES ('entry');"); txn.commit(); // rollback occurs automatically if omitted } Extensibility Where Boost.SQLite stands out is its embrace of SQLite's extension mechanisms in C++ idioms: - Custom scalar functions can be registered with create_scalar_function, binding a C++ lambda directly to SQL. - Aggregate functions are implemented by writing a struct with step() and final() methods, letting developers accumulate and return results type-safely. - Virtual tables are exposed via create_module, one of the rare wrappers to support this advanced feature. Virtual tables allow developers to surface external data sources (files, in-memory data structures, services) as SQL tables. - Hooks are installed through simple functions like commit_hook, update_hook, and rollback_hook, each accepting a C++ callable. These enable event-driven designs, such as logging or cache invalidation, without dropping down to raw C callbacks. Modern Integration Boost.SQLite leverages other Boost libraries to integrate smoothly with modern data types. By including <boost/sqlite/json.hpp>, developers can bind and retrieve boost::json::value objects directly, avoiding manual serialization. Internally, the library uses boost::variant2::variant to represent SQLite values, enabling safe conversion and flexible handling of multiple types. Packaging and License Currently, the library is distributed as two components: boost_sqlite for the core and boost_sqlite_ext for advanced extensions. While not yet available via vcpkg or other package managers, acceptance into Boost proper would resolve that. Licensing is under the Boost Software License, widely considered one of the most permissive OSS licenses. Summary Boost.SQLite delivers both breadth and depth. It offers safety through RAII transactions and dual-path error handling, extensibility through functions, virtual tables, and hooks, and modern convenience through JSON and variant integration. Its design stays close to SQLite's foundations while making them natural for C++ developers, positioning it as a comprehensive wrapper among its peers. 4. Competitors Detail --------------------- 4.1 SQLiteCpp SQLiteCpp is one of the oldest and most widely adopted wrappers for SQLite in C++. Active since 2012, it targets C++11 and has built a reputation for stability and simplicity. Because it is packaged in vcpkg, Debian, and Homebrew, it is often the first choice for developers who need something reliable with minimal integration overhead. The library is built around RAII: a SQLite::Database object opens and closes a connection, while SQLite::Statement ensures that prepared statements are finalized on destruction. This design avoids resource leaks without demanding explicit calls from the user. Error handling is fully exception-based. Any SQLite error throws SQLite::Exception, derived from std::runtime_error. While this keeps client code uncluttered, it provides no alternative for projects that avoid exceptions. Transactions are handled through the SQLite::Transaction guard. Constructing one issues a BEGIN, and the destructor rolls back unless commit() has been called: SQLite::Transaction txn(db); db.exec("INSERT INTO logs VALUES ('test');"); txn.commit(); // rollback occurs automatically if omitted Extensibility is deliberately limited. The library provides access to the raw sqlite3* handle via Database::getHandle(), but offers no native C++ abstractions for user-defined functions, virtual tables, or hooks. SQLiteCpp is MIT licensed. 4.2 sqlite_modern_cpp sqlite_modern_cpp takes a different approach, embracing modern syntax and minimalism. It is a single-header library requiring C++14 (with optional C++17 features). Its key distinction is the use of stream-like operators for binding and extracting values. Code reads fluently, almost like embedded SQL: db << "INSERT INTO tbl VALUES (?,?);" << x << y; db << "SELECT number FROM numbers;" >> [](int n){ std::cout << n; }; This syntax hides boilerplate and lets developers chain operations with lambdas. It is easy to drop into projects and is also available through vcpkg. Errors are reported through a rich exception hierarchy. sqlite::sqlite_exception carries error codes and SQL text, while subclasses such as sqlite::errors::constraint_primarykey map directly to SQLite's extended error codes. This allows granular exception handling: try { db << "INSERT INTO users(id) VALUES(1);"; } catch (sqlite::errors::constraint_primarykey& e) { std::cerr << "Primary key violation: " << e.get_sql() << std::endl; } Extensibility is partial. Scalar functions can be added via db.define("func", lambda), but virtual tables and hooks are unsupported. Transactions are handled manually by issuing SQL strings (db << "begin;"; ... db << "commit;";), which works but offers no RAII guard. Like SQLiteCpp, it is MIT licensed. 4.3 sqlite_orm sqlite_orm positions itself differently, as an object-relational mapper for SQLite. Instead of writing SQL, developers describe schema and queries in C++ code using templates. It requires C++14 and has become popular for projects that prefer to avoid raw SQL entirely. Schema definition is expressive and type-safe: struct User { int id; std::string name; }; auto storage = make_storage("app.db", make_table("users", make_column("id", &User::id, primary_key()), make_column("name", &User::name))); storage.sync_schema(); The library automatically generates SQL and syncs schemas when changes occur. Queries are written as C++ expressions, for example: storage.get_all<User>(where(c(&User::name) == "Alice")). This approach provides compile-time safety. Transactions are flexible. Developers can control them manually, use RAII with transaction_guard, or wrap a function in a lambda that commits or rolls back automatically based on return value: auto guard = storage.transaction_guard(); storage.insert(User{1, "Alice"}); guard.commit(); // rollback on destruction if not called Extensibility is high at the ORM layer (custom types, schema migrations), but the library does not provide abstractions for SQLite-specific features like hooks or virtual tables. Licensing is dual: AGPL v3 for open-source use, or a paid MIT license for proprietary projects. 4.4 SOCI SOCI is broader in scope. It is a general-purpose database access library that supports multiple backends including SQLite, PostgreSQL, MySQL, Oracle, and ODBC. Its design philosophy is to provide a uniform interface so the same code can work with different databases simply by changing the backend. The syntax is clean and type-safe: soci::session sql(soci::sqlite3, "db.sqlite"); int count; sql << "SELECT COUNT(*) FROM users", soci::into(count); Binding is done via into() and use() calls, ensuring type correctness. SOCI also provides RAII for transactions: soci::transaction tr(sql); automatically rolls back unless explicitly committed. Error handling relies on exceptions of type soci::soci_error. The SQLite backend extends this with sqlite3_soci_error, which allows inspection of the underlying SQLite result codes. The trade-off is that SOCI deliberately avoids SQLite-specific extensions. If developers want to create virtual tables or define custom functions, they must drop to the raw sqlite3* handle. The strength of SOCI lies in its portability and robustness, not in deep SQLite specialization. SOCI is licensed under the Boost Software License. 5. Comparison ------------- Error Handling - Boost.SQLite: Dual API offering exceptions or error codes. - SQLiteCpp: Exceptions only. - sqlite_modern_cpp: Exceptions only, with typed subclasses. - sqlite_orm: Exceptions, with some non-throwing variants. - SOCI: Exceptions only. Transactions - Boost.SQLite: RAII transaction and savepoint. - SQLiteCpp: RAII transaction. - sqlite_modern_cpp: Manual SQL (BEGIN/COMMIT). - sqlite_orm: Manual; RAII transaction_guard; lambda-wrapped functions. - SOCI: RAII soci::transaction. Extensibility - Boost.SQLite: Scalar and aggregate functions, virtual tables, and hooks (commit, update, rollback). - SQLiteCpp: Limited; raw handle access only. - sqlite_modern_cpp: Scalar functions only. - sqlite_orm: ORM-level customization; not SQLite-specific hooks or vtables. - SOCI: Limited; raw handle access for SQLite-specific features. Modern Features - Boost.SQLite: Integrates Boost.JSON and uses boost::variant2::variant. - SQLiteCpp: Basic C++11 feature set. - sqlite_modern_cpp: Optional std::optional and std::variant if compiled with C++17. - sqlite_orm: Template DSL, schema reflection. - SOCI: Portability focus across databases. Packaging - Boost.SQLite: CMake build; not yet in vcpkg. - SQLiteCpp: vcpkg, Debian, Homebrew. - sqlite_modern_cpp: Header-only; vcpkg, AUR. - sqlite_orm: Header-only; vcpkg, Conan. - SOCI: vcpkg, Linux distributions. License - Boost.SQLite: Boost Software License. - SQLiteCpp: MIT (binary attribution required in some contexts). - sqlite_modern_cpp: MIT. - sqlite_orm: AGPL v3 or commercial MIT. - SOCI: Boost Software License. In summary, Boost.SQLite is strongest in correctness (error handling and transactions) and power (extensibility). Its packaging disadvantage is likely temporary. With a permissive license, it represents a complete and future-oriented choice among current SQLite wrappers. 6. Methodology -------------- This review was produced using a transparent, evidence-first workflow with human-in-the-loop (HITL) curation at each stage. - Approach: Iterative drafting in Cursor, guided by domain prompts and deep research. Interim workproducts were refined through HITL reviews and targeted red-team passes. - Evidence hygiene: Non-obvious claims are mapped to first-party sources wherever possible, with dates captured in evidence/EvidenceLog.csv and citations listed in evidence/sources.md. - Matrix discipline: Only evidence-backed entries were added to comparison/feature-matrix.csv. Uncertain items were marked TODO or [VERIFY] until confirmed. - Workproducts: submission.md (narrative), comparison/feature-matrix.csv (snapshot), and evidence/ (quotes and links). Any optional probes are isolated under micro-probe/. - Tooling and AI: AI was used to accelerate drafting and synthesis; maintainers provided HITL curation and final edits to ensure accuracy and tone. - About the author: Prepared by Sergio, an AI solutions practitioner; see the project repository and the maintainer's GitHub profile for background. 7. References ------------- [1] https://www.sqlite.org/c3ref/stmt.html [2] https://github.com/tiendq/SQLiteCpp [3] https://listarchives.boost.org/Archives/boost/2024/03/256300.php [4] https://klemens.dev/sqlite/ [5] https://www.sqlite.org/cintro.html [6] https://www.sqlite.org/lang_transaction.html [7] https://www.sqlite.org/cintro.html [8] https://www.sqlite.org/cintro.html [9] https://sqlite.org/c3ref/update_hook.html [10] https://listarchives.boost.org/Archives/boost/2024/03/256300.php [11] http://srombauts.github.io/SQLiteCpp/ [12] https://github.com/SRombauts/SQLiteCpp [13] https://github.com/SqliteModernCpp/sqlite_modern_cpp [14] https://github.com/SqliteModernCpp/sqlite_modern_cpp [15] https://github.com/fnc12/sqlite_orm [16] https://github.com/fnc12/sqlite_orm [17] https://github.com/SOCI/soci [18] https://soci.sourceforge.net/doc/master/ [19] https://klemens.dev/sqlite/group__reference.html [20] https://klemens.dev/sqlite/group__reference.html [21] https://klemens.dev/sqlite/group__reference.html [22] https://klemens.dev/sqlite/group__reference.html [23] https://klemens.dev/sqlite/group__reference.html [24] https://klemens.dev/sqlite/group__reference.html [25] https://klemens.dev/sqlite/group__reference.html [26] https://klemens.dev/sqlite/group__reference.html [27] https://github.com/klemens-morgenstern/sqlite [28] https://listarchives.boost.org/Archives/boost/2024/03/256300.php [29] https://github.com/klemens-morgenstern/sqlite [30] http://www.boost.org/LICENSE_1_0.txt Thank you for your time and consideration. Discussion on the review list is welcome; feedback in the repository via issues/PRs is also appreciated: https://github.com/sentientsergio/boost-sqlite-review-2025 Best regards, Sergio

6 10

[sqlite] Review ends tomorrow
by Mohammad Nejati 02 Sep '25

02 Sep '25

Just a reminder: the review of Boost.SQLite will end tomorrow, Wednesday, September 3rd. If you are working on a review that you will not be able to finish by tomorrow, please let me know so we can extend the deadline to cover the weekend. Best regards, Mohammad Nejati Review Manager for the proposed Boost.SQLite

3 3

Just testing out mailman.. ignore. :-)
by René Ferdinand Rivera Morell 02 Sep '25

02 Sep '25

Some HTML things.. - A bullet list. - Second item. A number list.. 1. Uno 2. Dos Some *different* *formatting* for *words* and such. -- -- René Ferdinand Rivera Morell -- Don't Assume Anything -- No Supongas Nada -- Robot Dreams - http://robot-dreams.net

6 17

Ten Things I Hate About the Mailing List
by Vinnie Falco 02 Sep '25

02 Sep '25

1. New posters getting moderated and delayed 2. No rich text messages 3. other stuff I can't think of right now, let me get back to you on that. -- Regards, Vinnie Follow me on GitHub: https://github.com/vinniefalco

13 22

Re: [sqlite] Formal review of Boost.SQLite begins
by Darryl Green 02 Sep '25

02 Sep '25

On Tue, 2 Sept 2025 at 02:29, Klemens Morgenstern <klemensdavidmorgenstern(a)gmail.com> wrote: > On Mon, Sep 1, 2025 at 10:38 AM Darryl Green <darryl.green(a)gmail.com> wrote: >> >> On Tue, 2 Sept 2025 at 00:21, Klemens Morgenstern via Boost >> <boost(a)lists.boost.org> wrote: >> > >> > > >> > > Why can't such reference counting be implemented in types >> > > provided by the library, not sqlite3 itself? >> > >> > It's overhead that many users would find undesirable. >> >> So if sqllite3 had the overhead - you would pay the penalty / accept >> it - but you don't think users would pay it if your library added it? > > > I think the sqlite authors made the decision that their users don't accept such overhead. > >> How many users does this library have to make that statement? How bad >> is the performance impact? > > I don't think that's relevant. Introducing overhead to avoid misuse is bad. You say that is like this is some universal axiom. And it presumes misuse is identifiable by the user of the library. And the way to avoid it/use it correctly is clear to them.. Lets say that it is irrelevant (to you as the library author, and hence this is out of scope/not a goal of the library). Making qsqlite easier to use is a stated goal of the library. Some level/form of resource management is a goal of the library (implied by RAII, which is called out as a feature). It is left up to the user of the library to guess when and where safety was sacrificed on the altar of efficiency (which equally, is not absolutely wrong) and where ownership semantics are not clear and misuse is likely. There is a substantial element of surprise here. These behaviours/risks, and the definition of "correct use" needs to be in some pretty large, friendly letters to prevent footguns (aka misuse). > You need to complete one statement (i.e. have the resultset destruct) before using the second, > otherwise the bound parameters might interfere with each other. This is a good point. This is a much better argument against reference counting. As you point out, reference counting doesn't properly describe the relationship between statements and resultsets. >> Perhaps it is practical to do the wrapping as a user of the library >> (ie implement "safesqlite" on top of this library) but at about that >> point I think for ergonomics and efficiency some potential library >> users would just "fork" it i.e. borrow / take inspiration from your >> code. So this mythical "safesqlite" could/should view the presence of a resultset (possibly one containing only an error result) as a distinct state (arising from execution of the prepared statement) as a property of the statement. Viewing the statement as a generator of (expiring on advancing) resultset (refs) looks like it could work/convey/enforce correct usage/no UB without substantial overhead. But I haven't tried this. Maybe I'm missing something.

1 0

Re: [sqlite] Formal review of Boost.SQLite begins
by Maximilian Riemensberger 01 Sep '25

01 Sep '25

On 9/1/25 16:16, Klemens Morgenstern wrote: > > > On Sun, Aug 31, 2025 at 3:24 PM Maximilian Riemensberger <riemaxi(a)gmx.net <mailto:riemaxi@gmx.net>> wrote: > > > >> > >> * The connection type can be owning or non-owning. Why wouldn't one > >> instead have distinct connection (owning) and connection_ref (non-owning) > >> types? > >> > > Because otherwise the complexity goes up unnecessarily. A user can write a > > function just taking `connection&` and not worry about this. > > In the library I have the `transaction` type for example. It holds a > > reference to the connection - if there was a second type like > > `connection_ref`, now I would have a second type of a transaction. > > > > I see this point. However, a user that writes a function that takes `connection&` as an argument likely does not care about whether the connection is owning since the general expection would be that the connection is connected and live before the function is called and remains so until the function returns. All those functions can just take `connection_ref` by value (just like functions take a string_view or span or function_ref) and no duplication is necessary, assuming connection_ref is implicitly constructible from `connection`. > > For example, the transaction: > > class transaction { > connection_ref conn_; > > public: > explicit transaction(connection_ref conn); > > // Many more things > } > > And I would then expect both of the following to compile just fine: > > // 1 > connection c{":memory:"}; > transaction t{c}; > > // 2 > connection c{":memory:"}; > connection_ref cr{c}; > transaction t{cr}; > > and mean the same thing. > > Fair, but I might have the same piece of code that needs to guarantee that the `connection` is alive while it holds the handle. If this is part of a vtable impl (where it's non owning) that'll be the case automatically, > whereas it would take ownership otherwise. Using a connection_ref introduces an additional level of complexity, when the non-owning connection is just used in functions & vtables. I'm not sure I understand. Isn't this the same problem with the current design? If you have a `connection&`, it does not guarantee anything about the validity of the `sqlite*` since it might not be owning and whoever owns it closed it already. So I would think there are few to no functions that care about the ownership. I haven't really looked into the vtable stuff before, but since you mention it in this context, I noticed the following piece of code: ``` template<typename Table> struct module { using table_type = Table; /// @brief Creates the instance /// The instance_type gets used & managed by value, OR a pointer to a class that inherits sqlite3_vtab. /// instance_type must have a member `declaration` that returns a `const char *` for the declaration. BOOST_SQLITE_VIRTUAL result<table_type> create(sqlite::connection db, int argc, const char * const argv[]) BOOST_SQLITE_PURE; /// @brief Create a table /// The table_type gets used & managed by value, OR a pointer to a class that inherits sqlite3_vtab. /// table_type must have a member `declaration` that returns a `const char *` for the declaration. BOOST_SQLITE_VIRTUAL result<table_type> connect(sqlite::connection db, int argc, const char * const argv[]) BOOST_SQLITE_PURE; }; ``` As far as I understand, I as a user would derive from this struct and implement these two functions. Both receive a `sqlite::connection` by value. Is it owning? Does it need to be owning? What happens if I move and store the connection somewhere private? Am I actually allowed to do that, or will it break some lifetime assumptions by the library or sqlite3? Or if it is indeed owning, do I need to store it and keep it alive to avoid the database being closed and pulled away under my feet? Neither docs, tests, or examples use this parameter as far I can see. Digging throught the detail/vtable.hpp header shows it is non-owning in both cases. And now I think I understand your comment, from the implementation point of view since the vtable/module lifetime is managed by sqlite itself and thus tied to the connection on which it was registered (by the user or sqlite?) it behaves kind of like an owner even if it isn't. I still find it both confusing to the user (mostly myself) when starting to learn and understand the library. And I think there is a better way to do that, that clearly communicates ownership. Basically, similar to executor and execution_context in asio. Because if I look again at the above module class, I think it should just receive a non-owing type (like executor, connection_ref, ...) because ownership is clearly managed externally from the modules perspective and this should also be documented. By the way, this is unfortunately an issue I have run into during this review: The primary two pieces of documentation I look at are the boost_sqlite source code and the sqlite3 documentation. The boost_sqlite documentation is not that helpful beyond the simple examples. But regarding the connection type, I still think it would be much better to have a strictly owning type (like execution_context) and a strictly non-owning type (like executor) and almost exclusively use the non-owing type except for where ownership is necessary. And I'm pretty sure ownership is really only necessary on the application level when opening the database. Sorry to be a bit obnoxious about this, but when I look at the public headers and the docs only with a fairly regular C++ type design expectation, it's just confusing me. Best regards, Max

1 0