sob., 6 wrz 2025 o 19:27 Mohammad Nejati via Boost <boost@lists.boost.org> napisał(a):
On Sat, Sep 6, 2025 at 8:36 PM Claudio DeSouza via Boost <boost@lists.boost.org> wrote:
How is a connection_ref different from a reference or a pointer to connection? I can’t help but to feel this is quite unusual, and that it will impose a certain cognitive cost to understand code that otherwise could be simpler for little return.
A connection& or connection* allows moving a connection because it has a mutable reference. Furthermore a connection_ref can point to a sqlite3* without the need for a connection object at all.
I do not understand the use case/constraint that Klemens describes, but I guess a pointer to connection will not suffice. Maybe, if the passing of the connection from sqlite to a user is *the only* use case, the following scheme would work: Keep the "take_ownership=false" constructor, but: * in the implementation make it private * in the documentation don't even mention it: it would be an implementation detail. Then, when need arises for sqlite to pass the connection to the user, create it privately, but return only a pointer to the `connection` object. In that scheme, the users do not even know about this non-owing state, and the thing is presented to them as if "the library somehow creates and destroys the resource-managed connection object at the right time". Regards, &rzej;