
pon., 1 wrz 2025 o 12:03 Ruben Perez via Boost <boost@lists.boost.org> napisaĆ(a):
* The statement type can construct owning and non-owning resultsets. The former automatically finalize, the latter reset the statement. Again why are those two behaviors combined in the same type?
Same reason as above. If a user wrote a manual converter for each row, he'd need to implement it twice. The point is that those two things just work:
T interpret_result(sqlite::resultset rs);
auto rr = interpret_result(conn.prepare("...").execute(...));
auto s = conn.prepare("..."); auto r2 = interpret_result(s.execute(...));
Why should I force a user to write two different implementations of interpret_result? And the answer isn't OOP for the resultset, because that it cannot be passed by value.
Similar as for the connection: If the user function `interpret_result` does not take ownership of the resultset, that is the resultset that is passed into the function must outlive the return of the function, then interpret_result should only be written once and take resultset_ref as argument. resultset is implicitly convertible to resultset_ref. There is also no lifetime issue here since the return value of execute lives at least until the end of the semicolon (after interpret_result returns).
T interpret_result(sqlite::resultset_ref rs);
auto rr = interpret_result(conn.prepare("...").execute(...));
// Same thing written in two statements sqlite::resultset rs = conn.prepare("...").execute(...) auto rr = interpret_result(rs);
sqlite::resultset_ref s = conn.prepare("..."); auto r2 = interpret_result(s.execute(...));
I still think that having types that might be owning or not depending on a runtime condition is problematic. See my last review [1] for examples on the footguns that this may produce. I don't think there is much precedent of such a pattern in the standard library, taking out unique/shared pointers with custom deleters. The solution that Max is proposing here seems sound to me.
On top of that, this controversial design aspect is not documented. After having read the docs I was not aware that this conditional ownership decision is implemented. As a user, I need to be able to reason about the ownership of the resources, I need to have all the information available. Regards, &rzej;
Regards, Ruben.
[1] https://lists.boost.org/archives/list/boost@lists.boost.org/message/57ZZ7IIW... _______________________________________________ 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/F62TWUTO...