On Mon, Aug 25, 2025 at 6:53 AM Mohammad Nejati [ashtum] via Boost <boost@lists.boost.org> wrote:

This is the second review attempt. The first concluded without a result due to too few submitted reviews.

Hi. Could we please have a summary a changes, if any, compared to the 1st review? Any review feedback incorporated?

Below is my initial review (with one typo edited). I believe many of the comments were incorporated. I look forward to using this in production. Thank you all for the time you've invested. SB # boost_sqlite review Please accept my apologies for the poor formatting. And a bit thank you to everyone involved in this process. I have long wished for a sqlite wrapper with critical mass. ## Author's Background I am a professional C++ software developer. I have been a professional user and proponent of Boost libraries since the late 2000s. I have been using SQLite for more than 10 years and at one time wrote my own C++ wrapper. ## Initial Thoughts and Use Case At the time I saw the announcement for this review, I was actively evaluating libraries for a project I was (and continue to be) working on. I successfully used the boost_sqlite library in a limited capacity (create, insert, and pragmas only for on disk and in memory DBs). My first impression of the library is that it's extremely lightweight. This simplicity has value but also leaves the end user reinventing the wheel for certain repetitive operations. For example, using class enums for pragma get and set moves defect finding from runtime (bad) to compile time (better!). My second thought was how painful it was to include in my professional project. Our legacy software does not build Boost.json and, while it was trivial to add it for my sandbox app, it is an unnecessary extra dependency. ## Design Evaluation Simple, straight forward, and intuitive. I believe it meets my needs. ### Wishlist Here are some wishlist items I have. They may be inappropriate for this library and boost in general; however, they are still on my wishlist. #### connection It would be great if connection had a simple enum so I could do this: ```cpp boost::sqlite::connection mydb(boost::sqlite::memory); ``` Also, given C++17 `std::fstream` takes `std::filesystem::path`, it would be nice if `connection()` et all did as well. And I wouldn't complain if `boost::filesystem::path` was supported as well. ## Implementation Evaluation I reviewed this library as a user. ## Documentation Evaluation The readme.md file was adequate for me to quickly build a simple SQLite DB application. ## Potential Usefulness This is a useful library. I intend to incorporate this into professional projects as soon as it becomes available in a stable boost release. ## Personal Usage I used the following compiler in my development: gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0 I included Boost and Boost.sqlite using CPM.cmake (fetchcontent). It was a trivial operation to include and link. ## Final Thoughts For the past few years I've lamented the lack of a Modern C++ SQLite wrapper with a critical mass of user backing. This library has the potential to fill that gap. I would like to see this library built without the json dependency. With or without the build dependency change, this library should be accepted into Boost. Scott Bailey On Sun, Aug 24, 2025 at 11:52 PM Mohammad Nejati [ashtum] via Boost < boost@lists.boost.org> wrote:

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 _______________________________________________ Boost mailing list -- boost@lists.boost.org To unsubscribe send an email to boost-leave@lists.boost.org https://lists.boost.org/mailman3/lists/boost.lists.boost.org/ Archived at: https://lists.boost.org/archives/list/boost@lists.boost.org/message/FK4NIN2J...

BACKGROUND Vinnie asked me to take a look at this library and give my feedback. This is my first Boost review. As such this review might not take into consideration accepted Boost coding practices. Although I do not have any experience of SQLite I have been working in C++ for several years, and have myself written (proprietary) C++ wrappers around C libraries for accessing other relational databases (notably Sybase). I spent approximately 4 hours in total looking at this library. This was, therefore only a quick reading. The library does warrant a more in-depth review but I wanted to get my initial feedback to the author early. COMPILATION I compiled this using GCC-13 on ARM64 Ubuntu C++17. When I attempted to compile using C++11 and C++14 there were numerous compilation errors (most notably in example/multi_index.cpp). If code is not expected to compile under older C++ versions it should be wrapped in appropriate #if...#endif statements. Out of curiosity I tried building this against the boost version (1.83) that ships with Ubuntu 24 and found it fails to compile under C++20 (missing pfr/core_name.hpp). I suspect this is not a huge concern as most users building this library will also build the things on which it depends. DOCUMENTATION This is probably my largest concern. The documentation itself seems extremely light. As an example of the more "advanced" features such as virtual tables need worked examples. Without some basic knowledge of sqlite3 it would be hard to follow. Some of the reference descriptions appear to be unfinished (for example vtab::cursor has the description "Cursor needs the following member"), and many detailed descriptions are just a repetition of the single-line headline. I would also like to see the detailed descriptions provide information about what purpose it serves and how it should be used rather than simply stating what can be deduced by looking at the header. In addition, many users will look at the examples for inspiration, so those examples should have detailed step-by-step comments stating what is being done and why it is being done that way. INTERFACE DESIGN AND IMPLEMENTATION As a first pass the interface struck me as being quite clean. I did spot some issues (below) but none of them are major. One thing that struck me about the 'prepare' function is the choice of placeholders. `?`-based `?1`, `?2` are used for numbered placeholders, and `$`-based `$name1`, `$name2` for named placeholders. This feels slightly inconsistent, but it matches what sqlite already does, so this point can probably also be mitigated by pointing out in the docs that the syntax is driven by sqlite3 (with appropriate link). I notice that a number of classes expose the `handle` of the connection. Is there any reason for this to be part of the public interface. I would be tempted to keep it private (at least for the initial release until there is a proven use case) `cstring_ref.hpp` uses `#if defined(BOOST_NO_CXX17)` as a workaround for the lack of a `BOOST_CXX17_CONSTEXPR` keyword. The better solution might be to add `BOOST_CXX17_CONSTEXPR` into `boost/config.hpp` alongside `BOOST_CXX14_CONSTEXPR`. `allocator` has two constructors: {{{ constexpr allocator( const allocator& other ) noexcept {} template< class U > constexpr allocator( const allocator<U>& other ) noexcept {} }}} Is the first (non-templated) constructor required? Why does error_info need additonal overloads for `format` when `__GNUC__` is defined? Is there a compiler bug on old versions of the compiler? The fact that `row` and `field` hold raw pointers to the statement makes me worry about possible lifetime issues and UB if users start returning these objects from functions. There would be a slight overhead but some form of `weak_ptr`-based mechanism might be safer. I have some other concerns (such as the fact cstring_ref even needs to exist), but I accept that the author's hands are somewhat tied by the needs of the sqlite3 C interface. RECOMMENDATION I think this would be a useful library, and appears to be more full-featured that the alternatives listed at the foot of the documentation. My recommendation would be to Conditionally Accept on the basis that the documentation requires further work, and the examples lack user-friendly code comments. My interface/implementation concerns above are sufficiently minor to not warrant delaying progress. On 25 Aug 2025, at 5:54, "Mohammad Nejati [ashtum] via Boost" <boost@lists.boost.org> wrote: 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 _______________________________________________ Boost mailing list -- boost@lists.boost.org To unsubscribe send an email to boost-leave@lists.boost.org https://lists.boost.org/mailman3/lists/boost.lists.boost.org/ Archived at: https://lists.boost.org/archives/list/boost@lists.boost.org/message/FK4NIN2J...