
On Tue, 2 Sept 2025 at 02:29, Klemens Morgenstern <klemensdavidmorgenstern@gmail.com> wrote:
On Mon, Sep 1, 2025 at 10:38 AM Darryl Green <darryl.green@gmail.com> wrote:
On Tue, 2 Sept 2025 at 00:21, Klemens Morgenstern via Boost <boost@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.