On Tue, 2 Sept 2025 at 00:21, Klemens Morgenstern via Boost <boost@lists.boost.org> wrote:
On Mon, Sep 1, 2025 at 10:13 AM Darryl Green via Boost < boost@lists.boost.org> wrote:
There is no obvious place to put the counter. If sqlite had those, I'd use them.
Fair enough.
Is it? Why can't such reference counting be implemented in types provided by the library, not sqlite3 itself? It is not unusual to do this for other resource handles that the underlying implementation doesn't reference count or otherwise lifetime manage.
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? How many users does this library have to make that statement? How bad is the performance impact? I admit there will be some set of users who will measure every cycle - they can use the raw C API at their own peril - or potentially one could provide some raw and some "less raw" types. 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.